A bit of history (was Re: HP35s Display Of Sign) Message #9 Posted by Valentin Albillo on 2 Oct 2007, 5:32 a.m., in response to message #8 by Walter B
Hi again, Walter:
Walter posted:
"Buenas dias, Valentin, y muchas gracias!"
"So a '' is a '' is a '', and the parser should be intelligent enough to separate unary and binary ''"
From a purely ergonomic and traditional point of view, I do agree that both the unary minus and subtraction symbols have both always been portrayed in math literature as the one symbol "", no questions about that.
However, there exist very well known, stablished math software which departs from tradition and perhaps ergonomy in the name of mathematical consistency. That would mean that, since unary minus and subtraction are wholly different operations, it isn't consistent to have just one symbol to represent both and thus each should be assigned a unique symbol.
This is seen, for instance, in Mathematica, one of the worldwide famous, leading math packages. In Mathematica, to mean "sine of X" you must write it this way:
Sin[X]
i.e.: using square brackets for the argument of the sine function, instead of the traditional parentheses seen in math literature everywhere. This bold departure is grounded in sound consistency reasons, because parentheses already have a use, namely to change order of evaluation, and have no business being also used as argument delimiters, this would only create ambiguities which, for a powerful symbolic package, can't be tolerated. So mathematical consistency it is, and tradition must take a back seat.
That said, I think the HP35s design team were a little lazy on this one, because for such a product there's no valid reason to annoy the user by having two distinct "" symbols where consistency isn't paramount and it would have been quite easy to avoid.
For instance, vintage SHARP BASIC handhelds do parse each algebraic expression as it is entered, recognizing identifiers and substituting them for appropriate internal codes, deciding on the fly
where a "" is a unary operation and where it is a subtraction. Some early models did have a separated, bold "E" for exponents, as opposed to the regular alphanumeric "E", but even that was removed in later models, where "E" would be properly recognized as an exponent or a letter (variable, etc) depending on the context.
A side benefit of this preparsing was increased speed of execution and reduced memory usage, as "RADIANS" would be internally stored as a 1byte token instead of a 7byte alpha string, and would be instantly executed on encountering it again, not reparsed each time.
Some other machines did even better. The HP85, for instance, would parse any algebraic expression entered by the user (for immediate execution or as a program line) into an internal fully RPN representation, which was the one being stored, the original algebraic expression being discarded. Whenever the program encountered the expression, it would execute it directly in its RPN form (similarly to Java bytecodes), no parsing and no further conversion necessary, so speed was maximal. Upon the user requiring a LIST of the program, the RPN expression would be decompiled to algebraic representation just for that one purpose and sent to the output device.
That clever working was normally transparent to the user, who was unaware of the compilingtoRPN, decompilingtooutput procedures, but sometimes the effect was visible: should you enter an algebraic expression with redundant, unnecessary parentheses, the compilation to RPN would get rid of them, and so any subsequent LIST operations would reconstruct an optimized algebraic, with just the right amount of necessary parentheses. So, in a way, it did optimize your expressions for you.
Those were the times ! Sadly, I don't think present day HP has either the spirit or the budget allotment necessary to keep with that "Utmost Excellency Above All" paradigm of old anymore.
Best regards from V.
