Possible bug on HP50G with very large numbers

[Gil]

Always on a HP50G

1)280! gives
167... —> a correct number

And Log(167...) gives
69+Log(167...)

that is
69+496.22=565.22

which is a 566 digit
and that is correct.


2)281! gives
471... —> a correct number

And Log(471...) gives
69+Log(471...)

that is
69+498.67=567.67

which is a 568 digit
and that is correct.

3)282! gives
1329... —> a correct number

BUT Log(1329...) gives
69+Log(1329..)

that is
69+(exactly ?! 500)

which is a 569 digit
and that is clearly WRONG.

Strange isn't?

Gil

[John Keith]

Confirmed. Same answer for 283! Clearly a bug in LOG.

[Dave Britten]

Using this algorithm for lngamma, my 48 returns 570.1235 for lngamma(283)/ln(10), and 572.5753 for lngamma(284)/ln(10). I do believe you have found something fishy going on.

I don't have my 50g handy; does LOG top out at 569 if you keep doing larger and larger factorials?

[Werner]

I think I've seen it before; and that the problem is that LOG of integers is actually performed converting the integer to a real first, which is not possible with an integer > 1e500. Yes, it should error out on that, but it doesn't.

Cheers, Werner

[toml_12953]

You're right. The error does exist. I don't hold out any hope for a firmware revision to correct it, though since the 50g is a dead product (dead as in not in production anymore, not dead as in not used!)

[DavidM]

Interesting find!

If your intent is to determine the digit length of the resulting integer from the factorial operation on a 50g, a possible work-around is to simply execute SIZE on the result.

(exact mode assumed)

Code:

282 FACT SIZE

...produces "571." (fraction mark depending on mode, of course).

If you really do need the LOG, the LONGFLOAT library appears to provide an option:

(exact mode assumed)

Code:

282 FACT R←→F FLN 10 R←→F FLN FDIV R←→F

...produces "570.123547475".

[Carsen]

(10-28-2019 12:38 PM)Werner Wrote:  I think I've seen it before; and that the problem is that LOG of integers is actually performed converting the integer to a real first, which is not possible with an integer > 1e500. Yes, it should error out on that, but it doesn't.

Cheers, Werner

It does error out if system flag 21 is set.

[Wes Loewer]

(I wrote this before I noticed that others gave explanations, but I figured I might as well post this since I typed it out.)

This is not bug at all but rather the floating point number simply overflowing.

LOG(281!) = 69 + LOG(a 499 digit number) = 69 + LOG(4.71301006165E498) = 69 + 498.673298367 = 567.673298367, so a 568 digit number

LOG(282!) = 69 + LOG(a 502 digit number) = 69 + LOG(overflow to 9.99999999999E499) = 69 + 500 = 569, but not really a 569 digit number because of the overflow

If you go to MODE and set system flag 21 to make overflow an error, you'll see that LOG(281!) works but LOG(282!) produces an Overflow error message.

Sometimes it's best to have overflow produce an error rather than produce an incorrect value. Other times, you just want the biggest floating point number the calculator can produce. It's your choice.

[Gil]

Yes, I quite understand and agree with your answer.

Two observations

1) x! =for x >281 corresponds to a very large number and nevertheless the HP50G calculator manages quite well the calculation.

2) Let y = log(300!) = log(30605...).
And the calculator should give the right approximation
instead of an unexpected answer.
For instance, let z = size (300!) by reckoning
« 300! —>STR SIZE ».
Then y = log(3.0605) * 10^(z)
=. 4858 * 10^z
= 4.858 * 10^(z-1).

[Claudio L.]

(10-30-2019 02:46 AM)Gil Wrote:  Yes, I quite understand and agree with your answer.

Two observations

1) x! =for x >281 corresponds to a very large number and nevertheless the HP50G calculator manages quite well the calculation.

2) Let y = log(300!) = log(30605...).
And the calculator should give the right approximation
instead of an unexpected answer.
For instance, let z = size (300!) by reckoning
« 300! —>STR SIZE ».
Then y = log(3.0605) * 10^(z)
=. 4858 * 10^z
= 4.858 * 10^(z-1).

I agree with both of these statements:

a) Not a bug, works as intended

but also

b) Come on, it was so easy to get it done right...

[Gerald H]

For log base 10 have a look at this programme:

https://www.hpmuseum.org/forum/thread-39...t=gerald+h

[Claudio L.]

(11-01-2019 07:41 AM)Gerald H Wrote:  For log base 10 have a look at this programme:

https://www.hpmuseum.org/forum/thread-39...t=gerald+h

That's exactly my point. It's not really a bug, but it was just a few more lines of code... thanks for the contribution!

[Wes Loewer]

(11-01-2019 07:41 AM)Gerald H Wrote:  For log base 10 have a look at this programme:

https://www.hpmuseum.org/forum/thread-39...t=gerald+h

Or for a UserRPL program, how about

<< DUP SIZE "." ROT + OBJ-> LOG + >>

[Gerald H]

For input

234070

your programme gives an incorrect answer.

[Wes Loewer]

(11-02-2019 04:11 PM)Gerald H Wrote:  For input
234070
your programme gives an incorrect answer.

The program gives 5.36934575514 instead of 5.36934575513, which I think is as good as a UserRPL can get using real numbers. The correct rounding would require sysRPL's extended reals (or a more sophisticated program).

This example is an interesting one. The answer to 16 decimal places is 5.369345755134671 which when rounded to 12 significant digits is 5.36934575513. The program calculates -0.630654244865 + 6 which would have been 5.369345755135 but is rounded to 5.36934575514. It's the classic case where having fewer significant digits happens to give a better answer than having more.

Code:

5.36934575513     12 significant digits
5.369345755135    13 significant digits, rounds to 5.36934575514
5.3693457551347   14 significant digits, rounds to 5.36934575513 again