▼
Posts: 901
Threads: 113
Joined: Jun 2007
I was getting acquainted with my new hp 33s when I stumbled on a difference from many earlier scientific calculators manufactured by HP. Machines such as the HP45, HP27, HP67, HP41, HP11C, HP12C, HP15C and HP32S will all accept a SUM  command immediately after a CLEAR SUM command, return a 1 to the display, and store negative values in the statistics registers relative to those which would have been stored if a SUM + command had been used. The hp 33s will NOT accept a SUM  command immediately after a CLEAR SUM command.
Furthermore, if with those earlier machines the user enters a CLEAR SUM command, stores a positive fractional value in n, and then enters a SUM  command the machines will return one minus the fractional value to the display, store one minus the fractional value in n and store negative values in the remaining statistics registers relative to those which would have been stored if a SUM + had been used. The hp 33s will not accept a SUM  command if the existing value stored in n is less than one.
Interesting!
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Hi, Palmer 
Hmm, interesting discovery. I compared my 33S (a "bad display with bugs" unit from 2004) with my 32SII from 2001.
The 32SII seems to do no validation whatsoever of the summation value n in register 28 (accessed indirectly). So, any operation is permitted, including calculation of standard deviations and mean averages, as long as "SQRT(NEG)" is not attempted.
The 33S seems to include some validation of n:
 Sigma is rejected without informational message whenever n is not a positive integer, but Sigma+ is always accepted.
 Calculation of standard deviations is rejected when n is not a positive integer, but calculation of mean averages is not.
The reason for this apparentlyinconsistent approach to validation may be that the summation functions can be used for purposes other than statistics. Also, the statisticalsummation registers could be used as scratch registers, accessed indirectly.
For example, integrals and estimated error of subintervals of an integrand can be respectively summed using Sigma+ as they are calculated. Requirement of positiveinteger n could needlessly interfere with that. (The integrationbysubinterval technique is is fully described in the HP34C manual and HP15C Advanced Functions Handbook.)
Division by a noninteger n in a mean average can be useful, also.
Still, a message should be displayed when Sigma is rejected.
 KS
Edited: 8 Mar 2006, 1:50 a.m.
▼
Posts: 901
Threads: 113
Joined: Jun 2007
Once I had rebuilt a battery pack I was able to see that my HP33C and HP38C operated in the same manner as most of the other machines.
I did find that my HP28S will not accept a SUM  immediately after a CLEAR SUM. Instead, it beeps and displays the message “Nonexistent SUM DAT”. That is consistent with your idea that a machine should provide an indication if it does not perform a command. Of course, the hp 33s does provide an indication that something is amiss if you try to do a SUM  immediately after a CLR SUM since it does not return a 1 to the display.
I found the following statement under the paragraph “Value Limits” on page 204 of the HP27 Owner’s Handbook:
“You cannot have a negative number of entries for statistical problems. That is, you cannot key three inputs into SUM +, then subtract out four with SUM . “
That didn’t agree with the tests I had run earlier so I cleared the statistics registers and did two SUM  commands with 2 in the Y register and 3 in the display register. Then I pressed the meanx key and saw +3.00 in the display. I pressed x<>y and saw +2.00 in the display. This seems to make sense since n = 2. I stored +2 in register 4 which sets n to +2. I pressed the mean x key and saw 3.00 in the display. I pressed x<>y and saw 2 in the display. Again, that makes sense. I got the same results with my HP22.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Palmer stated,
Quote:
I did find that my HP28S will not accept a SUM  immediately after a CLEAR SUM. Instead, it beeps and displays the message “Nonexistent SUM DAT”. That is consistent with your idea that a machine should provide an indication if it does not perform a command.
Of course, the hp 33s does provide an indication that something is amiss if you try to do a SUM  immediately after a CLR SUM since it does not return a 1 to the display.
Statistical calculations offered by RPLbased HP28/48/49 models and by the HP17B/17BII/27S are different from most other models. The 17/27/28/48/49 store each datum as it is entered  unlike the other models, which only accumulate six summation values as each datum is entered.
Thus, it is quite logical for the 17/27/28/48/49 to refuse a SIGMA operation if there are no stored data. However, refusing an operation without an explicit message (as the HP33S can do for SIGMA) is not a very good "indication".
KinHPo's attempt in the HP33S to perform some validation of the summation value n before accepting SIGMA or standard deviation operations is perhaps commendable, but of questionable practical value. Use of only CLEAR SIGMA, SIGMA+, and SIGMA will yield integer values of n, which can be modified only by indirect access of register 28. There's not much reason to alter the value of n, but the user may have had a specific purpose for doing so.
 KS
Edited: 10 Mar 2006, 1:20 a.m.
▼
Posts: 901
Threads: 113
Joined: Jun 2007
This will explain why I was interested in the different way that my hp 33s responds to a SUM  command which appears after a CL SUM command but before a SUM + command has occurred. It will also show an application where it makes sense to change the value of n other than with SUM + and SUM  commands.
A quadratic solver which appears on pages 208211 of the HP15C Advanced Functions Handbook uses a socalled "tricky property of the SUM + and SUM  commands" in a way that is equivalent to carrying twenty significant digits in the calculation of the discrimiinant. As I was working my way through the hp 33s user's guide I found the following statement on page 119: "... During some complicated internal calculations, the calculator uses 15digit precision for immediate results. ..." That sounded a lot like the "tricky properties". I did some tests that convinced me that the "tricky properties" were available in the hp 33s. I then decided to try to translate the HP15C program for use with the hp 33s. Steps 011 through 025 of the HP15C program are
011 CLEAR SUM
012 RCL 8
013 STO 7
014 RCL / I
015 RND
016 RCL I
017 SUM 
018 RCL 9
019 x <> 7
020 x <> y
021 RCL 8
022 SUM 
023 R Down
024 SUM 
025 RCL 7
and so on where there is an additional SUM  at step 052 and there are no SUM + commands in the loop. That means that the HP15C is able to accept inputs to the statistics registers which would cause the number of entries (n) to become negative. The statistics routines in the HP41, the HP32S and several other HP machines can also do that. The statistics routine in the hp 33s cannot. After a little thought it occurred to me that hp 33s routine may not care how the value for the number of entries (n) had been accumulated in register 28. To prove that I did a CL SUM and followed it by three SUM + commands where 2 was in the y register and 3 was in the x register. I recalled the means and saw the values 3 and 2 as expected. Then I stored 28 (the number of the statistics register which holds the value of n) in I, entered a 3 in the display, and did a STO+ (i). I recalled the means and saw the values 1.5 and 1.0 . To make a long story short I was able to successfully translate the HP15C program for use on the hp 33s by storing a four for n in statistics register 28 after the CL SUM command and before the SUM  commands.
The resulting program for the hp 33s with test cases appears in the Articles section as "A Cadillac Quadratic Solver for the hp 33s."
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Palmer 
So that was the motivation! Congratulations are in order for a successful porting of some of the fine work in the HP15C AFH.
I suspect that the "tricky property" involves some internal numerical techniques to carry out products for the quadratic summations (X^{2}, Y^{2}, and XY) with minimal loss of accuracy.
Also, I believe that the AFH program  and your adaptation of it  is a perfect illustration of the point I made earlier: Specifically, that the added "validation" of n for SUM and standard deviation in the HP33S was a misguided "enhancement".
When the statisticalsummation registers are employed only in their intended manner, using only CLEAR SUM, SUM+, and SUM, n will be an integer. If the user never "deletes" more data than had been previously entered, n will remain nonnegative. The value of n can be modified to an "invalid" value only by indirectly accessing register 28.
As for disallowing SUM for n not a positive integer: That won't prevent "improper use" of SUM, whose purpose is to allow removal of erroneous or selected data from the summations. What if the user first enters the data 5, 3, and 7 using SUM+, then "deletes" the datum 8 using SUM? That wouldn't be valid, yet the HP33S would allow it.
The HP calculators that were developed inhouse do not impose misguided and ineffective restrictions on the summation functions. This allows users to fully exploit the functions as needed. Cases in point are the AFH program and summation of numerical integation over successive intervals.
 KS
Edited: 13 Mar 2006, 4:10 a.m.
Posts: 416
Threads: 78
Joined: Mar 2006
My 33S (SN CNA 5150xxxx) does accept a SUM after a CLEAR SUM command. Or, better, doesn't complain, and pushes 0 on TOS.
Maybe it's a revised model?
 Antonio Maschio
▼
Posts: 901
Threads: 113
Joined: Jun 2007
Are you sure that anything is really happening in your machine? My hp 33s is S/N 53200443 presumably a later unit than yours. When I try to do the Sum  after the CLR SUM I get a zero returned to the display and no error indication. But, if I recall the statistics registers 28 through 33 I don't find that anything has been entered.
Posts: 177
Threads: 12
Joined: Jan 1970
Interesting find Palmer. I'm not sure that I have ever used the Sum  command immediately after the Clear Sum but it is good to know about this difference. It would be interesting to compare this behavior with other Kinpo and nonKinpo calculators.
In the 80's I worked between a 15c, 34c, 41cv and a 97. Some of those machines also issued a Clear x or Clear Stack when Clear Sum was used. I don't remember the details any longer but I had to be careful when moving around them.
Regards,
John
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
15c and 11c clear the stack.
▼
Posts: 177
Threads: 12
Joined: Jan 1970
I just tested my 34c and it does not clear the stack after a Clear Sum.
John
Posts: 1,792
Threads: 62
Joined: Jan 2005
John Smitherman posted,
Quote:
In the 80's I worked between a 15c, 34c, 41cv and a 97. Some of those machines also issued a Clear x or Clear Stack when Clear Sum was used.
As Bill Platt said, the HP11C and HP15C clear the stack when CLEAR SIGMA is performed. The HP10C and HP12C do, also.
However, the HP32S, HP32SII, and HP33S do not. Also, the HP41C* and HP42S do not.
Why is this? Here's the answer:
The Voyagers (10, 11, 12, 15) and many earlier models have no "clear stack" function, and they calculate sample standard deviation on both the X and Ydata when the "s" function is performed. So, if "debris" is entered from the yregister into Ydata when only Xdata is explicitly entered, the standard deviation function may fail entirely due to SQRT(NEG) caused by the bogus Ydatum. Automatically clearing the stack when clearing summation registers for entry of data will help prevent erroneous results. (A user complained about failed standard deviation in the Forum several archives ago, when he did a calculation that placed results on the stack in the midst of data entry. The fix is to zero out the registers containing the contaminated and unneeded summations involving Ydata.)
The HP32S, HP32SII, and HP33S calculate standard deviation separately for Xdata and Ydata using distinct functions, so these models are not affected by the potential error.
The HP41C* and HP42S calculate sample standard deviation on both the X and Ydata, as the Voyagers do. However, they also provide a function "CLST" to clear the stack in a separate operation.
So, there's a usually a valid reason for everything you see on these calculators...
 KS
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Karl:
Karl posted:
"So, there's a usually a valid reason for everything you see on these calculators.."
A further valid reason for having CLEAR SIGMA to also perform CLST in the HP11C and most specially the HP15C is that by doing so you free an additional location on the keyboard to include yet another function.
This is really important for the HP15C, as the number of keys is the same as all other Voyagers, yet it has many more functions to assign to them. Using separate keys for CLEAR SIGMA and CLST would be a tremendous waste, and would probably mean that CLST wouldn't be included. Also, using the very same physical key for as many distinct functions as possible is mandatory.
Would you believe that, in the HP15C, the [+] key is used for seven different purposes ? :)
Best regards from V.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Hi, Valentin 
Yes, indeed the layout and organization of the HP15C keyboard (based, of course, on that of the HP11C) is an absolute marvel of coherent thought and organization. Even after adding a substantial amount of functionality for the 15C, the grouping of functions on the keyboard was actually improved somewhat over the 11C. Note the following improvements on the 15C over the 11C:
 All statistical functions (except CLEAR SIGMA) are on the bottom row
 All three conversion functions are sidebyside
 Pi and its shift key are closer together
 x<>(i) and x<>I were replaced by a moreversatile "x<> "
Another bit of good thinking was to place SOLVE above the "divide" key, which is used for solving an exactlydetermined linear system of equations.
So, if one could revisit 19811982 to improve the HP15C (as well as other Voyagers, respectively), how could that have been done without changing its hardware or paradigm in any way? Fixed specifications include the following: Voyager packaging; 7segment, 10digit display; RAM; ROM space; microprocessor; and battery.
We've discussed this before, a few archives ago, with the question framed a bit differently. I can think of only the following improvements to the HP15C within the limitations I have specified:
Place LN and e^{x} on keys 12 and 13, rather than e^{x} and 10^{x}
This was implemented on the successor Pioneerseries models. Perhaps there was a pleasing symmetry with e^{x}, 10^{x}, and y^{x} sidebyside. Also, keycodes 11, 12, 13, 22, 23, 24, and 25 all had blueshifted inverses of transcedental functions (maybe that was the reason!). However, LN is just more useful than 10^{x}.
Show A, B, C, D, and E in program keycodes where appropriate (for labels and matrix identifiers), rather than the corresponding positional keycodes 11, 12, 13, 14, and 15.
This was implemented on the Pioneerseries HP20S, but might have run into issues of development time and ROM space for the HP15C.
Move CLx above the backarrow as a yellowshifted function, put "SHOW" or "MANT" as the blueshifted function, and perform "CLEAR PREFIX" as on the HP41 and the Pioneerseries models: by repressing the shift key.
Clearing a prefix key by performing a "no op" or "display mantissa" function was probably carried over from the LEDdisplay Spice models such as the HP34C, which had no annunciator for a shift key. I believe that considerable 34C microcode was ported to the 11C, which in turn was used in the 15C.
That's about it. For what the HP15C was, those are about the only feasible improvements I can think of  absolute perfection was nearly achieved. Certainly, a few other functions would have been useful, such xestimator (present on the HP10C and HP12C), y^{1/x}, x^{2}, and "ALL" display format. However, there just wan't available space, at least without resorting to key combinations that were arcane, unintuitive, or inconvenient.
BTW: What are the seven uses of the [+] operation? I can identify four, six, or eight, depending on how one is counting:
Two real scalars
Two complex scalars
Two matrices
One matrix and one real scalar (in either order)
STO + (real scalar to numbered register or matrix element)
RCL + (real scalar from numbered register or matrix element)
Best regards,
 KS
