Use Case: Logic Operators



#9

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.

-Will


#10

Hi Will,

I guess it's supply and demand. 99.999999999% of users will need the transcendental functions and not the binary operations. Therefore, it probably doesn't make much sense (economically) to produce a calculator which has RL, RR, RLR, RLB, RRB, etc printed on the keys and sin, cos and tan hidden in some menu. I guess this is also a bit what is flawed with the HP28: It has both the hex and the trig stuff hidden in menus. At least, once the menu is active, you can keep them open and use them with a one keystroke operation. Plus, when in hex, the whole word fits into the display.

Too bad your 48sx is broken, it would be the thing to use for you.

Cheers, Peter.

#11

Quote:
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.
That's not quite right. In opposite to e.g. the 32SII, you're always in decimal entry mode. Enter 10 and will get Ah in hex display mode. Only the suffix allows for a different entry mode.

I agree however to everyone thinking that this is not a good design decision.

#12

Will --

Another thoughtful and well-written short essay. That's what a "Forum" is all about.

Quote:
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.


You should consider purchasing an HP-42S from eBay. This quality compact model was discontinued in 1995, but has all the base-arthmetic, logic, and transcedental math functionality (inlcuding modulo division) that you mention. The hexadecimal/octal/binary words are 36-bit 2's-complement signed integers.

I agree with you that the HP-16C had the best binary-mathematics capabilities and that those of the RPL-based models were poorly conceived. Here's an archived post on the topic:

Hex base-integer conversion -- HP-16C versus others

-- KS


#13

Thanks for the encouragement, Karl. I also found your link informative.

Keeping to the KISS principle (keep it simple, stupid), I followed the path of least resistance and programmed the two functions I want on the 50g, calling them SHL and SHR. I then created a custom menu containing the main commands I want and my new shift functions.

In the process I was reminded of how annoying RPL is because the loops are test-at-bottom rather than test-at-top. So in order to make the command #7 0 SHL work correctly, i.e. produce #7, I had to put an extra IF into the code before the START loop.

I'm sure looping constructs in RPL have been debated here ad nauseum, so I won't belabour the point. Suffice it to say that the 50g is not a pretty machine, but it can be made to do what you want sometimes.

The next obstacle is the two extra keystrokes needed per number entered, i.e. <left-shift> #. In the 16C this isn't needed. And of course I might want to see if I can make my SHL and SHR routines accept either a binary or a regular number for the second operand.

-Will


#14

Mostly for interest's sake, I did a full implementation of the 16c's logic operations in *fix (the OpenRPN implementation language). Most of the work is done in *fix which is essentially RPL so porting to a 48/49/50 wouldn't be difficult.

The code is available on sourceforge I think.

As for avoiding the '#' prefix some sysRPL magic ought to be possible if you are really keen.


- Pauli


#15

I've spent more time investigating both the 16C and the 50g. As before, my main criterion is simple usability for repeated hex calculations.

With my new custom menu, the 50g has all the functionality I want. However, it has usability problems in entering numbers. Not only does the '#' prefix require two keystrokes, but the digits ABCDEF require hitting the ALPHA key.

Furthermore, the custom menu keys coincide with the ABCDEF location. So if I forget to hit ALPHA I can accidentally change to decimal mode or invoke an AND operation. If I don't forget, I still have the problem that if I am in ALPHA mode I have to terminate it (or hit ENTER) to invoke one of the operators. Thus the operation is not very smooth and is prone to frustration from simple user errors.

The 16C definitely avoids all these problems. It has dedicated keys for all the hex digits, which are always active as such when you're in hex mode. It has the basic logic operators available with two keystrokes each (through the <f> prefix).

One thing the 16C doesn't have is binary (meaning two operand) shift-left and shift-right operators. However, it does have building blocks from which you can construct them. You could use a combination of MASKL or MASKR with AND and RLn or RRn. RLn and RRn are the available two operand rotate operators.

One could implement these new operators as subroutines and invoke them with two keystrokes per use using GSB, I believe. This gives a pretty viable solution with good usability.

So amongst the working HP calculators at my disposal right now, only the 16C seems to give me the hex calculating capability I want.

I haven't used sysRPL. Perhaps that's the only way to do the keyboard mappings necessary to get the 50g to reduce the keystrokes on '#' and the hex digits. The regular keyboard mapping through ASN doesn't look like it quite does it.

