[Free42] Numbers reformatted in program mode

[ijabbott]

In Free42, when entering a number such as 1.3e33 into program code, Free42 converts it to a canonical format such as 13e32, whereas the HP-42S leaves the number as typed. I'm not sure if that counts as a bug, but it does alter the program size in bytes.

[Didier Lachieze]

This is documented on the Free42 FAQ:

Quote:In programs, numbers are normalized

This is not actually a difference between Free42 and the HP-42S that causes HP-42S programs to fail in Free42, but it is something that can cause confusion. What's going on?

In programs, the HP-42S stores numbers basically as you enter them. If you want to enter the number 1000 in a program, you can enter 1000, or 1E3; the latter saves one byte, but apart from that, there is no difference.

Free42, on the other hand, stores numbers in programs in floating-point format, which means that the distinction between 1000 and 1E3 is not preserved. When it displays a program line containing a number, it formats the number in whichever way would be the most compact on the HP-42S, so, if you enter 1000, it is displayed as 1E3, but if you enter 10, it is displayed as 10. (When scientific and fixed-point representations are the same length, it chooses the latter, so 100 is displayed as 100, not as 1E2.)

Again, none of this has any effect on how Free42 performs calculations. I am mentioning this here because even though it may appear that Free42 does something differently than the HP-42S, this is a difference you should ignore.

[Thomas Okken]

Some background: Free42 stores numbers in programs in floating-point format, because storing them as a sequence of digits, like the real HP-42S does, would have been too slow.

Speed may not seem like an issue with Free42 today, but one of the platforms I targeted originally was PalmOS 3, which ran on 16 MHz 68000 CPUs, and on that platform, I was barely able to match the speed of the original calculator, so I optimized for speed wherever I could.

Storing numbers as a sequence of digits would have meant performing a decimal-to-binary conversion each time a number line was executed, and those conversions are computationally expensive. Storing numbers in floating-point format AND as a series of digits would have taken up more memory, which was also at a premium in PalmOS.

Given that the limitations that existed back then are no longer an issue, I could fix this, and I would like to, since the current behavior can be confusing, and it would be better to have byte counts that ALWAYS match those in program listings, even when they contain numbers that aren't minimal-length, like 1000 instead of 1E3. The only reason that I haven't done this yet is that it would be a lot of work, and given how minor an issue this is, it has never made it to the top of my to-do list yet... But given that that to-do list is getting shorter, some day I will get around to it. I'm not going to speculate when that will be, though!

[ijabbott]

Thanks for the answer. So can programs be imported from .raw files using a different number format (or even a different endianness for that matter)?

[Thomas Okken]

(07-22-2018 04:40 PM)ijabbott Wrote:  Thanks for the answer. So can programs be imported from .raw files using a different number format (or even a different endianness for that matter)?

Yes, Free42 will handle all .raw files correctly, regardless of how numbers are formatted.

Endianness is not an issue since .raw files are byte streams.

[Werner]

(07-22-2018 03:24 PM)Thomas Okken Wrote:  Given that the limitations that existed back then are no longer an issue, I could fix this, and I would like to, since the current behavior can be confusing, and it would be better to have byte counts that ALWAYS match those in program listings, even when they contain numbers that aren't minimal-length, like 1000 instead of 1E3. The only reason that I haven't done this yet is that it would be a lot of work, and given how minor an issue this is, it has never made it to the top of my to-do list yet... But given that that to-do list is getting shorter, some day I will get around to it. I'm not going to speculate when that will be, though!

I kinda like it as it is, actually ;-)
Cheers, Werner

[ijabbott]

(07-22-2018 05:40 PM)Thomas Okken Wrote:  Yes, Free42 will handle all .raw files correctly, regardless of how numbers are formatted.

Endianness is not an issue since .raw files are byte streams.

That's good to know, thanks!

[Paul Dale]

With BCD coded reals, there is no digit conversion required
A normalisation step would have to be done, so digit entry would be slightly slower than storing the number natively.

It must have been fun dealing with binary floating point numbers and decimal fractions that change the number. 0.1 being converted to 0.1000000000000000055511151231257827021181583404541015625 when stored as an IEEE 64 bit number. I guess digits after the 12^th can be rounded away which gives a solution.


Pauli

[Thomas Okken]

(07-23-2018 08:21 AM)Paul Dale Wrote:  With BCD coded reals, there is no digit conversion required

Yes, and that's why the HP-42S can store numbers that way and still be fast.
It's not as easy with base-10000 or BID, though!

(07-23-2018 08:21 AM)Paul Dale Wrote:  It must have been fun dealing with binary floating point numbers and decimal fractions that change the number. 0.1 being converted to 0.1000000000000000055511151231257827021181583404541015625 when stored as an IEEE 64 bit number. I guess digits after the 12^th can be rounded away which gives a solution.

While I was still supporting PalmOS, and therefore unable to use the Standard C Library, it was a pain. After dropping PalmOS, the code became a lot simpler:

Code:

sprintf(decstr, "%.15e", d);

followed by the existing logic to massage the string representation to match the HP-42S display modes.