A new RPL firmware for the 50g

[Paul Dale]

If REALs are double, extended reals shouldn't be decimal128 -- the conversion between the two is horrendous and inaccurate. I contemplated the reverse for a while, you get lots of rounding issues that make correct rounding very difficult if not impossible.

I'd use either double and long double or decimal64 and decimal128. I wouldn't expose decNumber to the user -- internally it will be required but it is quite space inefficient. Fortunately, conversion from decimal64 or decimal128 to decNumber and back is fast.

For reference, OpenRPN supported both binary and decimal reals as separate types. For a scientific calculator, I don't see a significant problem with using binary reals. Many others would hate this however.

One other thing I have contemplated is for the function to decide its return type -- e.g. SIN would always return a binary real rather than a decimal one because there is no benefit staying decimal here. The advantage being that there is lots of high quality numeric code written for binary reals but not for decimal ones.


I'd make BINT either 64 bit or unlimited length. Again OpenRPN has a fairly comprehensive integer suite predominately written in RPL. Integers there being 64 bits but with a word size setting like HP's RPL devices.


- Pauli