▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
This has probably been discussed here before, but I can't find it:
WHY does this calc display the unary minus in an elevated position?? IMO it looks really ugly, so there must be a technical reason but I am not able to imagine any.
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
Probably in an attempt to make it identifiable. Unfortunately the unary minus is one of those nevergetitquiteright "features". Although different from each other in important ways, I find the 27s approach and the 48 series approach very good and much better than anything in the 32s and its descendants.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
IMHO, the 48 series approach is the same as used in every reasonable HP calculator so far, i.e. 20 micrometer below zero are entered
20 +/ E 6 +/
and are displayed as 2E5 with the minus signs at half the number height.
I find the 27s approach strange because you must use the binary minus to enter a negative exponent, e.g.
20 +/ E  6
meaning you use the operation minus for entering an unary minus.
However, the way to enter such numbers was not my point, but the display of negative mantissae and exponents with a *misplaced* minus. No earlier model does it this way, even the 33s has a correct minus in front of the mantissa at least.
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
Quote:
However, the way to enter such numbers was not my point, but the display of negative mantissae and exponents with a *misplaced* minus. No earlier model does it this way,
Actually, this is incorrect.
The 32sii has the unary minus displayed just as the 35s does, except that it is very bad in the 32sii because in the leading position, the unary minus is not "displaced" whereas it is displaced in positions to the right. (And in the 32sii, the unary minus takes precedence over exponentiation. There is some discussion of this in A DATAFILE article by Jordi Hidalgo, written about the 33s).
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Quote:
Quote:
However, the way to enter such numbers was not my point, but the display of negative mantissae and exponents with a *misplaced* minus. No earlier model does it this way,
Actually, this is incorrect.
The 32sii has the unary minus displayed just as the 35s does, except that ... in the leading position, the unary minus is not "displaced" whereas it is displaced in positions to the right.
The 33s does it the same way as the 32sii. I regarded that as a half way decent display still. Therefore, I wrote "and" in my earlier post (see quote above).
So far, however, no one did explain the reason why to elevate the minus at all. Why not leave it standing on the normal level like in the 48, 42s and all the earlier models? Why make a simple thing complicated? Please explain to me like a 4yearold :)
Edited: 1 Oct 2007, 5:48 p.m.
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Walter:
Walter posted:
"So far, however, no one did explain the reason why to elevate the minus at all. Why not leave it standing on the normal level like in the 48, 42s and all the earlier models? Why make a simple thing complicated? Please explain to me like a 4yearold :)"
I'll try to provide a rationale for it. First of all, I'm not claiming that I'm right or that this is a valid reason from the ergonomic point of view, this is just my opinion.
I think that the display distinction between the subtraction "minus" symbol (correct level) and the unary "minus" symbol (raised) has to do with the fact that, for equationparsing purposes, both are different operations and thus get parsed as unique, distinct internal keycodes, one for the 2argument arithmetic subtraction, the other for the 1argument unary minus.
The distinct symbols are needed because else it would be an ambiguous situation if they were to appear in an equation which some user must key in (from a listing or an screen dump, say). If both were graphically equal, the user could get confused and not know whether he needed to press the "+/" key or the "" key to get that particular "" symbol on the screen.
And why is this important ? Because the wrong key would get you a syntax error. For instance:
A001 EQN SIN(X)
where the "" is obtained by pressing the "+/" key, parses and executes correctly, as it is an unary operation being applied to a single argument X, while the very same equation but with the "" obtained by pressing the "" key results in a SYNTAX ERROR upon execution, as the internally parsed keycode corresponds to the 2argument subtraction operation and here it's missing its left argument.
Hope that helps.
Best regards from V.
Edited to correct a glaring typo
Edited: 2 Oct 2007, 5:40 a.m. after one or more responses were posted
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
Hi Valentin:
What you point out about syntax is what I like about the 48, and the 27s, even though they are different. There is only one thinga minusand it is parsed by its location (in the 48) and in the 27s, there isn't a +/ in the equation parseryou get beeped at and that is that. In both cases, it parses like on paper (more or less:).
Posts: 4,587
Threads: 105
Joined: Jul 2005
Buenas dias, Valentin, y muchas gracias! Finally, this is a reasonable explanation. So the strange display is because of the equation function only. Well :/
After this, I'd like to second Bill. When you key in an equation, you use your calc in kind of alpha mode. So a "" is a "" is a "", and the parser should be intelligent enough to separate unary and binary "".
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
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.
▼
Posts: 150
Threads: 6
Joined: Sep 2007
Well, there is a use for having unary and binary minus entered and displayed in different ways on the HP 35s  and receiving a "Syntax Error" when having done it the wrong way:
Suppose you wanted to kex in sin(yx) as an EQN but you accidentally skip the y and key in sin(x). When you now XEQ the equation, the HP 35s will respond with a "Syntax Error" because it parses a binary minus where it expects a unary minus. So you have the chance to correct your mistake which you would not have had, had the 35s assumed that the binary minus should be a unary one.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
THINK!
(Sorry, else we'll end with calcs asking "Is the operation you pressed the one you really meant?" and similar stuff. Or in German: Für jede Sicherheitsregelung findet man einen Menschen, der sie braucht.)
▼
Posts: 150
Threads: 6
Joined: Sep 2007
Quote:
THINK!
Here is no reason to scream!
If you view it your way (and you're entiteled to do so), there is no reason for syntax or grammar in any programming language or even error messages. If you only think hard and long enough why the result is not as expected, you will eventually find out what you typed in wrong. In the worst case scenario however, you'll never know that you made a mistake in the first place because you have no indication that the result could be wrong...
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
You are right in Mainz, of course. BTW, I wasn't screaming, just quoting a famous little frame posted over the desk of an IBM chairman in the sixties (which you cannot know presumably).
As you do, I appreciate any support for users of a technical device like a scientific calc is one. There is a limit, however, where well meant support starts being an encumbrance. IMHO this limit is reached where the user is confused or annoyed by such "help". And that was my starting point for this thread.
Edited: 2 Oct 2007, 10:15 a.m.
▼
Posts: 150
Threads: 6
Joined: Sep 2007
Quote:
I wasn't screaming
FYI, words in capital letters are considered screaming in forums and such...
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
Well, not automatically. It is contextual. What did you learn firstto read, or to read the internet :)
Posts: 4,587
Threads: 105
Joined: Jul 2005
Buenas dias una vez mas, Valentin,
thanks for your insight into preparsing. That exactly was what I had in mind when thinking about modern calcs with processors exceeding the power of those antique ones by far. But, as you wrote: Those were the times, my friend ...
Edited: 2 Oct 2007, 6:39 a.m.
Posts: 217
Threads: 21
Joined: Aug 2007
Quote: 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's a lame excuse on Mathematica's part. There is no ambiguity using parentheses for both grouping and function calling. The somewhat more well established mathematical package Maple has no trouble using parentheses for both grouping and function calling. The same can be said for 99% of the programming languages out there. Heck, even Fortran managed to do this in the 1960s.
The only place I've ever seen a valid reason for two different minus signs is in APL. There, the traditional "" symbol was used for both subtraction and negation. The raised minus symbol was used as part of a number. In other words, "" was always an operation, whereas the raised minus was basically a number entry symbol, just like the digits and decimal point were. The reason this was necessary in APL is because of the vector syntax. Consider the following examples (where I use "_" to represent the raised minus):
1 2 3
_1 _2 _3
1 _2 3  _4 5 _6
5 _7 9
So the raised minus ("_") applies only to individual syntactic numbers, whereas "", whether unary or binary, applies to expressions.
Stefan
Edited: 2 Oct 2007, 3:32 p.m.
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Stefan:
Stefan posted:
"That's a lame excuse on Mathematica's part. There is no ambiguity using parentheses for both grouping and function calling."
That's a subjective opinion on your part and unless you sustain it with valid arguments it doesn't have to necessarily be taken as the truth.
As this is an offtopic matter as far as HP calculators are concerned, I won't enter into a long discussion about it and this will be my last message on the subject, but let's check your "no ambiguity" statement.
Mathematica is a very complex software package which has to deal with extremely complex mathematical symbolic objects and operations. As such, it is essential that no ambiguities are allowed to crop in, and every distinct object or operation must have a distinct, nonambiguous set of symbols associated with them.
Classical mathematical notation uses parentheses for at least two different, nonrelated purposes: (1) To define grouping of operations so as to be able to specify a particular order (2) to enclose the arguments to be passed to a function. Both uses have nothing to do with one another, and having the same symbol for both of them is potentially ambiguous and inconsistent.
For instance, suppose that you find this expression:
Scale ( Adist + Bdist)
what is the intendend meaning ? It could be interpreted two ways, namely:
 A variable, Scale, which multiplies the sum of two variables, Adist and Bdist, or
 A function, Scale, which is passed the sum of two variables, Adist and Bdist, as an argument to operate upon.
Unless you know substantial additional information about the environment where that expression will be evaluated, you can't tell which interpretation applies, i.e., the meaning is ambiguous.
Mathematica's development team realized this problem and cut the feet under it at once, preferring to promote consistency rather than indulging in extra programming to further promote ambiguity.
Thus, in Mathematica you'll have:
Scale ( Adist + Bdist) for the first interpretation
Scale[ Adist + Bdist ] for the second interpretation
and I don't see the lameness nor the excuse at all.
Thanks for your comment and
Best regards from V.
▼
Posts: 217
Threads: 21
Joined: Aug 2007
Quote: Mathematica's development team realized this problem and cut the feet under it at once, preferring to promote consistency rather than indulging in extra programming to further promote ambiguity.
Thus, in Mathematica you'll have:
Scale ( Adist + Bdist) for the first interpretation
Scale[ Adist + Bdist ] for the second interpretation
Or they could have just required a multiplication symbol whenever multiplication was desired. That's less intrusive than making people learn a whole new syntax for function calls. In fact, I don't think implied multiplication is allowed in Mathematica, although I could be wrong about that.
Stefan
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi again, Stefan:
Stefan posted:
Best regards from V.
Posts: 1,792
Threads: 62
Joined: Jan 2005
Hi, Stefan 
You posted,
Quote:
There is no ambiguity (in Mathematica) using parentheses for both grouping and function calling.
This brings to mind the Fortran constructs (at least, in '77 and previous) for arrays and function calls. Fortran was originally developed for input devices having austere keyboards that lacked many of the characters of modern 101 or 102key Englishlanguage keyboards. "{ }" and "[ ]" were unutilized in the language, for example  and likely unavailable in the early days. This led to ambiguities that had to be resolved by rule and context:
The statement
A = B(3, 4)
could be interpreted as either
"A is the result returned by function B using input arguments 3 and 4"
or
"A is set equal to element (3, 4) of array B."
The only way to distinguish functioninvocations from arrays was that, if B was declared in the routine's nonexecutable code as an array, it would be handled as such. Else, B was a function, which would not need to be declared because Fortran did not require prototyping  unless, of course, B was an internal function, which would be defined in the routine, and unavailable to other routines.
Implicit multiplication  which was not supported by these versions of Fortran  would have added a third possibility, as long as only one item was enclosed within the parentheses. This brings to mind the following: "(3, 4)" could also represent a complex number, in which case "B(3, 4)" would be improper syntax.
 KS
Edited: 4 Oct 2007, 12:29 p.m. after one or more responses were posted
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
And to Valentin's point, these ambiguities did nothing to improve or simplify FORTRAN.
Posts: 125
Threads: 11
Joined: Jun 2007
It is written this way in many mathematical and scientific texts. Since this is the way I write it myself, I rather like it. Perhaps it might have been better one pixel lower???
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Quote:
Perhaps it might have been better one pixel lower???
I'd like to see it TWO pixels lower.
Quote:
It is written this (elevated) way in many mathematical and scientific texts.
(Text in parentheses is from me).
Please show some examples (or link to them). So far, I've only seen unary minus printed in the normal position like a binary minus.
