DB48X: HP48-like RPL implementation for DM42

[c3d]

(Yesterday 05:05 PM)n1msr Wrote:  This post is only by way of discussion. Not complaining, but just interested :-)

In experimenting with RPL programs written for the HP-50g, I came across what looks like a difference between the DB48X and HP-50g. I have looked through some of the documentation for both calculators but haven't found an explicit description to explain the difference.

This has come about partly because not all HP-50g functions have been implemented on the DB48X yet - in this case the Real to Integer (R->I), which was used by several entries in the 2011 HHC programming contest.

Good point. I never implemented that, it's easy enough to do (the internal functions all exist).

Quote:It becomes important when the Comb[inations] function is used, because:

On the DB48X, it seems that the two parameters, n & r (for nCr) have to be Real Integers (type 28 objects). The result is a Real Integer.

The HP-50g doesn't seem to care. You can use Real Integers (Type 28), Real Numbers (Type 0) or mix them. If either input is a Real Number, the result will be a Real Number. If both inputs are Real Integers, the result is a Real Integer.

For clarity, and since we are in a discussion, the type names you used above are those documented in the HP50G advanced user reference manual, and I dislike them with a passion. "Real integer" is a mathematical nonsense, and "Real number" is inaccurate because of the limited precision of the calculator. In any case, these are HP50G data types.

DB48x has a different terminology, which I believe is more precise, which corresponds to entirely different underlying data types.

- "integer" denotes integer values. They can have arbitrary precision, being encoded using LEB128 (7 bits of data per byte), but the calculator typically only uses that format for values that fit on 64-bit.

- Above that point, there is a crossover with "bignum", which is also arbitrary precision, but with an LEB128-encoded length and 8 bits of data per byte. You can check that 63 bits is 9x7bits plus a 1-byte type, so the largest optimal "integer" value is 9+1=10 bytes. 64 bits is 8x8bits + 1-byte length (coding the number of bytes, 8, in LEB128, + 1-byte type, which is also 10 bytes. Above 64-bit, the bignum format becomes more efficient, so that is what is being used.

- All these only hold unsigned values, so there are neg_ variants for negative values.

- The types can also be used for based numbers, so that are also based_ variants, e.g. based_integer and based_bignum.

- Decimal values are stored in the variable-precision "decimal" type (not "real" precisely because it belongs to the mathematical D set and not R).

- IEEE754 hardware-accelerated 32-bit and 64-bit floating-point values are called hwfloat and hwdouble, carrying the ridiculously inconsistent names of the underlying C++ types ("float" being an implementation detail, the format, "double" being another implementation detail, the precision).

That being said, you are entirely correct that:

a) COMB and PERM do not accept decimal or hwfloat input, which is a bug.

b) R->I is not implemented, which is a glaring missing feature, that I will cowardly blame, to the fullest extent permissible by law, on this universe only featuring 24 hours per day.

c) There is currently no correct way to convert a decimal to an integer. There is, however, an incorrect way, with the ->Frac or CYCLE functions, which, when given a non-fractional decimal input, happens to produce an integer. Problem is that they accept a fractional value and produce a fraction, but maybe that's what you want because then COMB or PERM will fail.

Quote:Until R->I is implemented I was going to resort to using only Real Numbers is these programs, except that Comb[inations] won't use Real Numbers. I could of course do the nCr calculation using factorial (x!), where nCr = n! / (r! * (n-r)!). The DB48X factorial function will take both Real Integers and Real Numbers :-)

Yes, but that raises an interesting question. If you compute COMB with 2.3 and 4.5 as input, the HP50G raises a Bad Argument Value error. By contrast, every HP calculator since at least the HP15C interprets x! as being derived from the Gamma function for fractional values. This means that the formula for nCr works just fine with fractional values.

So the question is: should a version of COMB that accept decimal input also accept fractional input and use the Gamma function to compute the result? I vote in favor of that personally, unless someone can prove that this would instantly destroy a non-negligible fraction of the known universe.

Quote:I did wonder if there is a setting I could make in the DB48X calculator to change the way the functions behave, i.e. accept Real Numbers as well as, or instead of Real Integers?

There is no setting to workaround that specific bug, because it's a bug. Internally, the bug is as follows: functions that take an integer input but should accept a decimal and truncate it to an integer (e.g. FIX) use an internal routine designed for that very purpose, that does all the type analysis and truncation correctly. For some reason, the idiot who wrote the code for COMB and PERM decided to explicitly test if the value was an "integer" type.

I'm allowed to write "idiot" because I personally know that idiot very well. And I can tell from reading the code that the intent was to mimic the HP50G behaviour and give a Bad Argument Value for fractional input, as shown by this code:

Code:


    if (n->is_real() && m->is_real())
        rt.value_error();
    else
        rt.type_error();

This is fixed on dev now, meaning that it will be fixed in 0.8.9.