|Re: HP35s - the minus sign|
Message #4 Posted by bill platt on 31 July 2007, 7:36 a.m.,
in response to message #3 by Nenad (Croatia)
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,
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.