GNOME Bugzilla – Bug 121710
Calculator ignores operator precedence
Last modified: 2005-08-15 01:33:39 UTC
Steps: 1. Press [1]. 2. Press [+]. 3. Press [2]. 4. Press [*]. 5. Press [3]. 6. Press [=]. Actual result: 9 Expected result: 7 Version: 4.3.2 Architecture: i686 After many years, my Texas Instruments TI-30 still does this correctly ;-)
Just some additional information, the Windows XP program handles precedence correctly in `Scientific' mode, though, not so in `Standard' mode. Also, the latest version of xcalc (4.3.0) does everything correctly as promised (`It should be noted that the operators obey the standard rules of precedence.'). Since gcalctool is an official GNOME 2.4 module, this bug might be a bit dangerous. Users may unknowingly rely on results that aren't correct.
Thanks for filing this. This "bug" needs to be dealt with at some point, so having it commented on in Bugzilla seems to be the perfect place. I've added Calum, my HCI wizard to the Cc: list. This was also discussed on the desktop-devel mailing list a few months back. I can see both sides of the argument, so it's probably going to be an HCI decision on what happens. The one thing I really don't like about the Windows calculator is that you can get different answers depending on what mode you are in. Having said that, if that is what Windows users are used to, perhaps we need to implement something similar. The original calctool (circa 1986) that gcalctool is based on, was modeled on a Sanyo cx250. See: http://groups.google.com/groups?q=calctool+1986+burridge&hl=en&lr=&ie=UTF-8&oe=UTF-8&newwindow=1&selm=41%40yarra.OZ&rnum=2 for more details (and the original source code ;-)
*** Bug 126011 has been marked as a duplicate of this bug. ***
*** Bug 133285 has been marked as a duplicate of this bug. ***
PEMDAS: Parentheses, exponents, multiplication, division, addition, then subtraction. I can still remember it. :) Oh, and a cool mnemonic is "Purple eggplants make delicious afternoon snacks." :)
There is now a version of gcalctool with arithmetic operator precedence. As this is still a work-in-progress, we've setup a separate branch under GNOME CVS to do this. If you've like to try out this new version you can get the latest from GNOME CVS with: % cvs co -r gcalctool-ng gcalctool There is also a .tar.gz snapshot of the initial version at: http://users.utu.fi/~sampie/gcalctool/gcalctool-5.3.42.tar.gz Feedback is appreciated. We want to iron out all the problems before this is merged with CVS HEAD, and included in a future version of GNOME.
I've just tried the operator precedence version... generally I'm pretty impressed with it, most things worked just like I expected (given, of course, that I know about precedence and expect it to work all the time anyway). A couple of comments though: - I couldn't really figure out why the View->Show Answer Numerically option was useful... can somebody enlighten me? (My own calculator has an Ans button, which is useful because with that you can insert the previous answer into the current equation as often as you like, but since gcalctool doesn't have such a button, I couldn't quite see the point...) - Backspace functionality needs to be improved when deleting function names... e.g. to delete "Tan", you shouldn't have to delete the n, a and T individually. - At the moment there are probably too many status bar messages, and some of them are a bit verbose ("Showing answer" is rather redundant, for example)... but they're probably useful while it's still in development so I'm not going to complain about that just now :) - Would be really cool if the error reporting could be improved somehow, e.g. to highlight in the display where exactly the expression parsing broke down, rather than just showing "Malformed expression" in the status bar. - User-defined functions obviously need a bit of work in precedence mode :) If we could move the parentheses buttons into the basic layout, I'd almost be tempted just to have precedence switched on all the time-- one less option for people to worry about, and at the moment it's not really clear to the user when it's getting switched on and off automatically, which has already confused me a couple of times. We certainly need to do a little more research to find out what people *really* expect the behaviour to be though... I know I was taught about precedence at school almost as soon as I was taught how to multiply and divide, but that's the Scottish education system for you :)
I'm going to reassign this one (or try to) to Sami, for him to respond to as he's been the person who's done all this great work.
*** Bug 141320 has been marked as a duplicate of this bug. ***
This is really awful bug. I upgraded from gnome 2.2 to 2.6 and 2.2 does not have this bug in calculator (it was much simplier but does calculations correctly). Now I did some calculations and I had to do it 4 times to understand what's going on... even this is writen in man it is wrong to do calculations like this.
Hi Adam. Have you tried out the gcaltool with operator precedence (see comments earlier in the bug on how to get it). Does that supply what you need?
As I am using rpm based distribution I noticed this comment but was not very glad to compile anything especialy for gnome. OK I installed few megs of devel libraries but I still end up with error during compilation: ------------ LC_ALL=C ./intltool-merge ./po gcalctool.desktop.in gcalctool.desktop -d -u -c ./po/.intltool-merge-cache The OrigTree module doesn't seem to be properly installed ./intltool-merge make[2]: *** [gcalctool.desktop] Error 2 ------------ intltoolize -f -c seems to help. The result is interesting. I have to switch on "Use arithmetics precedence" to make correct calculations. This is not exactly what I expected. As in usuall calculators this is natural to typ 6+3*2 to get 12 and not 19. (Try xcalc for example.) "Use ar. prec." works bit different way as you have to type whole formula first to get result. You do not see intermediate results. It for sure has some advantage, but behaves unusually. That's all.
Thanks for the feedback. Whether "Use Arithmetic Operator Precedence" is checked on or off by default will be decided when this branch is merged by CVS HEAD. Our current thinking is to leave it off for two main reasons: 1/ gcalctool behaviour will be consistent with the previous version. In other words, the user has to deliberatly select the menu item to get what they want, and therefore are aware that a change has been made. 2/ The arithmetic operator code is new, and is thereforte potentially more buggy. I'll let Sami comment on the build and behaviour issues you are seeing as it's his code.
Hi, Adam. Seems you have found the right cure for the build problem. After a couple of minutes of using google I got the impression that the problem is related to intltool (or some other) program version conflict (I am still running Gnome 2.4, perhaps that is the reason why the problem does not occur on my machine). After using Arithmetic Precedence mode, have you found issues that you dislike? Or have you found use-cases in which gcalctool's behavior is unintuitive?
Sami, I understand you are discussing two things - 1. compilation problem whitch is really related to intltool and is relatively easy to solve by intltoolize. 2. If I like the precedence mode. Well hard to say - it is non-standard behaivour for calculators as I know them. It has some advantages and some disadvantages. Advantage is e.g. that you see whole formula in calculators display. Disadvantage is that you do not see intermediate results. E.g. in xcalc (or old gnome calculator) you type on display 6 6 + 6 3 3 * 3 (at this moment I know calculator has operator precedences) 4 4 + 12 5 4 = 23 in gcalctool precedence mode you type on display 6 6 + 6+ 3 6+3 * 6+3* 4 6+3*4 + 6+3*4+ 5 6+3*4+5 = 23 That is the only thing I am pointing to. I assume this is a very different programming aproach too. As first one is doing calculation during user is typing, second starts formula processing after "=" is pressed. I am also almost sure that Scientific mode without precedence is almost nonsens as I never saw formula written like 6+(3*2) but allways 6+3*2 as it is clear that it has to be 12 not 18. (sorry for misstype in may previous comment) Maybe Scientific mode should have precendence as default.
Arithmetic operator precedence mode is now available (in CVS HEAD).
*** Bug 157598 has been marked as a duplicate of this bug. ***
*** Bug 158385 has been marked as a duplicate of this bug. ***
*** Bug 303247 has been marked as a duplicate of this bug. ***