My responses: HP-15C layout Message #18 Posted by Karl Schneider on 19 Aug 2006, 11:40 p.m., in response to message #13 by Paul Dale
Hello, Paul --
My original statement in this thread:
Quote:
The layouts don't quite measure up to the exquisite HP-15C's masterful one, but then again, nothing could...
Your opening and closing responses:
Quote:
I hope you're kidding :-). The 15c has a very good layout but it is by no means perfect.
On rereading this it has a bit nastier tone than I intended ... sorry if this causes offense, none is intended.
No offense taken, but that won't stop me from addressing your comments. I ain't kidding -- of course I believe that near-perfection was achieved in the HP-15C keyboard layout! :-)
Quote:
Why is x<> where it is? The other register operating keys (STO & RCL) are miles away.
What's important is that x<> is used in conjunction with 0-9, .0-.9, I and (i), and A-E -- and most likely 0-9, I, or (i), which are nearby. STO and RCL require one of the same storage identifiers for completion, but are also used repeatedly in conjunction with A-E for matrix work.
Quote:
It also wouldn't be too hard to argue that ISG & DSE should be closer to STO & RCL since they are register based commands in addition to being conditionals.
I don't quite follow your logic. Sure, DSE, ISG, STO, and RCL are usually completed with a register number, but that doesn't make them a functional "family" that should be organized in a grouped location. DSE and ISG are shifted and seldom used; they should be placed where space allows. As program-control commands, they are actually more similar in function to the nearby SF, CF, F?, and the conditional-test functions.
Quote:
In your earlier article you mention that ABS's placement is a carry over from the 12c. If this is true, then it is simply out of place. However, I think that ABS and CHS are sufficiently related to justify the placement chosen.
Actually, it was the HP-11C (as stated in my post). ABS and MEM could be swapped to establish the functional grouping of "Scalar Parts and Values", but most users invoke MEM more than ABS, so keeping MEM closer to its shift key is better. CHS and ABS are functionally related, but ABS is useful only in programs and for taking the magnitude of a complex number. (Also, keeping CHS/ABS the same for the HP-15C allowed HP to use the same key for both the HP-11C and HP-15C.)
Quote:
Why does the 15c's TEST insturction take a 0-9 argument? I would have thought taking 0-5 & .0-.5 would make more sense, be easier to remember and it would free up two other keyboard locations.
Hmm, that's an idea to consider. I wouldn't say that using .0-.5 but not 6-9 is more intuitive, but here's the real problem: How would the codes .0-.5 be shown in the table on the back plate? If the codes aren't printed there, then the manual must be consulted.
Quote:
If you swap X<> and RND, swap DSE and INT and swap ISG and FRAC the register based commands are now located together; X<> is on the same key as X<>Y and INT, FRAC, RND and ABS are also fairly close together.
Yes indeed, but I'll stand by my responses above. True functional grouping is beneficial, but what is even more important are the following:
- Making the frequently-used functions more easily accessible by having them unshifted or close to the shift keys.
- Placing a function close to the keys that are used in order to complete the command.
x<>y and x<> are related, but different in several respects: x<>y is a frequently-used, complete one-stroke command. x<> is less commonly used and needs a register or matrix identifier to complete it.
INT, FRAC, and RND are useful for computational purposes and benefit from placement close to the shift keys. DSE and ISG are not very useful for interactive computations (but can be used to decrement or increment a stored value without disturbing the stack).
DSE and ISG are intended as programming functions; STO and RCL are data-access functions. They both utilize storage registers, but there the similarity ends.
So, in summary, I too like my HP-15C as it is. Certain things could have been done a little better (and I've posted elsewhere in the Forum about them), but the fixes would have entailed some cost in additional ROM space or less-consistent structure.
Best regards,
-- KS
Edited: 19 Aug 2006, 11:55 p.m.
|