-Will

Quote:
Mostly for interest's sake, I did a full implementation of the 16c's logic operations in *fix (the OpenRPN implementation language). Most of the work is done in *fix which is essentially RPL so porting to a 48/49/50 wouldn't be difficult.

The code is available on sourceforge I think.

As for avoiding the '#' prefix some sysRPL magic ought to be possible if you are really keen.

- Pauli


#16

I thought this comparison might help put it in perspective.

The following chart shows keystrokes required for various operations.


Operation HP33s HP35s HP35sB? HP16C HP50g Win Acc Gcalctool
------------- ----- ----- ------- ----- ----- ------- ---------

+,-,*,/ 1 1 1 1 1 1 1
AND,OR,NOT,XOR NA 3 2 2 1 1 1
SHL NA NA 2 2 1 1 1
SHR NA NA 2 2 1 NA 1
Change base 3 3 2? 1 1 1 1
View other base NA NA NA 2 NA NA NA
Num entry overhead 0 3 0 0 >=2 0 0
RMDR, INT/ 2 3 2 2 1 PS PS

Notes:

[0] "NA" means "Not Available". "PS" means "Partially Supported".

[1] HP35sB is a hypothetical calculator that might be built if HP folks decided to act
on my recommendations. In particular: (a) XEQ reduced to 2-keystroke operation, or
equvalent capability; (b) restore HP33s hex notation so the 'h' suffix does not have to
be entered; (c) provide SHL and SHR operations in the LOGIC menu.

[2] "Win Acc" is the Windows calculator accessory. Gcalctool is a similar tool in
Gnome, i.e. in Linux.

[3] It is assumed that all calculators have been programmed with simple wrapper
functions where appropriate. This would mean:
(a) HP35s: no improvements are possible that will reduce keystrokes
(b) HP35sB: wrappers on all LOGIC menus and change of base
(c) HP16C: my custom SHL and SHR are implemented, like the C operators
(d) HP50g: a CUSTOM menu is created, and SHL and SHR are available there as well
as the main logic and base change operators

[4] The "Num entry overhead" represents extra keystrokes required to simply type in
a number, beyond the actual digit values. In the HP35s this is fixed at 3 for
anything other than decimal, regardless of current mode. For instance in hex you
need the h suffix. In the HP50g, it takes two keystrokes to enter the # prefix.
For hex numbers, you also have to hit the ALPHA key an indeterminate number of
times for the hex digits A..F.

[5] Some of the operations on the HP50g might take an extra keystroke or two for shifting
through the custom menu, but the effect is random and small.

[6] RMDR and INT/ are related discrete math operations. They were in shifted key
positions in the HP33s but got shunted off into menus in the HP35s.

-Will


Possibly Related Threads…
Thread Author Replies Views Last Post
  RPN logic question Victor Quiros 52 11,616 03-12-2013, 02:59 PM
Last Post: Victor Quiros
  HP-65 logic board repair - help required Alberto Fenini 1 1,245 02-17-2013, 06:39 PM
Last Post: John Robinson
  HP-50G Equation Editing Logic Matt Agajanian 4 1,497 04-20-2012, 11:21 PM
Last Post: Matt Agajanian
  The story of HP's Logic Analyzers Steve Leibson 3 1,553 02-19-2012, 11:44 PM
Last Post: Bruce Larrabee
  OT: Help with Logic Dart AC adapter Donald Williams 9 2,799 03-19-2011, 10:22 AM
Last Post: Donald Williams
  j operators Dwight Sturrock 9 2,596 02-12-2011, 11:25 AM
Last Post: Bart (UK)
  USB Logic Analyzer Thomas Chrapkiewicz 7 2,033 03-09-2010, 04:54 PM
Last Post: Adrian Godwin
  Classic Series Logic Board - Desoldering Temp ? John Robinson 7 2,133 09-17-2009, 09:36 PM
Last Post: Dan W
  Voyager series, logic PCA and keyboard PCA Geoff Quickfall 7 2,197 07-28-2009, 04:20 PM
Last Post: Eric Smith
  Technical question; HP-41CV logic PCA Geoff Quickfall 11 3,023 07-22-2009, 01:22 AM
Last Post: Eric Smith

Forum Jump: