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
Confirmed. Same answer for 283! Clearly a bug in LOG.
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?
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
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!)
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)
...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 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.
(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.
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).
(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...
For input
234070
your programme gives an incorrect answer.
(11-02-2019 04:11 PM)Gerald H Wrote: [ -> ]For input
234070
your programme gives an incorrect answer.
The program gives 5.3693457551
4 instead of 5.3693457551
3, 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.3693457551
34671 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