Some curious numbers from my HP-67 « Next Oldest | Next Newest »

 ▼ Palmer O. Hanson, Jr. Posting Freak Posts: 901 Threads: 113 Joined: Jun 2007 05-25-2008, 02:10 AM A recent thread compared the capability of the HP-67 and the SR-52. While looking through the HP-67 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 HP-67 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 113-114 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?, ▼ Karl Schneider Posting Freak Posts: 1,792 Threads: 62 Joined: Jan 2005 05-25-2008, 01:55 PM 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 standard-deviation calculations in Step 8, which, if based on summation methods (as expected), would utilize overflowed values. The HP-15C 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 (x2, y2, 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. ▼ Palmer O. Hanson, Jr. Posting Freak Posts: 901 Threads: 113 Joined: Jun 2007 05-25-2008, 02:51 PM Karl: You wrote: Quote: The mean values in Step 6 are fine, as you stated. Maybe you should be asking about the standard-deviation 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 so-called "tricky properties" available in the HP-41 and in subsequent machines; however, when I tried to observe the "tricky properties" in the HP-67 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 HP-33C and HP-38C 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 TI-59 flashes an error after a summation input has caused an overflow but has done the summations. I like what the TI-66 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 TI-68 does something entirely different. If an overflow occurs the statistics registers are cleared! Palmer ▼ Karl Schneider Posting Freak Posts: 1,792 Threads: 62 Joined: Jan 2005 05-25-2008, 04:34 PM Quote: ...so-called "tricky properties" available in the HP-41 and in subsequent machines... "tricky properties", of course, is a term from the HP-15C Advanced Functions Handbook for extended-precision internal arithmetic in statistical-summation calculations, exploited using "Sigma-" to calculate a near-zero quadratic-function discriminant of the form B2-AC with increased accuracy. Not quite the same thing as storing the summation results to numbered registers in a different format that allows larger exponents. -- KS J-F Garnier Senior Member Posts: 412 Threads: 40 Joined: Mar 2006 05-25-2008, 03:54 PM Hi Palmer, Interesting observations on the HP-67! 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. J-F ▼ Palmer O. Hanson, Jr. Posting Freak Posts: 901 Threads: 113 Joined: Jun 2007 05-25-2008, 10:38 PM 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(n-1). 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 ▼ J-F Garnier Senior Member Posts: 412 Threads: 40 Joined: Mar 2006 05-26-2008, 07:26 AM Here is my analysis, with your test case: ```The formula used to calculate Sx is: Sx=sqrt((R5-R4^2/R9)/(R9-1)) 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 HP-67 seems to ignore the resulting negative sign so Sx is evaluated (more or less) as Sx=R4/sqrt(R9*(R9-1)) i.e. 2.30..E99. J-F Edited: 26 May 2008, 7:29 a.m. ▼ Palmer O. Hanson, Jr. Posting Freak Posts: 901 Threads: 113 Joined: Jun 2007 05-26-2008, 11:18 PM Quote: Here is my analysis, with your test case: ```The formula used to calculate Sx is: Sx=sqrt((R5-R4^2/R9)/(R9-1)) 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 HP-67 seems to ignore the resulting negative sign so Sx is evaluated (more or less) as Sx=R4/sqrt(R9*(R9-1)) 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 HP-67, while not having the "tricky properties" of the HP-41 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 far-fetched but it is not too far removed from the situation with the "tricky properties" of the HP-41 et al Thatt's the best I can come up with so far. Bizarre, to say the least. Palmer ▼ Palmer O. Hanson, Jr. Posting Freak Posts: 901 Threads: 113 Joined: Jun 2007 05-29-2008, 04:31 PM 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 HP-27 yields results which are similar to those from my HP-67, but with an important difference. When the fourth pair is entered the calculator displays OF. Page 48 of the HP-27 Owner's Handbook states "If the value in a storage register exceeds 9.9999999 x 1099 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 HP-67. 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 HP-33C, HP-38C, HP-11C, HP-12C and HP-41 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, HP-33S and HP-35S 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 HP-10B 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 HP-67 is unique in not providing any indication of overflow to the user. A bit bizarre! One wonders why the designers did that. ▼ J-F Garnier Senior Member Posts: 412 Threads: 40 Joined: Mar 2006 05-30-2008, 07:29 AM In my understanding, the HP-67 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. J-F Joe Horn Member Posts: 153 Threads: 7 Joined: Jun 2008 06-01-2008, 05:56 PM 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 "non-normalized 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 HP-67 NNN's can be found here: http://holyjoe.net/hp/nnn.htm -jkh- ▼ J-F Garnier Senior Member Posts: 412 Threads: 40 Joined: Mar 2006 06-03-2008, 04:49 PM 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 HP-41CV in the beginning of the 80's so I'm not a HP-67 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 x-bar function is indeed very easy, for instance (just to describe the process to all): ``` 1E60 STO 6 1/x STO 9 P<>S x-bar ``` creates the 1E120 NNN in Y, that is displayed as "-1.000000000 -20" by the STK command. Kind regards. Jean-Francois Garnier Edited: 3 June 2008, 4:55 p.m.

 Possibly Related Threads... Thread Author Replies Views Last Post HP Prime: complex numbers in CAS. Alberto Candel 1 643 12-06-2013, 02:36 PM Last Post: parisse [HP Prime] Plots containing complex numbers bug? Chris Pem10 7 1,260 12-05-2013, 07:40 AM Last Post: cyrille de Brébisson comparing numbers on the WP 34S Kiyoshi Akima 7 1,121 10-19-2013, 09:28 AM Last Post: walter b HP Prime: Operations with Large Numbers Eddie W. Shore 0 342 10-19-2013, 12:24 AM Last Post: Eddie W. Shore HHC 2013 room numbers David Hayden 2 551 09-20-2013, 05:34 PM Last Post: sjthomas [HP-Prime xcas] operations with complex numbers + BUGs + Request CompSystems 9 1,346 09-08-2013, 10:40 PM Last Post: CompSystems TED Talk: Adam Spencer: Why I fell in love with monster prime numbers Les Bell 3 685 09-05-2013, 12:54 PM Last Post: Ken Shaw Irrationality in numbers....the book Matt Agajanian 4 722 08-30-2013, 04:14 PM Last Post: Matt Agajanian Best HP calculator for crunching numbers rpn fan 51 4,740 08-05-2013, 03:17 PM Last Post: rpn fan HP 50G List of Library numbers already in use? Michael Lopez 2 503 08-04-2013, 10:10 PM Last Post: Michael Lopez

Forum Jump: