|Use Case: Logic Operators|
Message #1 Posted by Will Rutherdale on 15 Sept 2007, 10:25 a.m.
Where I work, there are lots of uses for hex. There are FPGA developers defining interfaces through registers that device drivers have to connect to, for example. There are interfaces between control systems and the devices. There are debug listings often giving values in hex. In some cases, the hex values contain a number of bit fields that have to be separated out for comparison with other values. There are also data streams to look at such as MPEG encodings.
What is needed in this environment, if you're going to use a hand calculator at all, is repeated use of hex conversions and logic operators. It's also nice to have general scientific computing available in the same package in case other stuff comes up.
I have six HP calculators sitting beside me right now. The 48sx is broken. The remaining ones are in perfect working order. 15C, 16C, 33s, 50g, 35s. What will I use for the job?
The 15C is for me the nicest general scientific calculator of the lot, if you're not looking to do much programming. But it has no hex or logic. The 16C has the best hex and logic capabilities ever built into an HP but only one transcendental function: sqrt. The 33s has general scientific combined with hex, but no logic operators and no reasonable way to implement them. The 50g is very powerful but requires a little programming to improve the logic operators and is a bigger calculator than I want to carry around in the lab with me and possibly lose. That leaves the 35s, which is flawed.
Minimal keystrokes for oft-repeated operations is a very important principle in calculator design. If you only enter one hex number every month or so, it doesn't matter how many keystrokes it takes to do it. But if you want to enter dozens in one day, an extra keystroke or so per number makes the job unmanageable and extremely annoying.
The 35s as it now stands forces me to enter 3 extra keystrokes minimum per hex number entered. Those keystrokes are redundant, because I am already in hex mode and am required by someone's inconsiderate calculator design to enter an 'h' character at the end of the number. Those characters are <right-shift> BASE 6. The '6' part is annoying because I have to remember an arbitrary numeric constant, which is bad user interface design. If I don't like the '6', I have an alternative of using the arrow keys. Doing so increases the number of characters to bring up the redundant 'h' to 5.
Then there are the logic operators. They are not right on the keyboard, but in a menu. I accept that for a general-purpose calculator. So to use the NOT operator I enter <left-shift> LOGIC 4. If I don't like the 4, I need two arrow moves, bringing the total to 4 keystrokes.
All right, disregarding the hex problem for a moment, how can we improve on the operators? Ahh, I can write a subroutine for NOT. Okay, I've defined AND, OR, NOT, XOR, RMDR, INTG DIV as A, B, C, D, E, F. Great. Now to negate a hex number, which is a very frequent operation, I need XEQ C ENTER. Three keystrokes for a frequent operation. Not good.
As far as I've determined so far, there is no facility available in the calculator to reduce the keystrokes for the NOT operator below 3. I'm stuck with it.
So from a usability point of view, the 35s would need two improvements. (A) eliminate the 'h' requirement when in hex mode. Nobody argued with me over that one. (B) Provide a rapid-entry subroutine call facility.
Regarding (B), if people are unwilling to part with the extended XEQ, then I would suggest a User mode as in the 15C. The next best alternative would be keyboard mapping, which requires too much extra infrastructure to support.
The great thing about a User mode is that I would only activate it when I need it. It's only a simple notational extension to existing subroutine facilities. When I'm done with my hex calculations, I can switch back into regular mode and have the usual scientific functions available. And when I'm in user mode, I could invoke my frequent functions using just one keystroke.
The other major issue in the Logic use case is shift operators. As I mentioned in another post, there's already a LOGIC menu and they could simply be added there. They're probably not hard to implement internally, as they are low-level operators close to the machine.
One flaw I've noticed in the 50g is that the shift operators exist in multiple forms, but they're all unary operators. What people really want most of the time is a binary shift operator, as in the C language << and >>. In order to extract different parts from an arbitrary hex number, for instance, you want to shift an arbitrary number of bits and do an AND with a mask value. Thus the preferred notation would be a ENTER b LSH.
Summary: People need to recognise the importance of minimum keystrokes for frequent operations. In the 35s one way to provide this would be a User mode. Finally, it would be useful to add binary left- and right- shift operators to the LOGIC menu of the 35s.