▼
Posts: 2
Threads: 1
Joined: Jan 1970
I'm doing the following on an HP11C: 147 sigma plus, 181 sigma plus, 211 sigma plus, 114 sigma plus.
Then I take the standard deviation: s = 41.97
Then I remove the last entry: 114 sigma minus.
Then I try to get the standard deviation again: s = error 2
If do 147 sigma plus, 181 sigma plus, 211 sigma plus, s then I get 32.02.
Is it me or the calculator?
▼
Posts: 76
Threads: 4
Joined: Jan 1970
s = error3 for my 34C; s= error2 for my 12C and OUT OF RANGE for the 41CV!
Posts: 76
Threads: 4
Joined: Jan 1970
Just realised  after getting s for the 4 numbers, 0 needs to be put into the stack before entering 114 so when you sigmaminus y=0 and x=114 rather than y=41.97 (old s) and x=114 otherwise when it recalculates s(x) it also tries to recalculate s(y) using sum of y squared which is now a negative due to subtracting the square of the apparent fourth y of 41.97 which then results in the poor old machine trying to take the square root of a negative number.
▼
Posts: 2
Threads: 1
Joined: Jan 1970
I see what's going on.
Thanks James!
Posts: 406
Threads: 47
Joined: Jul 2005
It's the calc. I posted this problem on the Forum some months ago. Of the ones I own this problem occurs on the 11C, 12C, 15C, and the 42S. On the 25C, 67, and the 32iiS, NO error message, but the correct answer: 32.02.
tm
Posts: 301
Threads: 28
Joined: Jan 2005
My HP15C and my HP41CV does well, both shows for the SDEV=32.0208, no error. I cannot try on my 11C as its display is broken :(
(HP15C s/n 2723B12245, HP41CV s/n 2214B03932)
▼
Posts: 301
Threads: 28
Joined: Jan 2005
As our friend James said, is the Y value on the sigma() operation... I was clearing the display before inserting the 114 sigma(), and it worked... if I don't clear the X before typing the 114, the HP15C shows "Error 2"...
▼
Posts: 76
Threads: 4
Joined: Jan 1970
Hi Gang
It's always the little things  reminds me of the hours I spent gazing at FORTRAN listings wondering why the program didn't work and someone would look over my shoulder and point out the ',' that should have been a '.'
My apologies in advance for the formatting  can't work out how to get a superscript 2 for the squares or a sigma sign so please read x2 as xsquared and E as sigma.
The apparent bug results from the fact that the standard deviation function operates on two variables, x and y. Every time you key E+ the calculator accumulates Ex, Ey, Exy, Ex2 and Ey2. When E is keyed the calculator makes the appropriate adjustment to Ex, Ey, Exy, Ex2 and Ey2. If you are only using one variable, the yregister should be cleared first before starting so that y (and Ey, Exy, and Ey2 ) will always be equal to 0. The apparent bug arises when, having called s, which returns both s(x) in the x register and s(y) in the y register, you then enter, in this case, the 4th x (114) which pushes s(x) into the y register and key E then the calculator will in making the appropriate adjustments to Ex, Ey, Exy, Ex2 and Ey2 subtract the square of s(x) from the current Ey2 which was 0 and now becomes s(x)2. When you recalculate s, s(x) can be calculated but s(y) can't be calculated as it now involves trying to take the square root of a negative number and the apprpriate error message is displayed – in the case of the 34C, error3. Extract from the 34C handbook “A nonzero number in the yregister during onevariable calculations of s, r, L.R. may result in a display of Error3”.
s(y) = square root of {[n Ey2  ( Ey )2]/n(n1)}.
With my 12C, 34C and 41CV there is no error display provided that I am careful to ensure that after getting s(x) I key 0 [ENTER] before keying the 4th x (114) and E.
I'm now off to try and make peace with my HPs for ever doubting them!
Best
James
Posts: 406
Threads: 47
Joined: Jul 2005
Using Alan's keystrokes on my 15C (serial 2242A17848) I get "Error 2". I consider it a "bug" when you are forced to load a "0" into the stack. After all on the 25C, 67, and the 32Sii loading in a "0" is not necessary and you do get the correct answer.
tm
▼
Posts: 76
Threads: 4
Joined: Jan 1970
Hi Trent
The behaviour of the 67 intrigues me as it appears (from what I can find) to operate in the same way as the 12C, 34C, 41CV et al, ie when you calculate s it computes both s(x) and s(y) and therefore unless y is set to 0 for the data pair to be deleted, E will result in s(y) being the square root of a negative number.
From a look at the 25 manual on the MoHPC CDs and the spec sheet on the 25C page on the museum the problem won't occur with the 25C as it doesn't appear to have full two variable statistical functions and only calculates s(x)  according to the manual the only quantities it accumulates are Ex, Ex2, Exy and Ey but not Ey2 therefore no s(y).
As to the 32Sii (of which I have no experience) a response to the thread a few months ago indicated that s(y) was a separate function to s(x) so calculating s(x) wouldn't give rise to any error message.
But the 67 baffles me.....
Best
James
▼
Posts: 406
Threads: 47
Joined: Jul 2005
James (UK),
I agree. I've got the handbooks out HP67 pgs. 113114 and HP15C pgs.5354 and Appendix A pg.206. Will try to figure it out. But the fact remains that the 67 comes up with the correct answer without all that "0" imput rigmarole.
tm
▼
Posts: 85
Threads: 8
Joined: Jan 1970
This may or may not be of some help.
According to the HP67 manual:
"The number that you keyed into the Xregister is preserved in the LAST X register, while the number in the stack Yregister remains in the Yregister."
rdb.
▼
Posts: 182
Threads: 9
Joined: Jun 2013
The same should also apply to the other 4level stack models (15C, 41, 42S): The stack lift is locked after Sigma+, so entering just one number will not raise the stack and leave Y what is was before. If you press 0 ENTER before beginning summation of your data, all of these calcs should behave the same and not cause problems with SDEV or MEAN.
Cheers, Victor
Posts: 406
Threads: 47
Joined: Jul 2005
James
I can't figure out why the 67 doesn't have this bug. Its too bad they didn't use its algorithm for the Voyager series and the 42S.
tm
▼
Posts: 76
Threads: 4
Joined: Jan 1970
Hi Trent
Thanks for the update  it's interesting that they changed the algorithm  I wonder why? Presumably the 67 must decide that if Ey2 becomes negative you are working with only the x variable. Out of interest, what does it return for s(y) in such a situation?
Best, James
▼
Posts: 406
Threads: 47
Joined: Jul 2005
James 
After going through the same steps in Alan's original example, the X reg shows 32.02 and th Y reg 34.27 and zero in the Z and T regs. Storage reg s4 has Ex, s5 has Ex2, s6 has 41.97 (the negative value of the sd the orininal four values), s7 has 1761.58 which is the negative value of 41.97 squared, s8 has 4784.72 i'm not sure what that is, and 3 (n) in s9.
Trent
▼
Posts: 137
Threads: 11
Joined: Jul 2006
Hi Trent
Thanks for the update  I've been trying to work out what the y reg figure of 34.27 represents but with no luck  maybe I should get a 67 (any reason will do as justification!)
It seems to be picking up s(y) as a y value when E is performed so stack lift can't be disabled so I guess it must have some code that decides that if s(y)2 is negative you are only working with x values and therefore doesn't bother with trying to take the square root which would produce an error flag. I wonder why they didn't carry this routine over to the later machines.
Best, James
▼
Posts: 406
Threads: 47
Joined: Jul 2005
James,
Sounds reasonable. I'm going to fool around with it some more this weekend.
Trent
Posts: 1,792
Threads: 62
Joined: Jan 2005
The cause of the unexpected result obtained by Alan Dalkey (subj: "Statistics Bug?") on an 11C (and others on the 15C and 41C) has been adequately explained. The root cause is that these units perform summation and calculations on orderedpair variables, even when only singlevariable data is being entered. Models that provide separate operations for calculating mean and standard deviation for x and y (e.g., 32Sii) can avoid this problem.
(Another logical solution is to have separate "modes" for twovariable and singlevariable statistics. Certain models by Casio and TI handle the stat/regression task more elegantly than many HP models, in my estimation. In fact, I can name at least five things I don't like about the stat functionality on the HP15C, but at least it's there. Many of the shortcomings stem from a lack of keyboard space.)
Alan's "finding" revealed something I didn't know about the HP41. I had assumed that it had only singlevariable stats, because it had only "MEAN" (arithmetic mean average)and "SDEV" (sample standard deviation) builtin. Thus, the "OUT OF RANGE" message found by "james(uk)" was surprising  if HP put twovariable stats in the HP41, why didn't they add the necessary namedfunction regression routines?
The cynical answer might be in the HP41 "Stat Pac" (which I have). Using Sigmaplus and Sigmaminus, the Stat Pac adds the missing regressionanalysis functions as RPN programs for linear, logarithmic, expenential, and power. BTW, using the Stat Pac regression programs will change the stat registers from the default R11R16 to R10R15.
The HP42S took this one better, adding a "bestfit" option.
Twovariable statistical summation builtin, with regressionanalysis as an extracost option! Had HP planned that all along?
▼
Posts: 406
Threads: 47
Joined: Jul 2005
Karl 
But you leave out of your discussion the HP67.
tm
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Trent posted:
Quote:
Karl 
But you leave out of your discussion the HP67.
tm
I don't *have* a 67; I've only seen pictures of one. Thus, I don't know what's different about it, other than what you have posted several times on this topic.
Perhaps the 67 is an exception, but stat calculations tend to be kinda screwy on the traditional HP RPN machines. Calculations automatically performed using "stackclutter" inputs is the real culprit. Here's a list of shortcomings on the 11C/15C:
1. (xdata) ENTER (ydata) E+ adds xdata to Ysummation, and viceversa.
2. No "frequency" function for multiple occurrences of a data point.
3. No xdata estimator, weighted mean, or population standard deviation.
4. ydata estimator also calculates "r" every time, and viceversa.
5. Risk of calculation errors with inadvertent garbage data.
Granted, if one knows the math and summations, there are fairly easy workarounds for most of these. Also, there just wasn't enough keyboard space to provide the missing functionality  much had to be "doubled up". Still, there is potential for "user consternation".
