entering a sequence of instructions leads to the wrong results. Reproducible: Always Steps to Reproduce: Platform Version 4.10.5 follow my instructions to the letter and i'll show you... don't press = till i say enter 13 press * press 5 press + press 50 press * press 20 press + press 1012 press - press 1976 the answer should be 1336 press = i bet you get 101 Actual Results: wrong answer Expected Results: correct answer the calculator should function like a calculator you hold in your hands. I believe most users expect this type of functionality and will be surprised after entering a list of numbers and mathematical functions applied to those numbers only to get the wrong answer. I say the software causes you to lose data because if you were using this to work out your check book you would be in a heap of trouble if you took kcalc seriously...
Can confirm this. While the calculator does the right Math, it does it not act like a "real" calculator. Best way would be to make it toggable or atleast act the expected way in simple mode.
It acts exactly like a school calculator. And in school, we learned that multiplication is executed before addition. The fact that the market is flooded also with primitive calcalutors mostly used for promotional purposes (which lack the memory and logic to execute correctly) should not influence our implementation.
Btw, our emulation of such a primitive calculator is the Plasma calculator widget.
(In reply to comment #2) > It acts exactly like a school calculator. And in school, we learned that > multiplication is executed before addition. > > The fact that the market is flooded also with primitive calcalutors mostly > used for promotional purposes (which lack the memory and logic to execute > correctly) should not influence our implementation. The question is not one of primitive vs futuristic or one of school vs industry standard, nor the matter of operations. Calculators are machines designed to make humans lives easier. The way a machine talks to or interacts with a human is at question here. Some humans, like yourself obviously sit in front of a computer or calculator and want it to do formulas for you. You have all the formulas worked out before you start entering in all of the sequences of instructions into the machine. Not all humans are like you or expect a calculator to function the way you do. Calling something primitive and incomplete in this case is a bit immature and not thinking the problem all the way through.
"Education is what remains after one has forgotten what one has learned in school." "Few people are capable of expressing with equanimity opinions which differ from the prejudices of their social environment. Most people are even incapable of forming such opinions." "I Fear the Day That Technology Will Surpass Our Human Interaction" Albert Einstein
(In reply to comment #3) > Btw, our emulation of such a primitive calculator is the Plasma calculator > widget. No, even in the Plasma Calculator the result of "13*5+50*20+1012-1976" is 101
they all probably use the same library
Please do not change the bug status. > No, even in the Plasma Calculator the result of "13*5+50*20+1012-1976" is 101 For the runner, yes, but not for the widget.
the widget is even more confused and returns the result of -964
instead of "Do not follow algebraic operator priorities in Simple Mode" it should be "Assume = pressed when next command is an operator"
most scientific calculators when used as i described will do 13 * 5 + -- becomes ans + 50 * -- becomes ans * 20 + -- becomes ans + 1012 - >> becomes ans - 1976 = which shows the behavior --> assume = pressed when next command is operator
http://en.wikipedia.org/wiki/Calculator_input_methods see immediate execution
@Gabriel, kcalc uses Infix (https://en.wikipedia.org/wiki/Infix_notation) which enforces correct order of operations as taught in school: If I were to write on a piece of paper "1 + 2 x 3 = " and asked someone to solve it, is the right answer 9 or 7 ? According to PEMDAS rules (what is taught in schools) the correct answer is 7. I honestly don't see the benefit in holding calculators to a lesser standard than we would ask of math students. Perhaps most simple calculators use immediate execution, but that's (in my opinion) a result of original calculator makers wanting to save costs in hardware, and not due to it being a desirable feature.
I understand that people care a lot about math, and standards, and classifications of things. I feel that you are calling this a lesser standard when it is not a lesser standard at all but an alternate communication method. In my opinion this is not about these things at all. I have been asking around and it seems that I get different answers from different people in different walks of life. I myself walk both sides of the line in life, the mathematician and the layman. Our job as programmer is to meet the needs of all sorts of people regardless of our personal opinions. The order of operations is a great thing but irrelevant in this conversation. It is apparent that your experiences are a bit one sided and personal opinion along with trivial classifications has clouded your mind and limited your view making you only see one side of this topic. You only seem to see the problem from a mechanical view that you were taught in school and haven't asked around to find out what other people think about communicating with machines. I have worked many different types of job from programming, to construction, to stocking shelves and taking inventory, to repairing electronic devices all the way down to brazing and digging ditches. I have done some research on the matter by asking 40 people their opinion on this matter stating the same thing i did in my original post and also using 2 + 2 * 2 as an example and asking if they expected the result to be 6 or 8 and why. It's split down the middle, 20 people told me 6, and 20 people told me 8. The people that told me 6 were the people that had been educated in using formulas and algebra and the order of operations, the people that told me 8 were people that used a calculator in other ways. I'll offer you as an example this situation which I have lived 3 times this year and had kcalc fail me and embarrass me as a calculator. The people asked me what kind of calculator I was using and told me i needed to get another one... I finally figured out WHY I was not getting the answer they desired as correct, which is why i filed this bug in the first place. Situation: You are standing on the ground and your boss is on the roof and he's hollering down "35, 26, 86, 22, double that, subtract 90... what do you got?" You are holding a calculator, and no pen... you don't have time to write down a formula and worry about order of operations you expect the calculator to know that you wanted to double the running total you had before your boss said "double that". In this situation I would have the correct answer before you with less keystrokes and you'd still be hitting enter or equals after each operation or worrying about entering () where needed to get the right answer. In this situation i came up with the wrong answer because there was no "immediate execution mode" and I expected there to be one on a 4 function calculator. Again I will repeat myself to a programmer who should understand this in the first place. There is no such thing as a lesser standard in this situation, this is not a matter of standard, it's a matter of preference in communication... would you tell a deaf person that they have to read your lips because sign language is a lesser standard? no, you'd use the preferred method of communication (if known) to communicate with that person. If that person preferred to read lips and answer you by talking you'd use that method instead, you wouldn't argue about it. This is no different and while this has proven to be more of a feature request than a bug report, far too much time has been spent discussing it. I'll write the stupid patch myself, if necessary. Far too much time has been wasted on a trivial thing such as this. I could have patched it myself 3 times. In a market where competition takes place, the more options you can give someone usually results in a better more feature rich product that everyone can enjoy and use without frustration. Every method of communication, including infix and postfix and immediate execution and reverse polish notation has it's pros and cons. Offering an opinion on which is better is like asking which is better, coke or pepsi. everyone will disagree.
I appreciate your passion on this issue. First, to answer your question "You are standing on the ground and your boss is on the roof and he's hollering down "35, 26, 86, 22, double that, subtract 90... what do you got?"" I would type into kcalc: 35 + 26 + 86 + 22 = * 2 - 90 = And I would get 248 (honestly, only one extra keystroke compared to what you want). As for the patch, if you write one, it is enabled via a user option (please default to existing behavior), and the code is high quality... it is of course welcome! Unfortunately, I think you'll find that it is far more complicated than you'd expect. Kcalc is quite tied to the Infix based stack at its core at the moment. But as I mentioned, patches are always welcome.
Since this feature requires a new string for the setting, it needs to be in before 30th October to make it for the 4.12 release. Considering time for review, I guess it will have to wait for the 4.13 development cycle, but you can post the initial patch to https://git.reviewboard.org/ anytime.
(And please do not change the bug severity, you might need to reload the page to stop it from happening)
sorry i didn't realize i was changing anything *looks around making sure not to do it again accidently* I am this passionate about everything that I do. Unfortunately it's also why I don't post many bug reports as it takes an incredible amount of my time and patience ;)
I agree. The difficulty here is not what is arguably correct but expected behavior.. if you were typing a calculation into python, order of operations should definitely apply. If this calculator really emulates a real physical desktop calculator, it should not follow order of operations and try to interpret the formula. The default should be to not respect order of operations, as it will give incorrect results. For example: 10 - 2 / 4 = 2 Kcalc 10 - 2 / 4 = 9.5 In terms of order of operations, the latter is arguably correct, but in terms of expected behavior, the former is definitely correct. The reason why is that at each stage (on a real-life calculator) the proper value is shown on screen. In other words, 10 - 2 followed by any non-numeric key would immediately calculate and show a result as a running total, not wait to display a total at the end. On the other hand, this behavior (once you know about it!) could be very helpful. Let's say that I'm doing an expense report stapler - $5 pens (3) - $1 kcalc: 5 + 1 * 3 = 8 regular calculator: (5 + 1) * 3 = 18 However, on a regular calculator, you'd obviously see the result of the 5+1=6 on screen and not try to multiple that times 3. You'd hope. Although I've done it without noticing. ;) So I agree -- making it act like a normal calculator by default would be consistent, and adding a switch for correct (current default) behavior would be really nice for adding long sums of numbers (but also arguably a taller screen/virtual printing calculator would be a good addition as well).
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
Showing the calculated input eliminates all ambiguity so, this can be closed per https://invent.kde.org/utilities/kcalc/-/merge_requests/67