Edited: 11 Mar 2006, 5:28 p.m.
▼
Posts: 901
Threads: 113
Joined: Jun 2007
I don't have an HP15C and as a result don't have a manual. I purchased the HP15C Advanced Functions Handbook after I saw it mentioned in Kahan's paper "Mathematics Written in Sand". When I decided to translate the quadratic solvers I ran into a problem  commands such as g TEST 2 didn't help me understand what was happening. I had to analyze the programs and look other places in the book in order to decipher what was happening. So my question is, why did they do it that way? It seems to me that it would be possible to put the actual commands in the display, just like the 32S and 33s.
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Palmer:
Palmer posted:
" So my question is, why did they do it that way? It seems to me that it would be possible to
put the actual commands in the display, just like the 32S and 33s.""
As it has been commented a number of times, they did it that way because, as you know, the HP15C doesn't have alphanumeric capabilities, so there's no way to execute a function by spelling its name, you must press the assigned key, which means 12 key locations would be needed to make available the 12 implemented logical tests.
Due to the many distinct functions available in the HP15C and the small, fixed number of keys, wasting 12 key locations wasn't an option and instead the two commonest tests were asigned to individual locations, while the 10 remaining ones where assigned to the TEST prefix, thus saving as much as 9 key locations for other functions. This explains why they weren't put on the keyboard.
As for why they weren't put "in the display, just like the 32S and 33S" it might have to do with the simple fact that, as stated, the HP15C does not have alphanumeric capabilities, plus it only has a 7segment LCD display. It's just too hard (physically impossible some might say ...) to display "X less than or equal to Y ?" under such constraints, don't you think ?
Best regards from V.
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Karl:
Karl posted:
"Show A, B, C, D, and E in program keycodes where appropriate (for labels and matrix identifiers), rather than the corresponding positional keycodes 11, 12, 13,
14, and 15. This was implemented on the Pioneerseries HP20S, but might have run into issues of development time and ROM space for the HP15C."
It was also implemented in a Voyager as well, the HP16C, which showed A,B,C,D,E, and F instead of the numeric keycode. As for ROM space, yes, the HP15C had serious problems with this, with features being suggested and still awaiting implementation when they were absolutely out of it.
I think that's why they didn't include the much more useful "Create Identity Matrix" function instead of the existing "Initialize Matrix Indexes" (MATRIX 1), which can be implemented in three steps (1, STO 0, STO 1) and thus only saves two, apart from the marginal benefit of leaving the stack unaltered. While programming the HP15C, I've needed many times to create an identity matrix and so always missed that particular function dearly.
"Certainly, a
few other functions would have been useful, such xestimator (present on the HP10C and HP12C), y^{1/x}, x^{2}, and "ALL" display format"
The HP15C does have the x^{2} function, look under "square root".
"BTW: What are the seven uses of the [+] operation?"
The six you mention, plus [ON][+] initiates a selftest operation.
Best regards from V.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Hi, Valentin 
Thanks for the response. Just a few clarifications:
Quote:
It (single letters in keycodes) was also implemented in a Voyager as well, the HP16C, which showed A,B,C,D,E, and F instead of the numeric keycode.
Indeed, but the HP16C always shows A, B, C, D, E, or F  even for the functions that do not involve the label or hexadecimal digit. This is because, no doubt, that the letters are prominently doubleshot molded on the keys, making a more visible identifier (like 0 through 9) than the twodigit code. The HP20S and HP21S, however, make the functional distinction in the displayed keycodes.
Quote:
The HP15C does have the x^{2} function, look under "square root".
Oops, an incomplete statement on my part. I meant, "x^{2} as an unshifted function." Practically all HP calc's after the HP35 had x^{2}, but few until the HP33S included it as unshifted. It is used so frequently...
Quote:
The six you mention, plus [ON][+] initiates a selftest operation.
I considered that one, but that's not really an addition operation, per se.
Regarding the HP16C: How might that one have been improved prior to release in 1982? I'm not an expert on required computerscience function set, but it would have been nice if it had the same RAM as the HP15C, for purposes of programming. The calc is very useful for conversion of data formats, but custom programs are required. It is my understanding (from an Eric Smith post?) that the 15C had two chips for user RAM, whereas the other Voyagers had only one. I'm not sure if the microcode for 16C's automatic memory reallocation (similar to that of the HP11C and HP34C) would have complicated the addition of more RAM.
Best regards,
 KS
Edited: 12 Mar 2006, 12:15 a.m.
