The Museum of HP Calculators

HP Forum Archive 17

[ Return to Index | Top of Index ]

HP 35s Review
Message #1 Posted by Will Rutherdale on 12 Sept 2007, 12:56 a.m.

I've been using HP calculators for decades and own several. Last summer I tried updating to newer models, and have acquired a 33s, a 50g, and now a 35s.

I want a calculator with a good mix of discrete and scientific capabilities, with a convenient user interface.

After a couple of days of trying the 35s out, I have some comments. These are just my personal usability concerns. I realise the calculator has already been released and probably won't be changed.

This is my first posting here. I hope they formatting comes out okay.

Good ~~~~

- adds logic operators (compared with 33s) - good notation (i / theta) for entering complex numbers - nicer keyboard layout than 33s - good that funny mode keys are gone - arrow keys are better - big ENTER key is nice to see again - better look and feel - addition of extra units and physical constants is very useful

Problems (in order of decreasing priority) ~~~~~~~~

- forced to fish out the 'h' suffix when entering a hex number, even when in hex mode - this is very inconvenient if you want to enter a lot of hex numbers - it takes too many keystrokes to get that 'h' suffix, which should be implicit in hex mode - user is now forced to enter a mantissa part for a number in scientific notation - standard interpretation in HP calculators for decades has been to default to 1 - for instance 'e2' is taken as '1e2' in older models - this is a great keystroke saver and has been in place for decades in all HP calculators, up to and including the 50g and the 33s - sanity check: entering the number 1000 in scientific notation should reduce the number of keystrokes - sometimes the calculator misses a typed key - overzealous debouncing? - sqrt key gives 'invalid data' for complex numbers or negative numbers entered as a complex number - inconsistent with general ability to use transcendental functions on complex - sqrt is easy to implement in complex - y^x key does it anyway when you give an exponent of .5 - there is no way to extract real and imaginary parts of a complex number - location and labelling of hex digits a to f - I realise that layout decisions are not easy, but placing them two rows below the register labels A to D is a bit odd - assuming they hold to the layout, it would be better to at least add some special labels in a different colour for the hex a to f - additional logic operators would be useful: shift, rotate, etc. - compare with 16C or 50g - new vector data type is very thinly supported - no real power to it, just addition of vectors and multiplication by a scalar - it complains on input of a vector of length 0 but not a vector of length 1 - 2*2 lin. solve and 3*3 lin. solve are badly done - user has to fuss with a list of storage registers - better idea: let user enter a set of vector objects into the stack and let calculator operate on those - for instance, 4 length-3 vectors would suffice for input to a 3*3 lin. solver - E key (for Enter Exponent) would be better labelled EE or EEX - this would avoid confusion with the other E keys - would stand out better - when complex numbers are displayed in polar form, it would be useful if the 'theta' character could be rendered differently so as not to resemble zero and eight so much - there should be a way to view complex numbers to greater precision - see for instance how this is done in the 15C - also compare with the scrolling view of large binary numbers in the 35s

Overall Conclusions ~~~~~~~~~~~~~~~~~~~

The 35s has look-and-feel improvements over the 33s and some functionality improvements. However, some interaction issues that affect everyday usage appear to have slipped through.

The 35s ought to be a convenient everyday use alternative to the bigger and more sophisticated 50g, but the 35s has limitations that leave the 50g more suitable for everyday use.

-Will

      
Re: HP 35s Review
Message #2 Posted by Will Rutherdale on 12 Sept 2007, 1:04 a.m.,
in response to message #1 by Will Rutherdale

That didn't come out at all. I'll have to experiment with the formatting and re-post when I get a chance. My apologies.

-Will

            
Re: HP 35s Review
Message #3 Posted by Jeff O. on 12 Sept 2007, 8:39 a.m.,
in response to message #2 by Will Rutherdale

Will,
Edit your post to put [pre] before "Good" and [/pre] after the bunch of "~~~~" under "Overall Conclusion". See this complete explanation of formatting techniques.

                  
Re: HP 35s Review
Message #4 Posted by Will Rutherdale on 12 Sept 2007, 8:12 p.m.,
in response to message #3 by Jeff O.

