Why does Intelligent math give this strange answer?

[DavidM]

(02-26-2024 02:26 PM)rawi Wrote:  So this seems to be an overflow.

If you put in (1-1/365)^365 and use the approx key (blue - enter) you get 2.71456748459.

I don't have a Prime, but I believe the processing in this case is similar to what happens with the 50g. On the 50g, there is a system flag (-21) that controls whether an overflow triggers an error (-21 is SET), or simply uses the "maximum real" of 9.99999999999E499 and keeps on processing (-21 is CLEAR). The default status for the flag is cleared, meaning no error is thrown. Setting system flag -21 on the 50g will cause an overflow error to be thrown when attempting to convert the exact fractional result to an approximate number with ->NUM.

Clearing system flag -21 essentially tells the 50g to cap any numeric values to 9.99999999999E499 (or the corresponding negated value for negative numbers). Thus, in this case, returning "1." since the fractional result simply becomes 9.99999999999E499/9.99999999999E499.

Does the Prime also have a similar "overflow mode" for this?

Regarding the accuracy of the approximate results, I believe we're simply seeing the difference that the lack of guard digits makes for this type of expression. The HP calculators giving a result of 2.71456748459 are giving the most accurate result they can given all the numeric values in the calculation are limited to 12 significant digits.

In particular for this example, digits are lost when adding 1 to 1/365, a typical scenario for financial calculations and perhaps one of the main reasons that the LNP1 and EXPM functions were included in some of the calculators.

Executing this on a 50g:

Code:

« 365. INV LNP1 365. * EXP »

...provides a much closer result of 2.71456748203 to what we might expect.