▼
Posts: 901
Threads: 113
Joined: Jun 2007
A recent thread compared the capability of the HP67 and the SR52. While looking through the HP67 Owner's Handbook and Programming Guide I found the following statement on page 109
Quote:
"..Unlike storage register arithmetic, the Sum+ function allows overflows (i.e., numbers whose magnitudes are greater than 9.999999999x10^99) in storage registers RS4 through RS9 without registering Error in the display. ..."
I tested the statistics routine of my HP67 with the following sequence:
1. Start with clear .registers.
2. Press 1 ENTER Sum+ to enter the first data pair. See 1.00 in the display.
3. Press 2 ENTER Sum+ to enter the second data pair. See 2.00 in the display.
4. Press 3 ENTER Sum+ to enter the third data pair. See 3.00 in the display.
5. Press 6 EE 99 ENTER 8 EE 99 Sum+ to enter a fourth data pair. See 4.00 in the display. There will not be an error indication.
6. Press f xbar to calculate the means. See 2.000000000 99 in the display. Press h x<>y and see 1.500000000 99 in the display. These number makes sense as the mean values and can be duplicated by pressing f P<>S and calculating RCL4 4 / and RCL6 4 / .
7. If you interchanged the primary and secondary registers to cross check the calculation of means in step 6 then interchange them again.
8. Press g s to calculate the standard deviations. See 2.309401077 99 in the display. Press h x<>y and see 1.732050808 99 in the display. Those numbers are the square root of 16/3 times 1 E 99 and the square root of 3 times 1E99.
If I interchange the primary and secondary registers and attempt to verify the numbers by calculating the standard deviations using the formulas on pages 113114 of the manual I get 5.000000000 49 for both standard deviations.
I have tried calculating the standard deviations without interchanging the primary and secondary registers by using indirect arithmetic and I still get 5.000000000 49 as the values.
So my question is "Where do the numbers in step 6 come from?,
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Quote:
So my question is "Where do the numbers in step 6 come from?,
Hi, Palmer 
The mean values in Step 6 are fine, as you stated. Maybe you should be asking about the standarddeviation calculations in Step 8, which, if based on summation methods (as expected), would utilize overflowed values.
The HP15C does not allow overflow summation values in the summation registers. Flag 9 is set (display blinks) and "9.999999999 99" is stored in registers R4, R6, and R7 (x^{2}, y^{2}, and xy). Means can be calcluated, but standard deviations cannot, due to capped summation values.
I don't understand the rationale behind the "special treatment" of summation. Is there a different data format for the summation registers than for stack and other storage registers? If so, recall of "special" stored numbers could lead to erroneous and unpredictable results in calculations.
 KS
Edited: 25 May 2008, 2:01 p.m.
▼
Posts: 901
Threads: 113
Joined: Jun 2007
Karl:
You wrote:
Quote:
The mean values in Step 6 are fine, as you stated. Maybe you should be asking about the standarddeviation calculations in Step 8, which, if based on summation methods (as expected), would utilize overflowed values.
You are correct. I meant to write Step 8, but somehow went to print with step 6.
You also wrote:
Quote:
I don't understand the rationale behind the "special treatment" of summation. Is there a different data format for the summation registers than for stack and other storage registers? If so, recall of "special" stored numbers could lead to erroneous and unpredictable results in calculations.
The only thing that I can think of at the moment is that the statistics routines use something similar to the socalled "tricky properties" available in the HP41 and in subsequent machines; however, when I tried to observe the "tricky properties" in the HP67 a few years ago I wasn't able to see them. Maybe I will have to try again. But, clearly, the standard deviation calculation with g s does something different from what happens when I do the supposed equivalent from the keyboard.
The methodology for handling overflow has varied a lot over the years. My HP33C and HP38C will accept a summation input which causes an overflow in the summations of squares without warning the user. But, when the user tries to do the standard deviation calculations the machines return an error indication.
The TI59 flashes an error after a summation input has caused an overflow but has done the summations.
I like what the TI66 does. If the summation input will cause an overflow the summations are not performed and "Error" is displayed to tell the user that there is a problem.
The TI68 does something entirely different. If an overflow occurs the statistics registers are cleared!
Palmer
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Quote:
...socalled "tricky properties" available in the HP41 and in subsequent machines...
"tricky properties", of course, is a term from the HP15C Advanced Functions Handbook for extendedprecision internal arithmetic in statisticalsummation calculations, exploited using "Sigma" to calculate a nearzero quadraticfunction discriminant of the form B^{2}AC with increased accuracy.
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv018.cgi?read=130481#130481
Not quite the same thing as storing the summation results to numbered registers in a different format that allows larger exponents.
 KS
