xcalc has order-of-operations problems

Bug #275645 reported by Toby Bartels
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
x11-apps (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: x11-apps

Under Ubuntu 8.04.1, running the version in x11-apps_7.3+1_i386.deb, the calculator program xcalc has problems with the order of operations.

To recreate this bug, run "xcalc" from the command line, then type "2*2^2+2=". The result displayed should be "10", but instead it is "12". Note that "2+2*2^2=", "2^2*2+2=", "(2*2^2)+2=", and "2*(2^2)+2=" each give the correct result.

My guess is that the program has problems when it must close two levels of implicit grouping at once. In effect, it treats the problematic input above as if it were "2*(2^2+2)=". This interpretation is consistent with other examples that I've tried.

Tags: xcalc
Revision history for this message
Rich Wareham (richwareham) wrote :

Same result here. The question is whether this is a bug or by design. The program aims to emulate a TI-30 or an HP-10C so I suppose the ultimate reference is typing the same into one of those calculators.

For reference, the 'gnome-calculator' program in scientific mode produces '10' unlike xcalc which does indeed produce '12'.

Changed in x11-apps:
status: New → Confirmed
Revision history for this message
Jarno Suni (jarnos) wrote :

If it were by design, what would be the calculation order rule?
It calculates 2*2^2+2 so that + has higher precedence than *.
On the other hand, it calculates 2*2²+2, 2+2*2^2 and 2*2+2 so that * has higher precedence than +.
This is a bug.

Revision history for this message
Toby Bartels (tobybartels) wrote :

@jarnos

My hypothesis in the original post is that, when the calculator should close two levels of implicit grouping, it closes only one. Regardless of whether that is correct, there is a program, and it must follow some algorithm, so there must be a rule, whether or not we know it. If the rule was programmed deliberately, then it was by design.

Of course, whether by design or not, it is a flaw. @richwareham is just wondering whether or not this is a flaw in the TI-30 or HP-10C calculators that xcalc deliberately copies. In other words, was the bug introduced in those historical calculators, or was it introduced in xcalc? (And in the fomer case, then what should we do about it?)

This report is 7 years old, and I had forgotten ever making it, but the bug is still there in my current system! (Although to be fair, I'm still running Ubuntu 12.04.)

Revision history for this message
Jarno Suni (jarnos) wrote :

I suppose the flaw does not exist in TI-30. Why would they want to mimic an old scientific calculator, that can't do basic arithmetic right? Besides, the manual page of xcalc tells (as for the TI-30 mode): 'It should be noted that the operators obey the standard rules of precedence. Thus, entering "3+4*5=" results in "23", not "35".' (HP-10C mode on the other hand does has completely different approach in the order of operations, and xcalc emulates it only, if it is started with -rpn option. )

The bug exists in Ubuntu 14.04, too.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.