HP Forums

Full Version: HP35s - the minus sign
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

-888 (the proper position of the minus sign)

It should be normal that the minus sign in negative numbers is positioned centered with respect to the height (i.e. at the half height). In HP35s display font it is positioned as the "underscore character upside down". This may be also seen in other HP calculators (e.g. in HP32SII, I suppose). This is something that I really don't like.

I am not sure if anybody has already mentioned this as something he/she dislikes. Simply, why wasn't the minus sign positioned in a "normal" way? Obviously, the HP35s font could withstand this.

Please, do not find this as an over criticism of a lovely machine (really, I do not want to be seen by others as one of the two elder gentlemen in Muppet Show, who criticize every performance from its very beginning).

What you are noting is the "unary minus" which is different from the minus sign. This is unfortunately one rather inconsistent solution (going from model to model). It was a real problem on the 32sii with respect to equations--actually had a buggy behavior (see Finseth's HPdatabase). The 33s dramatically improved the unary minus issue, but I haven't looked in detail of how the 35s is handling it, except to note that there was at least one place in the manual that specifically directs the use of the unary minus.

On other machines, for instance those with an RPL kernel, there isn't the same distinction, as a the minus is simply parsed and that is the end of it. If you have a 27s or 17b handy, and a 48 series, you can explore the similarities/differences in the handling of the minus, as well as differences in the function of the +/- key.


Thank you very much for your explanation. AFAIK, in "pencil-and-paper" mathematics there is no need to distinguish between the negative number sign and the subtraction operator. So, I could not figure out (and still cannot) why did the calculator software designers have the need for this.

As a mechanical engineer, dealing with marine engineering in a shipping classification society, I really don't remember a situation where "-" and "-" should be distinguished.

Hi Nenad,

Yes, I have the same feeling about the "unary minus" as a rather bizarre calculator artifact.

I believe it stems from the difficulty of minus as an *operator* as compared to minus as a *condition or state*. Depending on how you design your command interpretation, that can be an issue. In the original RPN paradigm, CHS is in fact an operation and we avoid the whole issue--we "operate" on a stack object one step at a time, and as such there are no issues with precedence etc.

However once you joint the world of "algebraics" this all changes and the issue of what to do about sign operations becomes a problem. In the case of the 32sii there is no difference in the display of a "unary minus" in the 1st position and yet it exists in the paradigm and further causes a problem:

is evaluated to:
on the 32sii equation list.
Compare this to

which evaluates to:
So, the 32sii treats a unary minus without anything
before it as being inside an imaginary set of

(-3)^2. Note that the manual for the 32sii states that
"unary minus" takes precedence over exponentiation, but this was a bad idea and wasn't consistently implemented, for it
it were, then 1-3^2 would have been equal to 10.

Note however that in the 32sii, you can use either the "-"
or the "+/-" to write the unary minus, and furthermore
in all but the 1st position, there is a different appearance
between the "unary minus" and a minus, and yet they do *not*
all parse the same way!

Take these examples:

1-3^2 evaluates to -8
1+-3^2 evaluates to 10
1+-3^2 (with the high position unary minus) evaluates to 10

Note that you can type in the regular looking minus
using either the +/1 or the - *before* typing "3", or you can
put in the high minus by pressing the +/- after pressing the

This is bad behavior of the 32sii equation list was a real
problem until you figured out how to deal with it.
It is totally different from the 48 or the 27 or the 17b.

But regardless of how the "unary minus" looks

On any other algebriac parser from HP,


evaluates to:


On the new 35s, this bug is eliminated; however a unary
minus requires a different syntax--achieved through the
"+/-" key in order to parse successfully.

Furthermore on the 35s, you cannot successfully parse
odd constructions such as 1+-3^2 and so the bad behavior
of the 32sii equation list avioded.

I don't have my 33s in front of me and although I wrote about this aspect of it some years back, I can't remember now how it handles this aspect.

Edited: 2 Aug 2007, 7:42 a.m.