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

[Marcus von Cube]

(11-18-2015 02:54 PM)Harald Wrote:  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?

I added a division sign before FRAC. I assume you just forgot it.

Now back to your question. If it's a simulator it might just use binary arithmetic which can produce strange results.

[BarryMead]

(11-18-2015 02:54 PM)Harald Wrote:  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?

Even though the simulator uses binary floating point arithmetic native to the TCL/TK language, it usually has at least
as much or more accuracy than the 10-digit BCD arithmetic used in the original HP-15C.

This is a genuine bug in the simulator. After division by 2 FRAC should only return one of two values (zero, or .5) so
something is corrupting the behavior of the FRAC function. I noticed that it does not happen on all 10-digit numbers either.

I sent an email to Torsten Manz reporting the bug. If he responds with a fix, I will post an update in this forum.

[Harald]

(11-18-2015 05:53 PM)Marcus von Cube Wrote:  

(11-18-2015 02:54 PM)Harald Wrote:  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?

I added a division sign before FRAC. I assume you just forgot it.

Now back to your question. If it's a simulator it might just use binary arithmetic which can produce strange results.

Thanks Marcus, I just forgot it. It is there in the program though.

[Harald]

(11-18-2015 07:06 PM)BarryMead Wrote:  

(11-18-2015 02:54 PM)Harald Wrote:  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?

Even though the simulator uses binary floating point arithmetic native to the TCL/TK language, it usually has at least
as much or more accuracy than the 10-digit BCD arithmetic used in the original HP-15C.

This is a genuine bug in the simulator. After division by 2 FRACT should only return one of two values (zero, or .5) so
something is corrupting the behavior of the FRACT function. I noticed that it does not happen on all 10-digit numbers either.

I sent an email to Torsten Manz reporting the bug. If he responds with a fix, I will post an update in this forum.

Thanks for confirming the bug and reporting it Barry!

[Harald]

Hi Barry,

thanks for the patch, I will try it!
As this thread was more about a bug in the simulator than about my program I did not include enough information about it.

So: The Program is a port from the HP 25. Therefore it originally didn't use lables and R/S is used.
LBL A starts the program and will return the lowest prime. Pressing R/S then will return all remaining prime factors (including duplicate ones) until 0 is displayed indicating that all prime factors have been found.

Cheers,
Harald

[rprosperi]

(11-19-2015 11:42 PM)BarryMead Wrote:  If you unzip this attached zip file into your HP-15C source directory and patch with the following patch commands:
patch -p0 <fract.patch
patch -p0 <int.patch

The source for the HP-15C calculator will be bug free. You can either run this source with TCL/TK's wish program like this:
wish HP-15C.tcl

Or you can compile the source to an executable with the freewrap program available from http://freewrap.sourceforge.net/ like this:
freewrap HP-15C.tcl -o HP-15C

Barry - thanks for the patch, and patch to the patch, and the explanation of the nice features in this great 15C simulator. Sounds like it makes it truly easy to create well-documented programs for the emulator, and the DM-15/15L

I guess the above presumes one has some sort of TCL development system installed? I looked at the source files and don't see the needed patch.exe program to do the above, so that tool must be part of some IDE or other toolset?

[BarryMead]

I promised that if Torsten got back to me with his official bug fix for this issue, that I would post an update to this forum.

Well as he always does, Torsten came up with a much more elegant solution to this bug than my first attempt, so I am attaching his official source release here.

This "source" will not run in native windows systems so it isn't as nice as the annual releases found on Torsten's web site, but those who use linux, or have the necessary tools installed on their windows computers, can make use of it (wish or freewrap). You can download the free "Community Edition" of TCL/TK for windows (wish program) at this web site: http://www.activestate.com/activetcl
Or you can download freewrap which allows you to compile the TCL/TK source into a windows 64-bit executable from this site: http://freewrap.sourceforge.net/

Torsten calls this release 3402 so I named the zip file 3402.zip. When you unzip this file into your HP-15C source directory (overwriting your existing HP-15C.tcl file) it will fix the FRACT and INT bugs.

This file has also been updated to fix the Unicode Save Bug mentioned elsewhere in this thread. (When the "Encode programs in UTF-16 (LE)" checkbox is CHECKED)
This file has also been updated to fix the Boundary Condition Bug in which 1.0 and -1.0 were returning the wrong answer for both the FRAC and INT functions.
This file has also been updated to fix a File Save HTML help page bug. The older version was not automatically changing the suffix to .htm when saving help pages.

Cheers, Barry

[rprosperi]

(11-21-2015 03:14 AM)BarryMead Wrote:  As a "Linux" user, I often forget that many of the everyday tools that we take for granted are not available in native windows. There is a great tool that you can load into windows that will give you all of he linux features called "Cygwin". Also there is a tool in subversion 1.7 called svnpatch that will do the job.

Wow, I had no idea Cygwin was still maintained, available, etc. It's been many years since I used it (Windows just needs some stuff like ls...) and good to know it's still available.

