50G precision & accuracy


Hello all.

I'm wondering if the 50G is built from an entirely different architecture, processor and algorithms/microcode than the 33S. 35S, or predecessors. If so, and its build is entirely different, what are the 50G's accuracy benchmarks (i.e. does it have any of the accuracy bugs listed in the infamous '35S Bug List')?



No, the 50g is very good. I think it's better than the 15C in terms of accuracy.




3.58979323846 x 10-9

which you'll notice is the first 20 decimal places of pi.

The 15C returns only



The HP-71B also gives:



as well.

This post ( The Turtle and the Hare ) and its sequel Part 2 includes lots of math-related tests with plenty of results for assorted HP machines which the OP might find useful to check both run times and accuracy.

Regards from V.


Thanks! I'll dive into that post.


Which doesn't agree with Mathematica or Wolfram Alpha, both of which give 3.5897930298416118 E-09.


The taylor series for sin(x) around pi is

pi -x + (x-pi)^3/6 ...

This means if you put as x a number that's very close to pi, minus a few digits, the sine will be the remaining digits of pi, until you get to the remainder.

In this case, the remainder is


Far too small to show in the digits I quoted.

The 50g is right, Wolfram Alpha is wrong.
Not the first time.


Actually, checking it with Wolfram Alpha gives me the same thing that the 50g gives. I'm not sure what you did differently.


I entered NumberForm[Sin[3.14159265],{13,12}] in Wolfram Alpha which returns the result I previously posted. If I enter N[Sin[3.14159265],12] I get the correct result. I guess I don't understand why they yield different results.


Which makes me wonder...if the 50G accuracy benchmark is superior, what is preventing HP from revising/replacing the 33S & 35S with the 50G algorithms? Or would that take too much ROM which would either make the 33S & 35S higher in price or, the ROM size for these modifications would be too much demand on the memory, processor limitations inherent to the design specs of the 33S & 35S?


From what I know, the RPL (Saturn) series of calculators uses a common math lib which has later been translated to C for inclusion in more recent designs such as the 20b/30b or 10bII+ (to my knowledge by Cyrille de Brébisson). The trouble with the 33s and 35s is that they are not using this library, at least not the most recent version. Development for these calculators had been sourced to external programmers which obviously didn't do everything to specs (or the specs weren't complete). Sadly, this development has ceased so that the 33S and 35S will never be improved.


Which doesn't agree with Mathematica or Wolfram Alpha, both of which give 3.5897930298416118 E-09.

Too bad for both of them as the correct answer is:


and the above results agree with it.

Anyway Wolfram Alphilth will show you the correct result if you beg for "More digits..." though it won't condescend to let you copy the plain-text result unless you suscribe ... that'll be the day ...

Regards from V.

Edited: 16 May 2012, 4:13 p.m.


Maybe I'll go through some of the bugs to see how they'd perform on the 50g.

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.

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.

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.

208.333333334 ;There are eight 'threes' in there
-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!

Utterly baffling. Does anyone have an idea why the 35s does this?

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.

Possibly Related Threads...
Thread Author Replies Views Last Post
  HP Prime numerical precision in CAS and HOME Javier Goizueta 5 865 11-16-2013, 03:51 AM
Last Post: Paul Dale
  How much accuracy does one actually need? Matt Agajanian 23 1,923 08-26-2013, 12:46 PM
Last Post: Kimberly Thompson
  [wp34s] Converting to/from IEEE 754 Binary64 (Double Precision) David Maier 1 418 06-15-2013, 09:21 PM
Last Post: Paul Dale
  Precision DC-50 Mic 3 656 05-26-2013, 01:27 PM
Last Post: DavidM
  Estimating accuracy in finite precision computations mpi 17 1,601 02-22-2013, 09:44 AM
Last Post: mpi
  WP 34S accuracy is excellent Jeff Johnson 15 1,312 06-01-2012, 10:41 PM
Last Post: Valentin Albillo
  Accuracy of Woodstocks Matt Agajanian 7 811 03-25-2012, 06:54 PM
Last Post: Eric Smith
  HP-35 Accuracy Threshhold Matt Agajanian 0 266 03-22-2012, 09:56 PM
Last Post: Matt Agajanian
  accuracy of integration and solve routines HP 15C LE Jan 3 517 02-02-2012, 01:03 PM
Last Post: Marcus von Cube, Germany
  WP 34S: Double precision registers - What are your feelings? Marcus von Cube, Germany 16 1,564 12-26-2011, 10:49 AM
Last Post: Dieter

Forum Jump: