The Museum of HP Calculators

HP Forum Archive 20

[ Return to Index | Top of Index ]

the HP-65 required more from the user
Message #1 Posted by Don Shepherd on 5 Aug 2011, 12:19 p.m.

OK, let's discuss something other than a 15c reissue. That conversation is getting boring.

I've always found it interesting that the F-1 shift key on the HP-65 has no key legend present on (or next to) the actual key. HP obviously assumed that the HP-65 user would be astute enough to know about inverse or complementary functions. These are the actual F and F-1 functions on the 65, and none of the F-1 functions are labelled on the keyboard:

key   F        F-1

- SF1 CF1 + TF1 TF1 not x SF2 CF2 / TF2 TF2 not 7 LN ex 8 LOG 10x 9 SQRT x2 4 SIN ARCSIN 5 COS ARCCOS 6 TAN ARCTAN 1 R->P P->R 2 D.MS+ D.MS- 3 ->D.MS ->decimal 0 ->OCT ->decimal . INT FRAC

It seems that current calculator keyboards might be simplified if manufacturers assumed that users knew these things. But I guess that may not be true anymore.

Here's another interesting find in the HP-65 manual:

Quote:
As an additional feature, the "octal to decimal" conversion will accept non-octal arguments containing the digits 8 or 9. A non-octal number such as 998 will be interpreted as (9x82) + (9x8) + 8 = 656.

Wow! That's a "feature"?

Edited: 5 Aug 2011, 1:24 p.m. after one or more responses were posted

      
Re: the HP-65 required more from the user
Message #2 Posted by Marcus von Cube, Germany on 5 Aug 2011, 12:45 p.m.,
in response to message #1 by Don Shepherd

The HP 35 has an ARC key inverting the trig functions. The assumption that HP calculator users know about math is older then the 65. :-)

TI calculators used to have an INV key which works the same but without the implicit shift function as on the 65. On a TI-59 the RTN command is entered as INV SBR.

The downside of an INV or f^-1 key is that a generic additional shift offers more options for assigning functions to keys. In many cases, g acts as f^-1 on HP calculators for the functions/keys where it makes sense but not as a general rule. What is the inverse of |x|? The WP 34S maps RND to the blue shifted and |x| to the yellow shifted zero.

            
Re: the HP-65 required more from the user
Message #3 Posted by Dieter on 5 Aug 2011, 1:09 p.m.,
in response to message #2 by Marcus von Cube, Germany

Quote:
TI calculators used to have an INV key which works the same but without the implicit shift function as on the 65.
Yes, the "2nd" key had to be pressed. And in LRN mode (i.e. during program entry) the sequence even had to be INV 2nd, not the other way round.
Quote:
What is the inverse of |x|?
That's easy: |x| makes the answer non-negative, so the inverse function makes it non-positive - like |x| CHS. #-)

Dieter

            
Re: the HP-65 required more from the user
Message #4 Posted by Thomas Radtke on 5 Aug 2011, 1:11 p.m.,
in response to message #2 by Marcus von Cube, Germany

Quote:
TI calculators used to have an INV key which works the same but without the implicit shift function as on the 65.
You can even 'invert' a 'second' function on some TIs :-).
      
Re: the HP-65 required more from the user
Message #5 Posted by Dieter on 5 Aug 2011, 1:02 p.m.,
in response to message #1 by Don Shepherd

Quote:
OK, let's discuss something other than a 15c reissue. That conversation is getting boring.
Ah, great. :-)
Quote:
I've always found it interesting that the F-1 shift key on the HP-65 has no key legend present on (or next to) the actual key. HP obviously assumed that the HP-65 user would be astute enough to know about inverse or complementary functions.
This technique has been used by TI in various calculators. They had an INV key for similar purposes. On the one hand its use was quite obvious with functions like sin or lnx, on the other hand there were others where it was less so. For instance, on the 58/59 an INV SBR was a simple RTN, pressing INV List printed the data registers, and INV Mean returned ...the standard deviation. #-)

Today most sophisticated calculators offer more functions than even a keyboard with three prefix keys and an additional INV or F-1 can handle. That's why there are menus. The basic problem regarding the keyboard layout is the question which functions might go into a menu and which have to be accessed directly.

Quote:
Here's another interesting find in the HP-65 manual:
...
Wow! That's a "feature"?

Well, I'd say accepting octal values with digits > 7 sounds more like a bug. But then - if it's documented this way, it's fine by me. ;-)

Dieter

            
Re: the HP-65 required more from the user
Message #6 Posted by Mike Morrow on 5 Aug 2011, 1:37 p.m.,
in response to message #5 by Dieter

Quote:
I'd say accepting octal values with digits > 7 sounds more like a bug. But then - if it's documented this way, it's fine by me. ;-)

That's obviously one of many examples in compute-world where a bug is "resolved" through documentation rather than by fixing the error.

Edited: 5 Aug 2011, 1:38 p.m.

            
Re: the HP-65 required more from the user
Message #7 Posted by Juergen Keller on 5 Aug 2011, 1:47 p.m.,
in response to message #5 by Dieter

Quote:
Today most sophisticated calculators offer more functions than even a keyboard with three prefix keys and an additional INV or F-1 can handle. That's why there are menus.
This was already the case with the HP-41. The solution was a fully customizable keyboard with overlays. I like this concept because each individual has its own preferences regarding key assignments. Together with the extensibility via modules it was easy to create a fully customized calculator for special applications. That was a key feature why the HP-41 was so successful.
                  
Re: the HP-65 required more from the user
Message #8 Posted by Ángel Martin on 8 Aug 2011, 3:15 a.m.,
in response to message #7 by Juergen Keller

I completely agree with Jürgen here on the 41 approach: it was a paradigm shift (pun intended), just compare the arguable cluttered 67's keyboard with three (no less!) shift keys to the unassuming simplicity of the 41: a deceiving impression of lack-of power for some, but a masterpiece in human factors design if you ask me.

I've taken the single SHIFT key concept to its full extent on the 41Z, with the "Z" key. Pressed once it "turns" the normal functions into their complex-mode equivalents (no need for key assignments but ZKBRD of course). Pressed twice it accesses the "secondary" complex keyboard (in red on the overlay).

Combining it with the standard SHIFT key produces more options, like "Z"-SHIFT accesses all the shifted-complex keyboard functions (in blue on the overlay), and then "Z", SHIFT, SHIFT goes to the "dedicated" function groups, like Hyperbolics, Multi-valued NEXT, and Bessel functions. A feast of options from within just a single (well, two) key(s).

Cheers, ÁM

                        
Re: the HP-65 required more from the user
Message #9 Posted by Don Shepherd on 8 Aug 2011, 4:22 a.m.,
in response to message #8 by Ángel Martin

Good points Angel and Jurgen.

      
Re: the HP-65 required more from the user
Message #10 Posted by Michael de Estrada on 5 Aug 2011, 1:07 p.m.,
in response to message #1 by Don Shepherd

Corrections:

key_____ F___________ F-1

1_______ R->P________ P->R

2_______ D.MS+_______ D.MS-

Anyways, I never found this system to be very convenient and never understood why HP adopted it, since all their other calcs, such as HP-55 and HP-67 use the f (yellow) and g (blue) shift convention with all the legends being shown. It doesn't really simplify anything, since it has the same number of keys and shifted keys as the HP-67. I imagine that's the reason HP abandoned it on subsequent models.

Interestingly, some non-HP calcs also use this system, such as the Mostek chip based RPN calcs (Corvus 500, Omron 12SR, APF Mark 55 etc.). I find that there is always a slight delay as my brain tries to remember what the inverse function is for one of the missing legends.

As to the octal "feature", I can only say wow ! That's pretty nerdy.

Edited: 5 Aug 2011, 1:12 p.m.

            
Re: the HP-65 required more from the user
Message #11 Posted by Don Shepherd on 5 Aug 2011, 1:28 p.m.,
in response to message #10 by Michael de Estrada

Thanks Michael, I changed the original per your note.

Yeah, that octal "feature", I can't imagine a valid use for such a thing. If you're going to convert octal to decimal, a non-octal digit in your input would be an error I would say, as Dieter pointed out.


[ Return to Index | Top of Index ]

Go back to the main exhibit hall