Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the '10.4: Be aware of a Calculator widget bug' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
10.4: Be aware of a Calculator widget bug
Authored by: justice on May 24, '05 02:52:57PM

I'm not replying to any one specific post because there are about 10 places where I could jump in with this, and I couldn't pick just one of them.

I'm a mathematician. Pursuing a PhD in mathematics at Georgia Tech, to be more precise. As someone so nicely pointed out, the order of operations is merely a convention. We mathematicians like our conventions, becuase they're the only way that we can communicate clearly in writing. A convention is just that. It cannot be "right" or "wrong". In fact, in advanced, cutting-edge mathematics (yes, it does exist, and it's not adding and multiplying even bigger numbers), there are often competing conventions for things until a field is well-developed enough that a standard emerges. The convention for order of arithmetical operations exists simply so that we do not have to fully-parenthesize every single arithmetical expression.

As far as the debate on if this is a bug or not, I will not call the widget's behavior a bug. It is a horrible inconsistency that Calculator.app and the calculator widget return different answers in response to the same sequence of keypresses. However, I have yet to meet a simple, four-function calculator (meaning can only do addition, subtraction, multiplication, division as arithmetic operations) other than Calculator.app that observes the order of operations. (Please don't tell me that you have one that does sitting on your desk. I'm not saying they don't exist, just that I've never seen one.) Four-function calculators that most people are familiar with behave incrementally, and thus update the display with the result every time a new operation key is pressed. I think the widget behaves in the way that most people would expect a calculator of its appearance to behave.

I believe that Calculator.app behaves improperly in Basic mode, as it doesn't provide sufficient feedback that it is storing up the entire string of symbols entered until you ask for an answer. It looks like a brain-dead, four-function calculator, and thus it would probably be better if it behaved like one. When I switch to scientific mode, I expect it to behave like a scientific calculator, which would mean that it will respect the conventional order of operations. Another poster put it very well when he said that you should use the right tool for the job. If you want to just do some quick arithmetic, you're probably not thinking about order of operations and want things evaluated in the order entered. If you're performing a calculation where you've put in enough thought to have constructed something where you want to enter it as it's written (using the conventional order of operations) and want to have it evaluated following the order of operations, you're not going to use a four-function calculator without carefully thinking about how to enter things.

If you take anything away from this post, it should be two things. First, that the order of operations is a convention for writing down arithmetical expressions. It happens to have been adopted by scientific and graphic calculators as well as programming languages because that's the convention that people were familiar with, but it's essentially about writing down strings of symbols so that there's a well-defined way to evaluate them. Second, I used the words "believe" and "think" a lot in this post. That's because this is an area where it's all based on opinions. It's probably good that this hint was posted, because it made a lot of people aware of the fact that Calculator.app and the calculator widget give different answers when presented with the same key sequence. There's not right answer other than to use the tool that does what you want it to do.



[ Reply to This | # ]
10.4: Be aware of a Calculator widget bug
Authored by: Makosuke on May 24, '05 06:13:11PM

Glad that somebody explained what I was going to say clearly. It is what it is, and that's the way it behaves. If anything, the basic mode in newer versions of Calculator.app behaves in the less-expected manner.

Additional, UI thoughts:

For one thing, a basic "dumb" (meaning four-function, non-scientific, like the Widget) calculator has no parentheses keys, so you can't type in a lot of equations without breaking them down mentally and hitting enter a lot. This is a big reason to remove the order of operations completely and just operate on the previous two entered values.

An additional good reason to limit four-function calculators to a single thread of logic: If you don't do this, there is absolutely no visual feedback as to the equation you've entered, and as such no way to visually verify what the heck you're doing.

Example: If I type 1 + 2 * 3 - 4 / 5 into a scientific calculator, I should see exactly that (as, for example, the tape in Calculator.app shows). If I type that into a dumb calculator, I'd have no confirmation what I typed, either as I'm typing it or afterward--all I see is an answer.

As such, it's clearer from a UI perspective to, once I type 1+2*, have the calculator display the result of that operation, 3, illustrating what I'm about to operate on next, and so on.



[ Reply to This | # ]
10.4: Be aware of a Calculator widget bug
Authored by: chyna4xena on May 24, '05 10:43:10PM
It is nonsense to suggest that the implied order of operations "cannot be right or wrong" - it is right, in the sense that failing to adhere to it will give you the wrong results.

People writing equations are always going to follow the rules, because there are no other alternative "conventions". If there is only one "convention", and it must be followed for accuracy, then it is not a convention at all, but a rule.

If you receive the equation a + b * c, then the correct formula is a + (b * c) because the person writing the equation would have written (a + b) * c if they had meant it to be computed that way. They are not going to think "well, under a different convention, a + b * c does equal (a + b) * c, so its OK to leave it un-parenthesised when what I mean is (a + b) * c".

You said it yourself: "there are often competing conventions for things until a field is well-developed enough that a standard emerges" (my emphasis). The field of arithmetic is indeed well developed, and the implied order of operator precedence is indeed a standard.

And, for reference, scientific and graphical calculators, along with programming languages, did not adopt any mathematical "conventions". They adopted a rule which was already (long, long already) a standard, and they had no choice but to do that. The notion that they arbitrarily chose from amongst a selection of possible implied orders of operation is just plain wrong.

As for the calculator widget, I would not call its behaviour a bug - because the behaviour is clearly intended, and it is correctly re-creating the behaviour of the device it is emulating. A calculator that can only handle dual-operand operations isn't buggy or wrong (it correctly calculates those dual-operand operations), just feature-poor.


[ Reply to This | # ]
10.4: Be aware of a Calculator widget bug
Authored by: thelamecamel on May 25, '05 05:06:12AM

I am most of the way through a 2nd year university course that deals with defining and constructing numbers, addition, multiplication etc. Our PEMDAS convention could have easily been different (say PEASDM), in which case you would get 1+2*3=9.

Of course, we do use PEMDAS when we normally write equations, so if I wrote down 1+2*3, it should be evaluated as 7.

BUT, THIS CONVENTION ONLY HOLDS FOR WRITTEN FORMULAE - there are no axioms about pocket calculators!

Whoever built the first pocket calculator established a new convention for inputting equations, which is sometimes more useful, and often less useful. This convention was established presumably because calculators originally could not handle PEMDAS. The Dashboard widget, as others have remarked, is meant to simulate a cheap, pocket calculator. It is not a scientific calculator.

Written arithmetic is a slightly different language to what you type into a calculator - even a scientific calculator (Would you ever write 4^2 on paper?). Making the languages as similar as possible is useful for people who have written down, mathematically formatted equations to evaluate. But when i'm working out what I want to do as I go along, the pocket calculator arithmetic language is often more useful to me.

The other problem with observing PEMDAS, as highlighted above is that it's mighty confusing without a visible record of what you've typed so far, which would really complicate the widget.

Widgets are fast access programs that you want to use briefly. Whenever i want to make a quick calculation, pocket-style calculators are faster and easier to use. If I want PEMDAS, then i'm doing something more complex, and chances are i'll be evaluating a whole bunch of equations and so would be better served by a proper application.



[ Reply to This | # ]
10.4: Be aware of a Calculator widget bug
Authored by: chyna4xena on Oct 25, '06 06:51:56PM

quote - "Whoever built the first pocket calculator established a new convention for inputting equations, which is sometimes more useful, and often less useful. This convention was established presumably because calculators originally could not handle PEMDAS"

That is not correct.

The first pocket calculators (and cheap ones since) did not establish a new convention for inputting equations at all. They only performed operations on two operands at a time (without exception, this is all that they do) so there was no 'convention' needed about inputting formulae! PEMDAS conventions, etc, have no relevance whatsoever to dual-operand instructions.

That is the point that has been continually missed throughout this discussion - a dual-operand calculator and PEMDAS have [b]nothing[/b] to do with each other.

Then they made calculators which could handle multiple-operand instructions (ie 'equations' or 'formulae'), and at this time, they adhered to the ONLY rule that has ever been accepted for determining the order of operation - PEMDAS.

You say that there are "no axioms about pocket calculators" when you should say, "there are no [b]specific[/b] axioms about pocket calculators because of course they would obey the same rules that everyone else, and everything else, is obeying."

quote - "Written arithmetic is a slightly different language to what you type into a calculator - even a scientific calculator (Would you ever write 4^2 on paper?)."

That is a furphy. The difference between "4^2" and a "4" with a superscripted "2" is zero - there is no difference between them. They are the same number ... 16.

The written language of arithmetic, and the language of scientific calculators, is identical, because scientific calculators were specifically designed to correctly calculate the written language of arithmetic, and they were specifically designed to obey PEMDAS in multi-operand equations.



[ Reply to This | # ]