Why does Intelligent math give this strange answer?

[KenL]

When I select "Intelligent math" in settings I get a strange result with simple equation (non-cas)

(1+1/365)^365

It essentially gives a result of "1"

See enclosed image

   

[Steve Simpkin]

The TI-89 gives a slightly different answer of 2.71456748202.
   

Wolfram Alpha provides: 2.7145674820218743031938863066851106287262091263030635433387435894...
Which matches the 12-digits of the TI-89.

[nickapos]

(02-26-2024 02:58 AM)Steve Simpkin Wrote:  The TI-89 gives a slightly different answer of 2.71456748202.


Wolfram Alpha provides: 2.7145674820218743031938863066851106287262091263030635433387435894...
Which matches the 12-digits of the TI-89.

I am getting 2.71456748459 on my app which does not have an option for intelligent math at all and this matches the results on my physical device with the latest firmware and with intelligent math enabled.
Not sure why intelligent math is missing on my app which is the latest.

[KenL]

(02-26-2024 06:14 AM)nickapos Wrote:  

(02-26-2024 02:58 AM)Steve Simpkin Wrote:  The TI-89 gives a slightly different answer of 2.71456748202.


Wolfram Alpha provides: 2.7145674820218743031938863066851106287262091263030635433387435894...
Which matches the 12-digits of the TI-89.

I am getting 2.71456748459 on my app which does not have an option for intelligent math at all and this matches the results on my physical device with the latest firmware and with intelligent math enabled.
Not sure why intelligent math is missing on my app which is the latest.

Regarding your physical device, please make sure you are not in the CAS mode, Is it still the correct answer?

[rawi]

Quote: When I select "Intelligent math" in settings I get a strange result with simple equation (non-cas)

(1+1/365)^365

It essentially gives a result of "1"

This is confirmed in non-CAS-mode with the physical device. I get the same result 9.9999..E499/9.9999...E499.
If I compute approx(9.9999..E499/9.9999...E499) I get the result "Undefined".

[rawi]

I tried with (1+1/100)^100 and I got 2,70481..E200/1E200.

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.

[Nigel (UK)]

You’ve typed in an exact expression - no decimal points in any of your numbers - so it tries to evaluate it exactly, as a rational number. Both numerator and denominator overflow, so this fails. (Also, Home mode doesn’t have large integers.)

I think this is acceptable. What I don’t like is that putting a decimal point in one of the numbers (i.e., 1. instead of 1) doesn’t change this behaviour.

CAS mode is better here - it gives the exact rational answer with no decimal, and the numerical answer if I put “365.” in the denominator.

Nigel (UK)

[KenL]

(02-26-2024 02:45 PM)Nigel (UK) Wrote:  You’ve typed in an exact expression - no decimal points in any of your numbers - so it tries to evaluate it exactly, as a rational number. Both numerator and denominator overflow, so this fails. (Also, Home mode doesn’t have large integers.)

I think this is acceptable. What I don’t like is that putting a decimal point in one of the numbers (i.e., 1. instead of 1) doesn’t change this behaviour.

CAS mode is better here - it gives the exact rational answer with no decimal, and the numerical answer if I put “365.” in the denominator.

Nigel (UK)

Excellent! Thank you

[John Keith]

(02-26-2024 02:26 PM)rawi Wrote:  I tried with (1+1/100)^100 and I got 2,70481..E200/1E200.

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.

The HP50 gets the same answer which is notably less accurate than the TI.

EVALuating the expression in exact mode returns, after a long calculation, a fraction with 936-digit numerator and denominator. Converting to an approximate number also returns 1. However, taking the first 20 digits of the numerator and denominator, dividing and converting to approximate, return the correct value 2.71456748202.

Clearly the Prime and the HP50 both have problems with fractions having very large terms.

[Steve Simpkin]

Here are answers from some of the calculator models I had handy.

TI-57:
2.714567

TI-59:
2.714567482

TI-86, TI-95, TI-89, WP 34S:
2.71456748202

TI-34 MultiView, TI-36X Pro:
2.714567482

Casio fx-8000G, fx-115ES PLUS, fx-991EX, fx-CG50:
2.714567482

HP-35, HP-25:
2.714567463

HP-27, HP-67, HP-34C, HP-41C, HP-15C, HP-12C:
2.714567455

HP-48SX, HP-48GX, HP-42S:
2.71456748459

HP 50g (aprox mode):
2.71456748459

HP 35s:
2.71456748459

Free42 (decimal):
2.714567482021874303193886306685083

WP43:
2.714567482021874303193886306685084

Sharp EL-W535X:
2.714567482

[klesl]

Canon F-605G, Sharp EL-510RT, Sharp EL-9950, Casio fx-5800, TI-74,
2.714567482
Sharp EL-501TB, Sharp EL-5500II, Sharp PC-1403, Casio fx-82 Solar II with fraction
2.7145677475
TI-57 II
2.7145677
Citizen SRP-75
2.714567485

[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.

[J-F Garnier]

(02-28-2024 04:31 PM)DavidM Wrote:  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.

Exactly !
Also on the 41C:
365 ENTER 1/x LN1+X * EXP --> 2.714567481

Or in the other way, calculating with the same 10-digit input number (1.002739726)^365 on every machine gives very close results, except the early HP (before the HP22/HP27 improvement):
HP-41C: 2.714567455
HP-42S: 2.71456745495
Free42 : 2.714567454950368...
No "errors", all machines are doing their best, the fault entirely to the input value.

J-F

[parisse]

f:=(1+1/365)^365 in CAS returns a fraction with numerator and denominator having about 900 digits, evalf(f) returns 2.71456748202, seems correct.