Possible bug on HP50G with very large numbers
10-28-2019, 10:10 AM
Post: #1
 Gil Member Posts: 197 Joined: Oct 2019
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
10-28-2019, 11:40 AM
Post: #2
 John Keith Senior Member Posts: 721 Joined: Dec 2013
RE: Possible bug on HP50G with very large numbers
Confirmed. Same answer for 283! Clearly a bug in LOG.
10-28-2019, 12:22 PM
Post: #3
 Dave Britten Senior Member Posts: 1,928 Joined: Dec 2013
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?
10-28-2019, 12:38 PM
Post: #4
 Werner Senior Member Posts: 648 Joined: Dec 2013
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
10-28-2019, 01:23 PM
Post: #5
 toml_12953 Senior Member Posts: 1,779 Joined: Dec 2013
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?
10-28-2019, 01:37 PM (This post was last modified: 10-28-2019 02:36 PM by DavidM.)
Post: #6
 DavidM Senior Member Posts: 823 Joined: Dec 2013
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".
10-28-2019, 08:26 PM
Post: #7
 Carsen Member Posts: 202 Joined: Jan 2017
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.
10-29-2019, 05:57 PM (This post was last modified: 10-29-2019 05:58 PM by Wes Loewer.)
Post: #8
 Wes Loewer Senior Member Posts: 332 Joined: Jan 2014
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.
10-30-2019, 02:46 AM
Post: #9
 Gil Member Posts: 197 Joined: Oct 2019
RE: Possible bug on HP50G with very large numbers

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
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).
10-30-2019, 09:17 PM
Post: #10
 Claudio L. Senior Member Posts: 1,823 Joined: Dec 2013
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
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...
11-01-2019, 07:41 AM
Post: #11
 Gerald H Senior Member Posts: 1,458 Joined: May 2014
RE: Possible bug on HP50G with very large numbers
For log base 10 have a look at this programme:

11-01-2019, 02:38 PM
Post: #12
 Claudio L. Senior Member Posts: 1,823 Joined: Dec 2013
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:

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!
11-02-2019, 01:57 PM (This post was last modified: 11-02-2019 01:58 PM by Wes Loewer.)
Post: #13
 Wes Loewer Senior Member Posts: 332 Joined: Jan 2014
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:

Or for a UserRPL program, how about

<< DUP SIZE "." ROT + OBJ-> LOG + >>
11-02-2019, 04:11 PM
Post: #14
 Gerald H Senior Member Posts: 1,458 Joined: May 2014
RE: Possible bug on HP50G with very large numbers
For input

234070

11-02-2019, 07:44 PM (This post was last modified: 11-03-2019 03:42 AM by Wes Loewer.)
Post: #15
 Wes Loewer Senior Member Posts: 332 Joined: Jan 2014
RE: Possible bug on HP50G with very large numbers
(11-02-2019 04:11 PM)Gerald H Wrote:  For input
234070

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
 « Next Oldest | Next Newest »

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