Thanks for the info. Here's what it was supposed to look like:

Good
~~~~

- adds logic operators - good notation (i / theta) for entering complex numbers - nicer keyboard layout 33s - good that funny mode keys are gone - arrow keys are better - big ENTER key is nice to see again - better look and feel - addition of extra units and physical constants is very useful

Problems ~~~~~~~~

- forced to fish out the 'h' suffix when entering a hex number, even when in hex mode - this is very inconvenient if you want to enter a lot of hex numbers - it takes too many keystrokes to get that 'h' suffix, which should be implicit in hex mode - user is now forced to enter a mantissa part for a number in scientific notation - standard interpretation in HP calculators for decades has been to default to 1 - for instance 'e2' is taken as '1e2' - this is a great keystroke saver and has been in place for decades in all HP calculators, up to and including the 50g and the 33s - sanity check: entering the number 1000 in scientific notation should reduce the number of keystrokes - sometimes the calculator misses a typed key - overzealous debouncing? - sqrt key gives 'invalid data' for complex numbers or negative numbers entered as a complex number - inconsistent with general ability to use transcendental functions on complex - sqrt is easy to implement in complex - y^x key does it anyway when you give an exponent of .5 - there is no way to extract real and imaginary parts of a complex number - location and labelling of hex digits a to f - I realise that layout is not easy, but placing them two rows below the register labels A to D is a bit odd - assuming you hold to the layout, it would be better to at least add some special labels in a different colour for the hex a to f - additional logic operators would be useful: shift, rotate, etc. - compare with 16C or 50g - new vector data type is very thinly supported - no real power to it, just addition of vectors and multiplication by a scalar - it complains on a vector of length 0 but not a vector of length 1 - 2*2 lin. solve and 3*3 lin. solve are badly done - user has to fuss with a list of storage registers - better idea: let user enter a set of vector objects into the stack and let calculator operate on those - for instance, 4 length-3 vectors would suffice for input to a 3*3 lin. solver - E key (for Enter Exponent) would be better labelled EE or EEX - this would avoid confusion with the other E keys - would stand out better - when complex numbers are displayed in polar form, it would be useful if the 'theta' character could be rendered differently so as not to resemble zero and eight so much - there should be a way to view complex numbers to greater precision - see for instance how this is done in the 15C - also compare with your scrolling view of large binary numbers in the 35s

                        
Re: HP 35s Review
Message #5 Posted by Karl Schneider on 13 Sept 2007, 12:30 a.m.,
in response to message #4 by Will Rutherdale

Will --

Good, thoughtful assessment. Some of the items you mentioned had been discussed previously.

I soon expect to prepare a short paper on suggested improvements for the HP-35s, not for general release until October. Most of this will address the complex-number issues you mentioned.

Some comments:

  • A full set of bit-manipulation functions might be expecting too much. PC-based software handles that work today; there never was a replacement for the HP-16C.

  • "Enter Exponent" has been labeled E instead of EEX since the Pioneer-series models, which displayed exponents with preceding "E" instead of a right-justifed value.

  • I haven't tried the linear solution yet (and I expected that it would utilize vectors), but the best way to do it is within matrix functions, which are not offered. One must also be able to store the input data and result, so it's either 15 variables or 5 vectors for a 3x3 system.

-- KS

Edited: 13 Sept 2007, 1:24 a.m.

                              
Re: HP 35s Review
Message #6 Posted by Will Rutherdale on 14 Sept 2007, 8:53 a.m.,
in response to message #5 by Karl Schneider

My list of problems was meant to be in order of decreasing importance, i.e. most important items first. The matrix operations no matter how you look at them have been badly done through half-measures. I would be perfectly happy to see them just drop the linear algebra support altogether.

I have found a new high importance item: XEQ.

It now requires you to hit ENTER after the label, unlike the 33s or any reasonable calculator I've worked with. This is bad at a number of levels. It's bad programming practice to jump into the middle of a subroutine. It's also a well-known principle in programming language design that users should only pay for what they use. And it defeats one of the purposes of writing the routines on the calculator, which is to save keystrokes on long operations.

