Possible bug on HP50G with very large numbers

10282019, 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 

10282019, 11:40 AM
Post: #2




RE: Possible bug on HP50G with very large numbers
Confirmed. Same answer for 283! Clearly a bug in LOG.


10282019, 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? 

10282019, 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 

10282019, 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? 

10282019, 01:37 PM
(This post was last modified: 10282019 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 workaround 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". 

10282019, 08:26 PM
Post: #7




RE: Possible bug on HP50G with very large numbers
(10282019 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. It does error out if system flag 21 is set. 

10292019, 05:57 PM
(This post was last modified: 10292019 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. 

10302019, 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^(z1). 

10302019, 09:17 PM
Post: #10




RE: Possible bug on HP50G with very large numbers
(10302019 02:46 AM)Gil Wrote: Yes, I quite understand and agree with your answer. 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... 

11012019, 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/thread39...t=gerald+h 

11012019, 02:38 PM
Post: #12




RE: Possible bug on HP50G with very large numbers
(11012019 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! 

11022019, 01:57 PM
(This post was last modified: 11022019 01:58 PM by Wes Loewer.)
Post: #13




RE: Possible bug on HP50G with very large numbers
(11012019 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 + >> 

11022019, 04:11 PM
Post: #14




RE: Possible bug on HP50G with very large numbers
For input
234070 your programme gives an incorrect answer. 

11022019, 07:44 PM
(This post was last modified: 11032019 03:42 AM by Wes Loewer.)
Post: #15




RE: Possible bug on HP50G with very large numbers
(11022019 04:11 PM)Gerald H Wrote: For input 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 

« Next Oldest  Next Newest »

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