Flawed prime factorization program and unexpected 15C simulator behaviour

[Harald]

This is a program I have written a couple of years ago:

Code:


# --------------------------------------------
# HEWLETT·PACKARD 15C Simulator program
# Created with version 3.3.00
# --------------------------------------------
# --------------------------------------------

   000 {             } 
   001 {    42 21 11 } f LBL A
   002 {       44  0 } STO 0
   003 {           2 } 2
   004 {    42 21  0 } f LBL 0
   005 {       44  2 } STO 2
   006 {           1 } 1
   007 {       44  3 } STO 3
   008 {       45  0 } RCL 0
   009 {    42 21  1 } f LBL 1
   010 {          11 } √x̅
   011 {       44  1 } STO 1
   012 {    42 21  2 } f LBL 2
   013 {       45  1 } RCL 1
   014 {       45  2 } RCL 2
   015 {    43 30  7 } g TEST x>y
   016 {       22  5 } GTO 5
   017 {       45  0 } RCL 0
   018 {       45  2 } RCL 2
   019 {          10 } ÷
   020 {       42 44 } f FRAC
   021 {       43 20 } g x=0
   022 {       22  4 } GTO 4
   023 {           4 } 4
   024 {       45  2 } RCL 2
   025 {    43 30  7 } g TEST x>y
   026 {       22  3 } GTO 3
   027 {           2 } 2
   028 {    44 20  2 } STO × 2
   029 {           1 } 1
   030 {    44 30  2 } STO - 2
   031 {       22  2 } GTO 2
   032 {    42 21  3 } f LBL 3
   033 {           3 } 3
   034 {    44 40  2 } STO + 2
   035 {       45  3 } RCL 3
   036 {          16 } CHS
   037 {       44  3 } STO 3
   038 {    44 40  2 } STO + 2
   039 {       22  2 } GTO 2
   040 {    42 21  4 } f LBL 4
   041 {       45  0 } RCL 0
   042 {       45  2 } RCL 2
   043 {          31 } R/S
   044 {          10 } ÷
   045 {       44  0 } STO 0
   046 {       22  1 } GTO 1
   047 {    42 21  5 } f LBL 5
   048 {       45  0 } RCL 0
   049 {          31 } R/S
   050 {           0 } 0
   051 {       43 32 } g RTN

# --------------------------------------------

I calculates the prime factorization for a given number (Enter the number and execute LBL A).
It works for natural numbers with a maximum of 9 digits. For larger numbers it can come up with wrong results, because the fractional part (extracted in line 20 from the divison) might get rounded off. This beeing the flaw in the program as mentioned in the topic.
In such an event, the number might look divisable by a factor, where in fact it is not. For example 3333333333 returns a 2 as the first prime factor. Similarly 9876543210 returns several 2s although it only contains one.

Now to the unexpected behaviour with this 15C simulator. 9876543210 returns 5 as the first prime factor.
Reason being that 9876543210 Enter 2 FRAC returns 4294967296?!?
What is going on here? Am I making a mistake somewhere? Or is this a bug?[/code]

Cheers,
Harald