HP Forums
MAJOR RESULT DISCREPANCY; 50g vs. 41CX - Printable Version

+- HP Forums (https://archived.hpcalc.org/museumforum)
+-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html)
+--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html)
+--- Thread: MAJOR RESULT DISCREPANCY; 50g vs. 41CX (/thread-109620.html)

MAJOR RESULT DISCREPANCY; 50g vs. 41CX - Edward J Pec - 03-05-2007

I recently found this site and there is a result discrepancy
between the HP-41CX (I own 2 of them; same thing for
both) and the new HP-50g, namely, the numerical result
for the following (done in full floating point, maximum decimals in all attempted evaluations):

{ [3 x (5-(1/9))] / 23 ^3 } + e ^2.5 then sq. root of result

In the 50g, using RPN, the result is 3.49....
In the 41CX, the result is 3.83...

Independent evaluations indicate 3.49... is correct... as
in the 50g User Guide, so what's going on ??

This can not be a rounding error, and the answer can not
be a matter of calculator opinion, so please help my insomnia and tell me what's going on !

Edward (anyone with some info on this can also email me at: epec@nj.rr.com)

Re: MAJOR RESULT DISCREPANCY; 50g vs. 41CX - Dave Hicks - 03-05-2007

On the 41Cs and 41CXs that I happen to have handy, I'm getting 3.49.

I noticed that if I take just the first bit 3x(5-(1/9)) and take the sq root of that - then I get 3.83. Coincidence?

Edited: 5 Mar 2007, 1:51 p.m.

Re: MAJOR RESULT DISCREPANCY; 50g vs. 41CX - Nelson M. Sicuro (Brazil) - 03-05-2007

My 41CV gives 3.490515637 as result, same as my 32S (3.49051563628),TI-52 (3.490515636), Sharp PC1260 (3.4905156362).

Best regards,

Nelson Sicuro

Re: MAJOR RESULT DISCREPANCY; 50g vs. 41CX - Massimo Gnerucci (Italy) - 03-05-2007

Ditto: 3,490515637 on V41


Re: MAJOR RESULT DISCREPANCY; 50g vs. 41CX - Hal Bitton in Boise - 03-05-2007

Hi Edward,

You may want to check your keystrokes on your 41CX('s)...I own 2 of them as well, and both of mine give me 3.490515637. This result is also achieved using my 29C, 34C, 67, 97 and 15C as well, so I think there is no question that it's the correct result. Bear in mind that the stack logic on your 50G (in RPN mode) is a little different than that of a vintage 4 level machine...I know some functions won't work on a 50G unless you bump the command line into level 1 of the stack (by presssing the enter key), where as there is no need to enter on an a pure RPN/four stack level machine. One such function that comes to mind is X<>Y. I was unable to duplicate your 3.83 result even by purposely miss- keying the equation (in several different ways), so if you wanted to post the exact keystroke sequence you are using (on your 41CX), we could take a look at that.

Best regards, Hal

Getting Edward's result - Palmer O. Hanson, Jr. - 03-06-2007

We begin by finding that the square of Edward's HP-41 result is 14.6689... which is very close to the result obtained from the
[3 x (5-(1/9)) part of the proposed problem which is 14.6666... . Then we note that square of 3.49051... is 12.183699... which is close but not quite equal to e^2.5 which equals 12.182439... Then we evaluate the { [3 x (5-(1/9))] / 23 ^3 } part of the problem and find that it is equal to 0.0012054.... If we add that value to e^2.5 and take the square root we get the correct answer. If we add that value to 14 .66666...and take the square root we get 3.8298..., which is the incorrect answer.

Thinking about those results a little will reveal that somehow Edward's RPN sequence doesn't use the e^2.5 value of 12.182439... but instead uses the value of 14.66666... . By working from the back of the problem to the front and inside out and adding a couple of unfortunate ENTER's the following RPN sequence will get the incorrect answer:

where the two ENTER's before the entry of 23, which aren't needed, push the e^2.5 value out of the stack and leave a [3 x (5-(1/9)) value where it should have been.

I don't say this is necessarily the way Edward did it. I only say it is one way he could have done it. The RPN language can yield some strange results if one isn't careful about pushing values up and out of the stack. When an RPN solution goes bad it is reminiscent of the book I used to read to my children --"Inside, Outside, Upside Down"