I agree the conditions that cause the problem are obscure enough that one could easily get by without the patch, I was just interested in taking a peek at the sources, but it now sounds like that's taking a much larger bite than I planned.

If you (or anyone else) makes a windows .exe with the patches, it would be nice to share it, since the update sounds like it's a long way off.

The more I explore this simulator, the more impressed I am; thanks again Barry for the comments that encouraged me to look closer.

[rprosperi]

(11-22-2015 05:48 AM)BarryMead Wrote:  I used the windows version of freewrap to create a windows .exe file as you requested. I created the entire directory with all of the parts needed to run the simulator.

Wow, super service with a smile. Thanks so much Barry. I will send a PM with my email, no problem with the size and instructions sound trivial to just drop it in to replace the existing .exe from the website download. BTW, I'm using x64 Win-7 and Win-10; it appears from the folder name that x64 is supported.

I am not at all familiar with TCL. It sounds like freewrap takes all the components from the normally installed run-time/environment and "wraps" it into a standalone .exe file? Convenient.

I'll send you feedback via PM unless you prefer it here. Hope my request has not lead to lots of work; it does sound like you are very familiar with this stuff and enjoy doing it.

Thanks once again.

[Marcus von Cube]

Hi Barry,

thanks for your efforts. My Mac has wish installed (version 8.5.9) and runs the .tcl file directly I just need to find out how to create a shortcut from it.

[BarryMead]

(11-22-2015 05:37 PM)Marcus von Cube Wrote:  Hi Barry,

thanks for your efforts. My Mac has wish installed (version 8.5.9) and runs the .tcl file directly I just need to find out how to create a shortcut from it.

Marcus:

For the Mac try unzipping the HP-15C_3.4.00_Source.zip file to a location you like, overwrite the HP-15C.tcl with the one from the 3402.zip file above, then create a bash script and make it's permissions executable, and point the Desktop Icon to that script file. The script file has only 3 lines like so:

#!/bin/bash
cd DirectoryWhereYouUnzippedSource
wish HP-15C.tcl

I think this will work on a Mac, but I haven't tried it yet.

The rest of this posting is for Windows 7 (64 bit) users.

You will need the directory structure created by unzipping (extracting) the HP-15C_3.4.00_Source.zip file downloadable from the "Source Release" selection on Torsten's site here.
Then overwrite the HP-15C.tcl in that directory with the one you get by unzipping the 3402.zip file above. The following example shortcut assumes you downloaded the Source zip file into the C:\Users\Yourname\Downloads directory.
If you put it somewhere else, then you need to modify the instructions below accordingly.

Then right click on your open desktop and select "New" then pick "Shortcut"

Type "wish C:\Users\Yourname\Downloads\HP-15C_3.4.00_Source\HP-15C.tcl" into the command box.
For the "Start In" directory choose "C:\Users\Yourname\Downloads\HP-15C_3.4.00_Source".
You may have to provide the full path name of the wish command as well depending
on weather it is installed in a directory listed in the %PATH% environment variable or not.

You can change the shortcut's icon by right clicking on the desktop icon and selecting "Preferences" then choose "Change Icon" and "Browse", and select an icon from the C:\Users\Yourname\Downloads\HP-15C_3.4.00_Source\icons
directory to make your new shortcut icon look more representative of the Simulator.

Hope this helps, Barry

[BarryMead]

Marcus:

I updated the posting above to include a solution for the Mac, that I believe will work.

Give it a try, and let me (and other Mac users) know if it worked for you.

Thanks, Barry

[Marcus von Cube]

Hi Barry,

don't worry, it's already running. The only "problem" is that I need to resort to the command line so far. I'm pretty sure I can make it work from a shortcut (an alias in Mac speak).

A few hours later...

It works, but it isn't pretty. I've created a shell script to run wish in the correct folder.

[BarryMead]

(11-22-2015 05:48 AM)BarryMead Wrote:  When you run the simulator, make sure you UNCHECK the check box in the "Menu/Preferences/Files" tab that says "Encode programs in UTF-16 (LE)". I found that if you try to save a program when this checkbox is on, it will be corrupted when you try to reload it. I have already reported this bug to Torsten, and we are working on getting it fixed.
Enjoy, Barry

The Unicode Save Bug is now fixed for all systems Linux, Windows, and Mac. The 3402.zip file above has been updated to include the fix for the unicode save bug. Which by the way was only happening on Linux and Mac systems not on 64-bit Windows systems.

[BarryMead]

There was a boundary condition error in both the FRAC and INT functions.

The values 1.0 and -1.0 were returning the wrong values for both functions.
The 3402.zip file above has been updated to correct these bugs.

Happy Holidays, Barry

[BarryMead]

I discovered another bug in the HP-15C Simlator and after reporting it to Torsten, he quickly came up with the solution which has been incorporated into the 3402.zip file
shown in the posting above.

Enjoy, Barry