[Free42] Numbers reformatted in program mode - Printable Version +- HP Forums (https://www.hpmuseum.org/forum) +-- Forum: Not HP Calculators (/forum-7.html) +--- Forum: Not quite HP Calculators - but related (/forum-8.html) +--- Thread: [Free42] Numbers reformatted in program mode (/thread-11104.html) |
[Free42] Numbers reformatted in program mode - ijabbott - 07-22-2018 10:33 AM 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. RE: [Free42] Numbers reformatted in program mode - Didier Lachieze - 07-22-2018 11:03 AM This is documented on the Free42 FAQ: Quote:In programs, numbers are normalized RE: [Free42] Numbers reformatted in program mode - Thomas Okken - 07-22-2018 03:24 PM 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! RE: [Free42] Numbers reformatted in program mode - ijabbott - 07-22-2018 04:40 PM 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)? RE: [Free42] Numbers reformatted in program mode - Thomas Okken - 07-22-2018 05:40 PM (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. RE: [Free42] Numbers reformatted in program mode - Werner - 07-23-2018 07:27 AM (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 RE: [Free42] Numbers reformatted in program mode - ijabbott - 07-23-2018 07:37 AM (07-22-2018 05:40 PM)Thomas Okken Wrote: Yes, Free42 will handle all .raw files correctly, regardless of how numbers are formatted. That's good to know, thanks! RE: [Free42] Numbers reformatted in program mode - Paul Dale - 07-23-2018 08:21 AM 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 12th can be rounded away which gives a solution. Pauli RE: [Free42] Numbers reformatted in program mode - Thomas Okken - 07-23-2018 03:25 PM (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 12th 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. |