Posts: 412
Threads: 40
Joined: Mar 2006
Hi Palmer,
Interesting observations on the HP67!
Try this even simpler test:
1. Start with clear registers and stack.
2. Press 1 EE 80 Sum+ . See 1.00 in the display.
3. Press 3 EE 80 Sum+ to enter the second data. See 2.00 in the display.
4. Press f xbar to calculate the mean. See 2.000000000 80 in the display (OK). Press g s to calculate the standard deviation. See 2.8284.... 80 in the display. The correct answer should be 1.4142.... 80.
I believe that even if there is no overflow error and that internal math may be able to compute with exponents larger than 99, then the results are not reliable due to the fact than the square sum registers are 'clamped' to 9.999... 99 during data input.
JF
▼
Posts: 901
Threads: 113
Joined: Jun 2007
J.F.
You wrote:
Quote:
I believe that even if there is no overflow error and that internal math may be able to compute with exponents larger than 99, then the results are not reliable due to the fact than the square sum registers are 'clamped' to 9.999... 99 during data input.
I tend to agree; however, if you do my sequence with x or y values for the fourth data point with integer mantissas ranging from 1 through 10 and the exponent as 99 you will find that the mantissa of the standard deviation result will be the mantissa of the input divided by the square root of 12, where of course 12 is n(n1). This suggests that although the summation of the squares may read out to the display as 9.9999999999 E 99 the number actually in the summation register may be correct. Strange indeed!
Palmer
▼
Posts: 412
Threads: 40
Joined: Mar 2006
Here is my analysis, with your test case:
The formula used to calculate Sx is:
Sx=sqrt((R5R4^2/R9)/(R91))
if the HP67 registers would be able to hold exponents above 1e99, the registers would be:
R4=8E99
R5=6.4E199
R9=4
and the result would be:
Sx=4E99
My hypothesis is that R5 is actually clamped to 9.99..E99 and is negligible compared to R4^2/R9, and that the HP67 seems to ignore the resulting negative sign so Sx is evaluated (more or less) as Sx=R4/sqrt(R9*(R91)) i.e. 2.30..E99.
JF
Edited: 26 May 2008, 7:29 a.m.
▼
Posts: 901
Threads: 113
Joined: Jun 2007
Quote:
Here is my analysis, with your test case:
The formula used to calculate Sx is:
Sx=sqrt((R5R4^2/R9)/(R91))
if the HP67 registers would be able to hold exponents above 1e99, the registers would be:
R4=8E99
R5=6.4E199
R9=4
and the result would be:
Sx=4E99
My hypothesis is that R5 is actually clamped to 9.99..E99 and is negligible compared to R4^2/R9, and that the HP67 seems to ignore the resulting negative sign so Sx is evaluated (more or less) as Sx=R4/sqrt(R9*(R91)) i.e. 2.30..E99.
You are correct that the sum of the squares of the inputs overflows and becomes 9.999999999E99.
As I understand what you have written (8E99)^{2}/4 must be much larger than 9.999999999E99 . But it won't be because the square of the sum of the input values (a little bit larger than 8E99) also overflows. Thus, the square of 8E99 becomes 9.999999999E99. That value divided by 4 becomes 2.500000000E99. Subtracting that from the 9.999999999E99 from R5 yields 7.499999999E99. Dividing by 3 yields 2.500000000E99 and taking the square root yields 5.000000000E49.
You will get that answer if you used 6E99 instead of 8E99 at the beginning, or for that matter, if you use any value which overflows the summation of squares, since it will also overflow the square of the sum of input values.
You will get the same answer whether you use P<>S so you can do the recalls directly,or if you don't do P<>S and use indirect recalls.
My only idea so far is at least implausible. Suppose that the statistics calculations in the HP67, while not having the "tricky properties" of the HP41 and subsequent machines per se, have their own set of "tricky properties" which can somehow keep track of large numbers like th square of 8E99, and that the statistics calculations can somehow use those values even though I can't see them in keyboard calculations. Then it would be possible to get the strange results. That sounds farfetched but it is not too far removed from the situation with the "tricky properties" of the HP41 et al
Thatt's the best I can come up with so far. Bizarre, to say the least.
Palmer
▼
Posts: 901
Threads: 113
Joined: Jun 2007
I tested overflow in the statistics routines with other HP machines in my collection using the four data pairs (1,1), (2,2), (3,3) and (6E99, 8E99).
My HP27 yields results which are similar to those from my HP67, but with an important difference. When the fourth pair is entered the calculator displays OF. Page 48 of the HP27 Owner's Handbook states "If the value in a storage register exceeds 9.9999999 x 10^{99} the following indicator appears on the display: OF". The summations are made. If I clear the display and proceed I find that the means are correct. The standard deviations are displayed as 2.3094011 99 and 1.7320508 99 . If I divide the displayed values by 1E99 the displays become 2.309401077 and 1.732050808 which are the same ten digits as in the mantissas of the standard deviations returned from the HP67. The linear regression function (L.R.) yields an intercept of 0.3125 and a slope of 0.75 . If I calculate the standard deviations from the keyboard using sums recalled from the statistics registers I get the 5.0000000 49 display.
Other ten digit mantissa machines in my collection such as the HP33C, HP38C, HP11C, HP12C and HP41 do not give a warning of overflow when the fourth pair is entered and do make the summations. Each machine calculates the means correctly. Each machine returns an error message when asked for standard deviations.
Twelve digit mantissa machines in my collection such as the HP32S, HP33S and HP35S flash OVERFLOW when the fourth pair is entered. NOTE: to get overflow the fourth pair must be (6E499, 8E499) not (6E99, 8E99) as with the ten digit mantissa machines. The means are calculated correctly. The response to a request for standard deviations is STAT ERROR.
Finally, my HP10B flashes OFLO when the fourth pair is entered. The summations are made. The means are correct. When I ask for the standard deviation the machine responds with Error  StAt.
So, at least for the machines in my collection, the HP67 is unique in not providing any indication of overflow to the user. A bit bizarre! One wonders why the designers did that.
▼
Posts: 412
Threads: 40
Joined: Mar 2006
In my understanding, the HP67 is unique not in providing no overflow indication (other machines do the same), but in providing no error indication in case of invalid standard deviation.
For instance if, after accumulating some data, you clear the square sum register (P<>S, 0 STO 5, P<>S), you will get a result for the standard deviation instead of an error indication. We could call it a bug.
JF
Posts: 153
Threads: 7
Joined: Jun 2008
Yes, the '67 can work with exponenents up to 499 internally. That's what is happening here with the '67 statistics bug.
I hate to burst anybody's bubble, but these "nonnormalized numbers" (NNN's) caused by the '67 statistics functions were thoroughly explored (and written about) over 30 years ago, in the "65 Notes" newsletter (which soon afterwards changed its name to the "PPC Journal").
The whole story behind HP67 NNN's can be found here:
http://holyjoe.net/hp/nnn.htm
jkh
▼
Posts: 412
Threads: 40
Joined: Mar 2006
Hello Joe,
Thanks for this valuable information! It was really a pleasure to read your post, and your page about the NNN's on the HP67. My first personal HP calculator was a HP41CV in the beginning of the 80's so I'm not a HP67 expert, but I always considered this machine as one of the most important (and beautiful) model from HP and I was very happy when I got one some years ago.
Creating NNN's that are beyond the 9.99...E99 limit with the xbar function is indeed very easy, for instance (just to describe the process to all):
1E60 STO 6 1/x STO 9 P<>S xbar
creates the 1E120 NNN in Y, that is displayed as "1.000000000 20" by the STK command.
Kind regards.
JeanFrancois Garnier
Edited: 3 June 2008, 4:55 p.m.