Concerning shift operators, there's a LOGIC submenu anyway, which has room for extra stuff. And the 50g has a good set of shift operators. However you can get what you want most of the time with scaling by powers of two.

-Will

                                    
Re: HP 35s Review
Message #7 Posted by Jeff O. on 14 Sept 2007, 1:08 p.m.,
in response to message #6 by Will Rutherdale

Quote:
I have found a new high importance item: XEQ.

It now requires you to hit ENTER after the label



As I see things, the labelling paradigm implemented on the 35s essentially makes every line number a label. If you key in the whole label identifier, which is a letter followed by three digits, you do not need to press ENTER. If you want to start a program that begins at line no. 1 (where the actual label letter is), you may press XEQ, letter, ENTER as a shortcut instead of pressing XEQ - letter - 000 or 001. So it adds one keystroke to kicking off programs that start at line no. 1, but the ENTER shorcut save 2 keystrokes from what it would have been without it. This was the trade-off needed to get around the severe limitation of the 26 program labels of the 32s/32sII/33s models. I guess a possible alternative would have been to allow branching directly to line numbers only during program exectution. From the keyboard, you could only start 26 programs, but they would start immediately after pressing XEQ - letter. I guess I feel that the added ENTER required by the method chosen by HP is worth the increased flexibility of programming that it offers.
Best Regards,
Jeff
                                          
Re: HP 35s Review
Message #8 Posted by Gene Wright on 14 Sept 2007, 2:23 p.m.,
in response to message #7 by Jeff O.

Hey, the original way it was going to work was to ALWAYS require XEQ label 3-digit line number.

Even for the normal "Start a program at line 001" situation.

I imagine that would have been greeted with a great deal of irritation.

So, the XEQ label ENTER shortcut was devised.

I personally find it very easy to remember and press when I want to run a label.

Remember that the 35s was a modified HP 32SII / HP 33S programming paradigm.

I view this as an excellent compromise. If someone doesn't like it, they can always use the 384 byte HP 32SII.

:-)

                                                
Re: HP 35s Review
Message #9 Posted by Ed Look on 14 Sept 2007, 3:41 p.m.,
in response to message #8 by Gene Wright

Boy, imagine that- a 32SII with 30 kb!!

But the 35s appears to be AT LEAST as nice to use as the 32SII. In fact, after having been using the 33s, 35s, and the 48G+, 49G+, the single stack level display of the 32SII seems confining!

Yeah, yeah, I know... REAL HP users keep track of their stacks in their heads...

                                                
Re: HP 35s Review
Message #10 Posted by Will Rutherdale on 15 Sept 2007, 12:38 a.m.,
in response to message #8 by Gene Wright

The history is unimportant, it's the end result that counts. There is such a thing as a good compromise and such a thing as a bad compromise. The XEQ as implemented is the latter.

As Jeff stated, another alternative might have been to never prompt for the line offset at all at the user level. Better still IMHO would be to not have line number references at all. You shouldn't need them if you can write good code.

The pride of HP in the old days was its RPN, which saved a single keystroke once in a while over the algebraic entry alternative. Now we're hearing that it's okay to hit an extra key on frequently used functions. This is not acceptable.

The 15C has a User mode to make it possible to execute user defined functions with a single keystroke. The 50g has the VAR with directory trees, the CUSTOM facility, and keyboard remapping, all with the aim of solving this very problem in multiple ways. It is very important to ease of use to make custom functions as efficient to invoke as possible.

If the prevailing view on the 35s remains sticking with bad ideas like adding extra keystrokes to XEQ, then it will never be a good product and people will have to stay with the 50g for everyday calculating use.

If HP had simply taken the 33s and added nicer keys and a LOGIC menu, then I would have been happy with it. Instead it's been ruined by misguided design ideas.

-Will

Quote:
Hey, the original way it was going to work was to ALWAYS require XEQ label 3-digit line number.

