HP35s Display Of Sign



#25

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.


#26

Probably in an attempt to make it identifiable. Unfortunately the unary minus is one of those never-get-it-quite-right "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.


#27

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 -2E-5 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.


#28

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).


#29

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 4-year-old :)

Edited: 1 Oct 2007, 5:48 p.m.


#30

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 4-year-old :)"

      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 equation-parsing purposes, both are different operations and thus get parsed as unique, distinct internal keycodes, one for the 2-argument arithmetic subtraction, the other for the 1-argument 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 2-argument 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


#31

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 thing--a minus--and it is parsed by its location (in the 48) and in the 27s, there isn't a +/- in the equation parser--you get beeped at and that is that. In both cases, it parses like on paper (more or less:-).

#32

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 "-".


#33

Hi again, Walter:

Walter posted:

    "Buenas dias, Valentin, y muchas gracias!"

      You're welcome ! :-)

    "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 pre-parsing was increased speed of execution and reduced memory usage, as "RADIANS" would be internally stored as a 1-byte token instead of a 7-byte alpha string, and would be instantly executed on encountering it again, not reparsed each time.

      Some other machines did even better. The HP-85, 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 compiling-to-RPN, decompiling-to-output 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.


#34

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(y-x) 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.


#35

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.)


#36

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


#37

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.


#38

Quote:
I wasn't screaming

FYI, words in capital letters are considered screaming in forums and such...


#39

Well, not automatically. It is contextual. What did you learn first--to read, or to read the internet :-)

#40

Buenas dias una vez mas, Valentin,

thanks for your insight into pre-parsing. 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.

#41

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.


#42

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 off-topic 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, non-ambiguous set of symbols associated with them.

      Classical mathematical notation uses parentheses for at least two different, non-related 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.

#43

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


#44

Hi again, Stefan:

Stefan posted:

    "Or they could have just required a multiplication symbol whenever multiplication was desired [...] In fact, I don't think implied multiplication is allowed in Mathematica, although I could be wrong about that."

      You're wrong, of course. Implied multiplication is allowed in Mathematica from day one. The mere fact you didn't know about it implies that you are criticizing a math package you don't know well, if at all. I don't intend this to sound derogatory, just plain fact.

      As for having a multiplication symbol explicitly stated when multiplication is desired instead of parameter passing, I'll simply quote Mr. Theodore W. Gray, one of the chief creators of Mathematica:

        "It's a mistake to use the same symbols to mean these two completely different things, and Mathematica corrects this mistake by using round parentheses only for order of evaluation, and square brackets only for function arguments [...]

        Although I'm all in favor of interesting, quirky languages fpr writing novels and poetry (English comes to mind), it's really a bad idea to use an ambiguous language for something like mathematics [...]

        An alternative would be to insist on using * for all multiplication [...] We decided it was better to remove an inconsistency than to force people to use an extra symbol. Another option would have been to have Mathematica "know" what was a variable and what was a function. This turns out to have serious consequences and it's really not a good idea."

      As you can see, they thought pretty hard about this and what was best and why. You may disagree, of course, even though you don't seem to know Mathematica in depth if at all, but you can't say that their rationale was just "a lame excuse".

      I rest my case.

    Again, thanks for your comments and

Best regards from V.

#45

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 102-key English-language 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 function-invocations from arrays was that, if B was declared in the routine's non-executable 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


#46

And to Valentin's point, these ambiguities did nothing to improve or simplify FORTRAN.

#47

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???


#48

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.


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP35s Program Four Slings Lift Calculation Jean-Marc Biram (Australia) 2 1,481 12-16-2013, 07:21 PM
Last Post: Jean-Marc Biram (Australia)
  HP35s Calculator Max Rope Tension Program Jean-Marc Biram (Australia) 10 2,941 12-12-2013, 12:03 AM
Last Post: Jean-Marc Biram (Australia)
  Trouble entering a HP35s program line Arno 2 1,052 04-05-2013, 06:28 PM
Last Post: Arno
  HP35s scientific calculator GREG W THOMAS 4 1,328 03-22-2013, 06:49 AM
Last Post: Thomas Radtke
  A new product of Spee Dee Sign d;-) Walter B 180 27,281 12-01-2012, 03:29 PM
Last Post: Richard Ottosen (Denver, CO, USA)
  Can the display for a HP32Sii be replaced with the display from another model? Bruce Larrabee 8 2,142 10-10-2012, 10:05 PM
Last Post: Luiz C. Vieira (Brazil)
  HP35s "MEMORY CLEAR" flashes Mark Paris 1 961 08-31-2012, 07:35 PM
Last Post: Bart (UK)
  HP35S keyboard Nick R 8 1,982 08-01-2012, 01:27 PM
Last Post: Dave Shaffer (Arizona)
  Where should I post new HP35s bugs Andres Capdevila 33 6,128 03-13-2012, 01:00 PM
Last Post: Jeff O.
  HP35s Internal Investigations - new processor? stefan 5 1,497 03-08-2012, 04:48 AM
Last Post: Paul Dale

Forum Jump: