GNOME Bugzilla – Bug 786510
gnome-calculator comes up with totally wrong answer
Last modified: 2018-05-22 12:00:15 UTC
Created attachment 357974 [details] Bug description image To reproduce the bug (have tried on multiple computers) do something along these lines in the gnome-calculator app: - Press 7 and Enter. Screen should show 7 = 7, input field should show 7. - Press left arrow and type 12, then the right arrow and type +7. Input field should show 127+7. - Press Enter. Screen will show 127+7 = 91, input field will show 91. No scientific modes or anything; this is in normal mode. Copy from: https://bugs.launchpad.net/ubuntu/+source/gnome-calculator/+bug/1680438
confirmed gnome-calculator 3.25.90-1
The cause for this lies in the automatic multiplication: the last result (always shown in bold) is a variable: * pressing 7 and enter stores 7 as the last result variable * when you press left arrow and type 12 (the input showing 127, where the 7 is bold) you have an implicit multiplication between the 12 an the 7, the last result variable * adding 7 to 12*7 equals to 91. I am not sure how to fix this, just wanted to let you know the explanation behind it. Fixing this could mean treating the last answer variable as simple text input when editing the inputbox. In that case 127+7 shown in the input box would translate to 127+7, and not to 12*7+7.
While it is possible for us to treat the previous answer (bold text) as normal text input, note that this will cause loss of precision for almost every user. e.g. * 1/3= will give output as 0.333333333. * *3= will give output 0.999999999. This is the reason why we internally replace the bold text with previous answer, with much higher precision. With current code, this will always yield 1 as output. This is not the only consequence. When the "Number Format" is set to scientific (for example), this will result in unexpected behavior for other users. e.g. * 90= will give output as "9×10¹". * After prepending "sin" to the output, input box will look like "sin 9×10¹". (assuming angle unit is degree) * The expected answer when we use "9×10¹" as a single entity is 1. However, if we treat output as text, "sin 9×10¹" will be evaluated as "sin(9)×10¹" (i.e. 1.5643). At best, we can allow user to switch between these two behaviors. Not sure if this will still adhere to the GNOME HIG.
(In reply to PioneerAxon from comment #3) > At best, we can allow user to switch between these two behaviors. Not sure > if this will still adhere to the GNOME HIG. This is an option to consider, and given that the number of reports complaining about this behavior is increasing (surely had several of these), it might be something needed. Regarding GNOME HIG, I am not sure the HIG stops us from doing something like this. Yes, options are indeed to be avoided usually, but in this case users experience bad behaviour, so if a user preference with a sensible default can make users' life easier, then maybe it is the way to go. User experience is not only about the interface and the complexity of the user interface, and GNOME HIG is only meant to provide guidelines for the best UX, rules which in some cases have to be broken (but still, I don't see anything we would break here by adding something like this)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-calculator/issues/59.