Even for the normal "Start a program at line 001" situation.

I imagine that would have been greeted with a great deal of irritation.

So, the XEQ label ENTER shortcut was devised.

I personally find it very easy to remember and press when I want to run a label.

Remember that the 35s was a modified HP 32SII / HP 33S programming paradigm.

I view this as an excellent compromise. If someone doesn't like it, they can always use the 384 byte HP 32SII.

:-)


                                                      
Re: HP 35s Review
Message #11 Posted by Meenzer on 15 Sept 2007, 2:08 a.m.,
in response to message #10 by Will Rutherdale

Will, the idea behind having XEQ-LABEL-ENTER and XEQ-LABEL-Line Number implemented is to have more than 26 (A-Z) entry points for different(!) programs (remember the 32kB). This way you could have, say, 15 independent programs under the A label and start them independently with relative ease. It's not meant to start one(!) program from different entry points (though you can cerntainly (ab-)use it that way).
The user mode on the 15C is very nice but you only need five entry labels due to the very limited memory. ;-)

                                                            
Re: HP 35s Review
Message #12 Posted by Will Rutherdale on 15 Sept 2007, 9:29 a.m.,
in response to message #11 by Meenzer

Okay, perhaps the new XEQ notation has a better purpose than I at first surmised.

However, there's still a very good reason why minimum keystroke function invocation is needed. Single keystroke is the most desirable. Rather than talking in generalities, I'm going to break open a new thread analysing an example.

-Will

Quote:
Will, the idea behind having XEQ-LABEL-ENTER and XEQ-LABEL-Line Number implemented is to have more than 26 (A-Z) entry points for different(!) programs (remember the 32kB). This way you could have, say, 15 independent programs under the A label and start them independently with relative ease. It's not meant to start one(!) program from different entry points (though you can cerntainly (ab-)use it that way).
The user mode on the 15C is very nice but you only need five entry labels due to the very limited memory. ;-)
                                                      
Re: HP 35s Review
Message #13 Posted by Don Shepherd on 15 Sept 2007, 7:58 a.m.,
in response to message #10 by Will Rutherdale

Let's see; 1 extra keystroke to execute a program, or 800 registers? I think I'll take 800 registers.

                                                            
Re: HP 35s Review
Message #14 Posted by Arne Halvorsen (Norway) on 15 Sept 2007, 8:22 a.m.,
in response to message #13 by Don Shepherd

If this is the trade I would gladely had two extra keystroke for 800 registers AND some I/O :-)

      
Re: HP 35s Review
Message #15 Posted by Patrick Rendulic on 12 Sept 2007, 4:28 a.m.,
in response to message #1 by Will Rutherdale

Hello. I also noticed a problem with the keyboard concerning missed keystrokes. Inconsistency between former calculators bothers me also. I bought my 35s almost a month ago. It has been laying in a drawer for 2 weeks now. I prefer working with my other HPs.

      
Re: HP 35s Review
Message #16 Posted by Meenzer on 12 Sept 2007, 11:45 a.m.,
in response to message #1 by Will Rutherdale

Quote:

- there is no way to extract real and imaginary parts of a complex number



Try this: write a program that does left shift-ARG and right shift-ABS on the complex number (x i y) in order to obtain the angle a and the hypotenuse h of the corresponding polar coordinates. Then cos(a)*h is the x and sin(a)*h is the y of the complex number.
You could put the complex number in the X register, xeq the program and have it leave the real and imaginary part in the x and y registers respectively.

            
Re: HP 35s Review
Message #17 Posted by Will Rutherdale on 12 Sept 2007, 8:18 p.m.,
in response to message #16 by Meenzer

You are correct, it can be computed that way. What I meant was, there's no predefined interface to do it. Any complex number implementation is going to give you that as part of the interface since it's so fundamental to working with complex numbers. Look at the standard C++ complex type, or the HP 15C, or the 50g as examples.

Quote:


Try this: write a program that does left shift-ARG and right shift-ABS on the complex number (x i y) in order to obtain the angle a and the hypotenuse h of the corresponding polar coordinates. Then cos(a)*h is the x and sin(a)*h is the y of the complex number.
You could put the complex number in the X register, xeq the program and have it leave the real and imaginary part in the x and y registers respectively.


                  
HP-15C programs for complex operations
Message #18 Posted by Karl Schneider on 13 Sept 2007, 12:56 a.m.,
in response to message #17 by Will Rutherdale

Quote:
Any complex number implementation is going to give you (extraction of real or imaginary parts of a complex number) as part of the interface since it's so fundamental to working with complex numbers. Look at the standard C++ complex type, or the HP 15C, or the 50g as examples.

"Fetching" either part of a complex number is easy on the HP-15C as you suggest, using STO and Re<->Im. Here are keystroke sequences to emulate the RPL "C->R" (inverse of RPL "R->C" or HP-15C "f I"), and the other RPL-model and HP-42S functions on the HP-15C:

"C->R"       "Re"        "Im"       "Conj"     "Sign"    "Neg"

ENTER Re<->Im CLx Re<->Im ENTER CHS Re<->Im CLx Re<->Im CHS ABS Re<->Im CLx Re<->Im Re<->Im / CHS Re<->Im Re<->Im x<>y CLx Re<->Im

Only the "Sign" function (normalization to unit magnitude) uses an "extra" stack level for computation.

Even though it was rather impractical to include these necessary complex-argument operations as built-in functions (due to limited available keyboard and ROM space), the basic functions were designed to make them possible. That's why CLx and CHS operate on only the real part of a complex number.

This, and the complete complex-domain functionality for transcedental functions (in all likelihood, a first for a handheld calculator) is part the HP-15C's excellence.

-- KS

Edited: 14 Sept 2007, 12:26 a.m.

                        
Re: HP-15C programs for complex operations
Message #19 Posted by Eric Smith on 14 Sept 2007, 7:55 p.m.,
in response to message #18 by Karl Schneider

Quote:
This, and the complete complex-domain functionality for transcedental functions (in all likelihood, a first for a handheld calculator) is part the HP-15C's excellence.

Gotta agree with you on this one, Karl! :-)

      
Re: HP 35s Review
Message #20 Posted by J Lustig (CA USA) on 12 Sept 2007, 6:04 p.m.,
in response to message #1 by Will Rutherdale

Hello- I was just readying this when I saw this post, so I thought Iíd use it as a reply.

Iíve been lurking here off and on for a long time. Iíve been a big fan of HP calculators since the beginning, collected a few (67, 41cv, 32, 32sII, 48, 33s, and 35s) but, though Iíve always used them for work and play, Iím not a power user. Itís always interesting to here from people who feel the way I do about these little gems. Now I finally have something to say and ask.

The new 35s is wonderful for itís look and feel. Iíve missed this button style since the 41 (& 48) slipped away. The 35s buttons are beyond reproach. One of the most important parts of the HP calculating experience is the positive feed back and solid feel, not to mention durability. And we have the proper ENTER key back. But I think they miss calculated (if youíll excuse me) in one regard and Iíd like some feedback, maybe Iím just ignorant. It seems to me that the keyboard is a skewed in favor by programming key layout and that routine calculating suffers for it. The roll down and X<>Y keys should be immediately next to the ENTER key, the X<> should be close by and maybe on the face of a key. Also, as has been discussed, a quick polar/rectangular conversion would help, as it always has. Perhaps most importantly the STO key should be on the face of a key. This could be done easily by moving the sqr. root, Y^X, and 1/X keys up and SIN, COS, & TAN keys to the right to make room for STO, RCL, and roll down just above the ENTER.

It seems to me that computers are used far more easily for almost everything that programmable calculators started to be used for, and besides, without real label names and real names for output (ie. 41, 42) the usefulness of programming a calculator is further crippled by arcane and arbitrary single letter labels that are hard to remember. I have fun with the programming and Iím sure many people use it to good effect. But I think a calculator should be a calculator first and programmable second- if and where thereís a trade off (in keyboard space) to be made. Programming would still be quite easy and calculating would be even easierÖ

Any thoughts from anyone?

            
Re: HP 35s Review
Message #21 Posted by RonHudson(USA) on 12 Sept 2007, 7:57 p.m.,
in response to message #20 by J Lustig (CA USA)

1) Is there any way to share programs/backup the machine? USB perhaps?

2) Programmables have an advantage over the laptop, even the real small laptops like the palm folio (rip) they fit in pockets (perhaps big pockets...)

But I do agree: all of the calculating functions should be on the face keys and programming (except run) should be relegated to f- ang g- shifted keys.

(Or even better yet - You plug in your trusty HP-2007XL into your USB and it appears on your desktop like a thumb drive. The registers are kept in a file with NAME=VALUE pairs that you can edit with notepad, the programs each in their own file are also notepad editable (RPL? Lisp? Forth? Python? All the above?) and while the calculator is connected it can still calculate. Your laptop also has an emulator that can run off the same memory. It's all file so you can copy stuff on and off at will)

Sorry - I know it's not the "Dream Designs" thread... :^)

            
Re: HP 35s Review
Message #22 Posted by Will Rutherdale on 12 Sept 2007, 8:32 p.m.,
in response to message #20 by J Lustig (CA USA)

Yes, the 15C for example has the basic editing keys like x<>y all clustered together, with STO and RCL at top level.

I agree, if I have to program I pull out Perl or C++ rather than struggling with a calculator language.

The use case of Hex numbers is a good one. Once in a while I need to go over part of a debug listing by hand. There must be 50 PCs running Windows or Linux in the immediate vicinity in the office. Each has a Calculator accessory that does hex conversions and binary operations.

The only way I can justify my use of the calculator in that situation is convenience. But if the calculator makes me use a minimum of 3 keystrokes each number to add the 'h' suffix, even though I'm in Hex mode, it just isn't worth it.

The calculator should have been reviewed by an experienced HP calculator user before being shipped. Perhaps they just rushed it to meet their 35th anniversary deadline. The result is no showpiece.

The 35s could be turned into a decent product, if they looked at some of the suggestions and fixed it up. Whether to change the model name would be up to them.

-Will

            
Re: HP 35s Review
Message #23 Posted by DaveJ on 12 Sept 2007, 10:55 p.m.,
in response to message #20 by J Lustig (CA USA)

Quote:
But I think they miss calculated (if youíll excuse me) in one regard and Iíd like some feedback, maybe Iím just ignorant. It seems to me that the keyboard is a skewed in favor by programming key layout and that routine calculating suffers for it.

Correct, it is a machine optimised for programming, not for ordinary day to day calculator usage. This has been discussed on here before.

Quote:
The roll down and X<>Y keys should be immediately next to the ENTER key, the X<> should be close by and maybe on the face of a key. Also, as has been discussed, a quick polar/rectangular conversion would help, as it always has. Perhaps most importantly the STO key should be on the face of a key. This could be done easily by moving the sqr. root, Y^X, and 1/X keys up and SIN, COS, & TAN keys to the right to make room for STO, RCL, and roll down just above the ENTER.

It seems to me that computers are used far more easily for almost everything that programmable calculators started to be used for, and besides, without real label names and real names for output (ie. 41, 42) the usefulness of programming a calculator is further crippled by arcane and arbitrary single letter labels that are hard to remember. I have fun with the programming and Iím sure many people use it to good effect. But I think a calculator should be a calculator first and programmable second- if and where thereís a trade off (in keyboard space) to be made. Programming would still be quite easy and calculating would be even easierÖ

Any thoughts from anyone?

I agree. Small calculators (read-small one or two line screen, non-graphing) should be a scientific first and foremost. The big graphic calculators like the 48/49/50 TI-89 et.al cater for the programmable market much better, and are much more versatile with their bigger screens.

HP screwed up big time by making the 35S primarily a programmable calc, esp when you compare it with the 33S which has the nice key layout of a good scientific, not a programmable.

Dave.


[ Return to Index | Top of Index ]

Go back to the main exhibit hall