Post Reply 
Possible bug on HP50G with very large numbers
10-28-2019, 10:10 AM
Post: #1
Possible bug on HP50G with very large numbers
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
Find all posts by this user
Quote this message in a reply
10-28-2019, 11:40 AM
Post: #2
RE: Possible bug on HP50G with very large numbers
Confirmed. Same answer for 283! Clearly a bug in LOG.
Find all posts by this user
Quote this message in a reply
10-28-2019, 12:22 PM
Post: #3
RE: Possible bug on HP50G with very large numbers
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?
Visit this user's website Find all posts by this user
Quote this message in a reply
10-28-2019, 12:38 PM
Post: #4
RE: Possible bug on HP50G with very large numbers
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
Find all posts by this user
Quote this message in a reply
10-28-2019, 01:23 PM
Post: #5
RE: Possible bug on HP50G with very large numbers
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!)

Tom L
Cui bono?
Find all posts by this user
Quote this message in a reply
10-28-2019, 01:37 PM (This post was last modified: 10-28-2019 02:36 PM by DavidM.)
Post: #6
RE: Possible bug on HP50G with very large numbers
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".
Find all posts by this user
Quote this message in a reply
10-28-2019, 08:26 PM
Post: #7
RE: Possible bug on HP50G with very large numbers
(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.
Find all posts by this user
Quote this message in a reply
10-29-2019, 05:57 PM (This post was last modified: 10-29-2019 05:58 PM by Wes Loewer.)
Post: #8
RE: Possible bug on HP50G with very large numbers
(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.
Find all posts by this user
Quote this message in a reply
10-30-2019, 02:46 AM
Post: #9
RE: Possible bug on HP50G with very large numbers
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).
Find all posts by this user
Quote this message in a reply
10-30-2019, 09:17 PM
Post: #10
RE: Possible bug on HP50G with very large numbers
(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...
Find all posts by this user
Quote this message in a reply
11-01-2019, 07:41 AM
Post: #11
RE: Possible bug on HP50G with very large numbers
For log base 10 have a look at this programme:

https://www.hpmuseum.org/forum/thread-39...t=gerald+h
Find all posts by this user
Quote this message in a reply
11-01-2019, 02:38 PM
Post: #12
RE: Possible bug on HP50G with very large numbers
(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!
Find all posts by this user
Quote this message in a reply
11-02-2019, 01:57 PM (This post was last modified: 11-02-2019 01:58 PM by Wes Loewer.)
Post: #13
RE: Possible bug on HP50G with very large numbers
(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 + >>
Find all posts by this user
Quote this message in a reply
11-02-2019, 04:11 PM
Post: #14
RE: Possible bug on HP50G with very large numbers
For input

234070

your programme gives an incorrect answer.
Find all posts by this user
Quote this message in a reply
11-02-2019, 07:44 PM (This post was last modified: 11-03-2019 03:42 AM by Wes Loewer.)
Post: #15
RE: Possible bug on HP50G with very large numbers
(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
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 1 Guest(s)