Re: 50G precision & accuracy
Message #12 Posted by Crawl on 17 May 2012, 11:15 a.m.,
in response to message #2 by Crawl
Maybe I'll go through some of the bugs to see how they'd perform on the 50g.
Quote:
Cos(x) for x near 90 is dud
cos(3.14159265/2) = 1.79489661923e-9
The TI89 only returns 1.7949e-9.
All digits appear to be correct, based on the Taylor series.
Quote:
Checksums are meaningless.
Checksums are essential for sharing programs on a calculator where the only way of entering them is by manually keying them in. It's possible to share HP50g programs through USB with essentially no risk of a mistake. Nevertheless, the 50g does have a CKSM command (which I've never used). It seems to be a way of checking for error when transmitting data from one calculator to another through IR.
Quote:
TANH, SINH and COSH all have bugs when applied to large values. An OVERFLOW message given when computing TANH for values greater than or equal to 30000. The TANH value is correct, 1, but the OVERFLOW message is wrong. SINH and COSH generate the OVERFLOW message correctly, but return the wrong values. Overflow is supposed to return 1E500, but with an argument greater than or equal to 30000 SINH and COSH return the mantissa of the argument and the characteristic is changed to 499. e.g. SINH 31415 = OVERFLOW --> 3.1415E499
1000000 TANH returns 1. in approx. mode. 30000 SINH depends on Flag settings. You can either have it generate an error (leaving the stack unchanged) or go to 9.999....E499.
Quote:
LBL A
156.25
STO X
208.333333334 ;There are eight 'threes' in there
STO R
1.77951304201
STO Q
-R*X/(X*Q-R) ;Should evaluate to roughly -467, and it does
-R*X/(X*Q-R) ;Should (still) evaluate to roughly -467, but
calculator outputs 31.323 instead!
RTN
Utterly baffling. Does anyone have an idea why the 35s does this?
Quote:
Input of numbers in bases other than 10 require the suffix to be explicitly entered. This makes non-base 10 unworkable.
Honestly, I've never use the 50g in different bases before. I'll usually pull out a scientific.
It does seem you have to enter the # symbol first. At least it might have been nice to either
1. Have the # symbol be part of the base soft menu.
2. Have a special "base enter" key be part of the base soft menu, so if you've keyed in AB1F and hit it, it would automatically interpret it as a hex number, *and* enter it on the stack, thus costing no extra keystrokes at all.
It seems like, as a work around, it should be possible to write a program to do that for you, but my first stabs at doing that didn't work for some reason.
"#" SWAP + OBJ->
works if the entry is all numbers (eg., 123) or begins with letters (eg., AB123) but fails if it beings with numbers but has letters (eg., 123AB). Also, it must be in exact mode to work with numbers. I think all this is quirky, at the least.
I did notice what seems to be another bug on this experiment. If you select the string "123." on the stack and copy it, it pastes as the pure number 123.
Anyway, a lot of the 35s bugs can't possibly apply to the 50g, because they relate to ways the 35s does things that the 50g does not, eg., keystroke programming rather than RPL.
Edited: 17 May 2012, 11:18 a.m.
| 
Go back to the main exhibit hall