Bug 57349 - Wrong behaviour on repeated pressing operator buttons
Summary: Wrong behaviour on repeated pressing operator buttons
Alias: None
Product: kcalc
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Evan Teran
: 244171 276331 (view as bug list)
Depends on:
Reported: 2003-04-17 02:41 UTC by Andrey Cherepanov
Modified: 2018-10-05 21:10 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:

modified files (20.94 KB, application/x-tgz)
2006-02-28 00:11 UTC, Alessandro Russo

Note You need to log in before you can comment on or make changes to this bug.
Description Andrey Cherepanov 2003-04-17 02:41:30 UTC
Version:           1.3.2 (using KDE 3.1.0)
Installed from:    compiled sources
Compiler:          gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)
OS:          Linux (i686) release 2.4.7-10

When I use normal calc (ex. xcalc), I can press operator buttons (+,-,*,/, etc.) as I wish - result will be right. This behaviour is useful for correct electing wrong operator - need to use addition instead multiplication.
For example, there is 4 * * * 4 = 16 in xcalc
In kcalc this combination returns 262144.
Another example:  4 * + - 2 = (wrong typing  * and +. Need to 4-2=): xcalc returns 2, kcalc - 30.
I know, = sign uses in calc as repeater last operation. 
2 * = (or 2*2=) returns 4
press = another once returns 8
each pressing = multiplicates result number by 2.

Please, correct this behaviour or create new mode - Simple, supporting this rule of calculation.
Comment 1 Mathieu Jobin 2005-09-18 22:50:45 UTC
I was saying its a bug not a wish, because on a standard calculator this is the expected behaviour. Pressing two operators in a row will cancel the first operator and replace it by the second one.


2 + * 3 ==== 2 * 3

Comment 2 Alessandro Russo 2006-02-21 00:19:43 UTC
Also if you press 100 - 10 / 5 = you obtain 98 and not 18

100 - (10 /5) = 98

(100 - 10)/5 = 18

It think that the right method, for a simple calc, is the second but kcalc use the first.
If you want to use the first method you have to display the full expression like a Texas Instruments calculator, in a simple calc where you display only 1 number you HAVE to use the second method.

press 1 and 0 and 0  -> display: 100     actual display: 100
press -              -> display: 100     actual display: 100.0000000
press 1 and 0        -> display:  10     actual display:  10
press /              -> display:  90     actual display:  10.0000000
press 5              -> display:   5     actual display:   5
press =              -> display:  18     actual display:  98
Comment 3 Mathieu Jobin 2006-02-21 02:05:36 UTC
as far as I can remember * and / operators have priority over + and - operators.

so, in your expression to get 98, the parenthesis are optional. and in your second expression to get 18. the parathesis are required. kcalc is correct.

Comment 4 Mathieu Jobin 2006-02-21 02:08:13 UTC
original bug stated in original report still needs to be fix IMHO.
Comment 5 Alessandro Russo 2006-02-21 14:10:28 UTC
This isn't algebra! It's a simple calculator!
In all the simple calculator that the people use when you press an operator it's like you first press = and then rewrite the result.
10 + 10 / 2 ---> 10 + 10 = 20; 20 /2 = 10

kcalc doesn't show the algebraic expression when you write it, kcalc display only numbers so it's extremely confusing to use the algebraic priority.
If I digit:
then: +
then: 10
then: *
when I press * I expect to see 20 on the display not 10.0000
This is the behaviour of all the calculator that don't display the full expression: you make only 1 operation per time and take the result as the first number of the next operation.

Btw the Windows Calc do exactly what I say. 
Comment 6 Thiago Macieira 2006-02-23 10:35:01 UTC
2 + 2 * 2 = 6

KCalc does it right. I hate calculators that don't know about operator precedence.
Comment 7 Alessandro Russo 2006-02-23 14:23:36 UTC
Please, try to understand me.
KCalc knows about operator precedence but the user DOESN'T expect this behaviour!
The user isn't inserting an expression, he's only doing some operation in sequence. And he's expecting that KCalc respects this sequence.
KCalc is mixing 2 different kind of calculator.
Type 1: Algebraic calculator like Texas Instruments or Sharp. They have a large display and if you press 2+4*3 they display "2+4*3" on the display. Only when you press '=' the result '14' is displayied.
Type 2: Simple calculator. They have a small display (10-12 characters) and they do only 1 operation per time. If you press 2+4*3 they show you 6 when you press '*' and 18 when you press '='

Kcalc is using the small display of the Type 2 and the algebraic expression of Type 1. This is WRONG.

The most beautiful solution would be to have 2 different 'mode': simple and advanced, to mimic the 2 different type of calculator. But in the meantime Kcalc should mimic the type 2 because is the most common one, and the 99% of the users expect this behaviour.

Comment 8 Thiago Macieira 2006-02-26 02:18:12 UTC
It's not wrong when the operator precedence is right. It is just not what $1 calculators do.

You don't have to have an algebraic calculator to do proper operations. All you need is something a bit more sophisticated, like one that does parentheses evaluation.

I don't know if that's what users expect. I expect my calculator to know Math rules. Then again, I'm more used to RPN notation than algebraic.

Please post the patch to change this behaviour if you feel so strongly about it.
Comment 9 Alessandro Russo 2006-02-28 00:07:22 UTC
Ok, here it is.
Can somebody test it?
Btw you have to install the file kcalcui.rc in the /usr/kde/3.5/share/apps/kcalc/ dir (or in a similar place).
Comment 10 Alessandro Russo 2006-02-28 00:11:56 UTC
Created attachment 14904 [details]
modified files
Comment 11 Evan Teran 2006-02-28 04:38:17 UTC
I have to say that I am very much against this patch and feel it should not be applied. having a calculator that doesn't know the rules of math is generally a _bad_ idea. Changing core behavior of an application which has been part of KDE for so long is even worse!

The only appropriate solution besides just saying "won't do it" would be to make a new calculator "KSimpleCalc" or something which woudl act as you describe.

Firstly, I dont think that calculators what ignore proper order of operations are common place, I think you'd have to go out of your way to even find one. Goto stables, by any basic 4 function calculator (the so called simple calculator) and low and behold, it'll respect the rules of operator precidense.

Also the argument that the user doesn't expect this is unsubstatiated, windows calc, gnome-calc-tool, kcalc, xcalc (just to name a few) are all calculators which work similarly to kcalc in this regard.

Evan Teran
Comment 12 Alessandro Russo 2006-02-28 18:00:56 UTC
windows calc (xp version) work exactly like my patch. In the windows calc you have 2 different mode: Standard and Scientific. In the standard mode 80+20/5=20
while in Scientific mode 80+20/5=84.
I think that this is much more userfriendly. We can't expect (at least not in the 2006, maybe before 2000 when linux usage was restricted to scientific and technical university) that many people using kcalc think about the priority of the operation when they do some simple calculations.

Btw in the patch I added an 'Advanced mode' (we can change it to: Scientific mode) where kcalc respect the priority of the operations. When not using this 'Advanced mode' kcalc execute every operation as soon as an other operation is inserted (80+20/ -> 100/). Try to ask to your friends/parents/girlfriend to sum 80 and 20 and then to divide per 5 using kcalc. Do you expect to see them write (80+20)/5? :-)  I read a bug report for gcalctool and from that discussion they added operator priority but only for the scientific mode and only by showing the entire formula and no partial results (you write 80+20/5 on the screen you see 80+20/5, when you press = you see 24).

I fixed also the bug "Wrong behaviour on repeated pressing operator buttons" so if you press several operation keys without pressing some numbers only the last operation is considered (80+/- -> 80-).
Comment 13 Stefan Borggraefe 2006-06-25 14:51:30 UTC
Would a good patch that only fixes the issue described in comment 0 be incorporated into kcalc?

Would it only be considered if this is configurable so the current behaviour is still optionally available?
Comment 14 Christoph Feck 2010-08-28 15:56:04 UTC
*** Bug 244171 has been marked as a duplicate of this bug. ***
Comment 15 Unknown 2010-08-29 10:14:44 UTC
Please, fix this bug. It's at least 7 years old...

I have to use Google (http://www.google.com/help/features.html#calculator ) every time I want to use KCalc because if I accidentally press an operator button twice, that would mess up the whole calculation I made before.
Comment 16 Evan Teran 2011-06-23 18:37:28 UTC
*** Bug 276331 has been marked as a duplicate of this bug. ***
Comment 17 Victor Varvaryuk 2011-06-23 19:23:26 UTC
Is this going to be fixed, or you still consider this not a bug?
Simple real (not computer) calculators do it like this.

For me it's a bug. Today i wanted to calculate sum of numbers from several web-pages. So i opened first page and entered in calculator first number and pressed '+'. Then i opened another page and entered next number in calculator and pressed '+'. Then i opened another page and found smth interesting on it and got distracted. Then i wanted to add number from this page and went to calculator, but couldn't recall if i already pressed '+', so i pressed again '+', as people usually do on simple real calculators. Guess what happened?
Usually to repeat last operation '=' is pressed.

I think a compromise would be to leave current behavior in scientific mode.
Comment 18 Evan Teran 2012-04-10 19:55:59 UTC
OK, it's been a while since I've looked at this bug. I certainly still feel that a calculator, even a simple one should respect operator precedence rules.

However, I do agree that pressing operator buttons multiple times should behave better. I think the "usual" is to have the most recent operation replace the previous operation. And that "=" would just repeat the last operation.

So: "5 + * 10" would equal "50".

I will look into how to implement this properly.
Comment 19 jeremy9856 2015-05-28 22:30:51 UTC
This bug is very old it really have to be fixed
Comment 20 Victor Varvaryuk 2015-05-29 07:28:13 UTC
Evan Teran 2012-04-10 19:55:59 UTC
> I certainly still feel that a calculator, even a simple one should respect operator precedence rules.

This is not how successful software it done. You have to consider existing standards and user expectations.
Comment 21 jeremy9856 2015-07-05 10:39:35 UTC
12 years later I think that really shoulb be fixed. It makes kcalc hard to use an prone to errors.
Comment 22 noric 2015-10-07 15:24:38 UTC
Please fix this, it's really a pain to use Kcalc this way.
Comment 23 Albert Astals Cid 2018-10-05 21:10:11 UTC
Git commit b0ce4ff01b5e1f7f4c2340b90f326491437c076c by Albert Astals Cid, on behalf of Maximilian Schiller.
Committed on 05/10/2018 at 21:09.
Pushed by aacid into branch 'master'.

Corrected behaviour on repeated pressing of operator buttons

Fixes "wrong" behavior to the correct one as described in the bug report.
Before the fix pressing "10 * / 5 =" normally would result in 20 (Stack: (10,*), (10,/), (5,=)) but with those changes it results in 2 (Stack: (10, /), (5, =)).

Internally this is achieved by "blocking" node adding after a operator (*,-,/,...) has been pressed until a number is entered. If another operator is pressed whilst blocked the top (last) operator is changed instead.

Reviewers: cfeck, teran, #kde_applications

Reviewed By: cfeck

Subscribers: aacid, cfeck, kde-utils-devel

Differential Revision: https://phabricator.kde.org/D15463

M  +3    -1    kcalc.cpp
M  +17   -3    kcalc_core.cpp
M  +3    -0    kcalc_core.h