GNOME Bugzilla – Bug 135140
gcalctool-ng - percent operator works not as expected
Last modified: 2006-09-13 18:00:48 UTC
Moving a bug upstream... On https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=116513 Doug Maurer wrote: "GcalcTool 4.3.3 not computing percents I have tried this on both a i686 laptop and athlon desktop. When computing a percentage of a number; all it does is multiply the number. when doing 100 * 10% it should give a number of .1, but instead it multiplies the number 100*10 % and gives the answer of 1000. Steps to Reproduce: 1. bring up calculator 2. press any number (ie.100) 3. hit the times sign (*) 4. press another number (ie. 10) 5. then press the percent sign (%) Actual Results: when pressing the % sign it acts like your pressing the equals button Expected Results: to give a percentage of the number"
Created attachment 24660 [details] [review] gnome-utils-2.4.0-percent.patch
I reproduced the problem with gnome-utils-2.4.0-1 on Fedora Core 1. After reading the source code, I realized that the percent operator does work, but not as I expected. 200%30= produces 60. I agree with Doug Maurer that 200*30%= should produce 60.
Bart, I see the attachment, but it just shows in my browser. And i don't see any instructions for applying the patch. I tested the way you did it.. and it works ok..
Applied the RPM that Bart supplied to me. And it tested ok. Although I did have to press the equal sign "=" after pressing the "%" sign, which on a normal calculator hitting the % would perform the calculation without having to press the = button. Doug
% is a two operand operator. One before the %. One after. So you needed to enter: 200%30= to get 30 percent of 200. It's been doing it this way since 1987 (in it's previous incarnations - calctool in the OpenWindows DeskSet and dtcalc in CDE). Both these calculators have been reviewed by numerous HCI experts. The calculator is based on a Casio hand-held calculator from that time. That's the way it did it. This behaviour is also documented in the online help. It is noted that not all calculators do the same thing. I've picked one way of doing this. I've no plans to change it.
Wow, it seems I'm so unfamiliar with Casio that I didn't realize that this is not a bug, even after discovering how it works. OK, I (and Doug too) should have checked the help files. It is well documented. The Casio way was probably the best choice 17 years ago. Would this still be the choice today? Maybe this is just a local problem (I live in Belgium). Is Casio still popular elsewhere? I think gnome is missing a calculator that works the way other calculators work. Maybe it's time to include a new calculator in gnome? Or to implement a user preference in gcalctool? There are probably much more differences between Casio and other calculators than just the percent operator. This needs a thorough study, not a quick "fix" of the percent operator. Should I register a separate "request for enhancement" bug? Or do we re-scope *this* bug report? Or should I simply use a separate, existing, calculator?
hmm.. ok.. guess i was used to the TI (texas instruments) of doing things.. but it works.. so not sure of the procedures for closing this bug report from me. thanks Bart. :)
No real need for a separate request for enhancement. Bug #121710 I think covers this. There is even a prototype version for you to try out (see bug report). We hope to integrate this new version into GNOME 2.7/8. Your feedback on that bug report would be most useful. Adding Sami to the Cc: of this bug so he's aware of it. Thanks.
If current percent operator behaviour is not intuitive, please create a new bug report (a feature/behaviour change request). Address the report to gcalctool's experimental version. http://users.utu.fi/~sampie/gcalctool/gcalctool-5.3.42.tar.gz does not have implementation for % operator in arithmetic precedence mode. Other feedback is also welcome. Thanks
Yes, bug #121710 covers discussions on what people expect from a calculator, including arithmetic precedence. It doesn't explicitly cover the percent operator behaviour, but I see that the code for the percent operator in http://users.utu.fi/~sampie/gcalctool/gcalctool-5.3.42.tar.gz looks very similar to my patch, so I guess *this* bug is covered. However, I haven't tested it yet, because a quick ./configure and make on Fedora Core 1 didn't build that gcalctool version. I got "The OrigTree module doesn't seem to be properly installed ./intltool-merge". Any hints?
At first the experimental version did implement % operator as unary operator. For example entering 95% did give result 0.95. This was because I assumed wrongly how percent operator works in gcalctool. By default in the experimental version the old behaviour is not altered (non arithmetic precedence mode). Additionally gcalctool must de designed to be as coherent as possible. That's why arithmetic precedence currently (in CVS) implements percent as binary operator. For example: "a % b". However, if current behaviour of % operator is not intuitive for users, then behaviour of percent operator must be rethought. That's why feature request is important. Perhaps Rich can answer to the question about build problem. I am not yet very familiar with the build system. However, problem might be caused by intltool version related issues. Have you tried to run autogen.sh?
I suspect the built errors you are seeing are because the experimental prototype for gcalctool needs the latest version of gnome-common installed. I'm hesitant to suggest you just going ahead and do that in case it breaks other things you've already got installed. Sami, any possibility you can generate a compiled Linux version for Bart? I develop under Solaris, so I'm unable to do this.
http://users.utu.fi/~sampie/gcalctool/gcalctool-5.3.42-compiled.tar.gz This is development tree in my machine. Don't try to install, just run gcalctool binary. It seems I am now also getting "The OrigTree module doesn't seem to be properly installed ./intltool-merge". However, binary seems to compile successfully.
> just run gcalctool binary ./gcalctool: error while loading shared libraries: libgnutls.so.7: cannot open shared object file: No such file or directory > I assumed wrongly Then bug bug #121710 does *not* cover the percent discussion we're having here. Reopen *this* bug?
I'd suggest you open a new bug, make sure that it's clearly indicated that this is against the experimental (gcalctool-ng) version, and assign it to Sami. Also make sure that there are no keywords like GNOMEVER2.5. Thanks.
I'm going to re-open this bug. We are working towards integrating gcalctool-ng into CVS HEAD for inclusion in a future GNOME 2.X release. Let's revisit the percent operator at the same time (asking for input from a wider audience - probably the folks on desktop-devel).
*** Bug 161368 has been marked as a duplicate of this bug. ***
*** Bug 165687 has been marked as a duplicate of this bug. ***
Created attachment 72648 [details] [review] The fix. The fix for arithmetic precedence mode and for non-arithmetic precedence mode. Strance thing. The non-arithmetic precedence mode does not behave like I expected. The cause is not this patch, altough the same problem can be duplicated with % operations. An example: 100 * 90 SIN = Gives 1. Rich, is there a reason for this behavior or is this a bug?
The way that you implemented arithmetic operator precedence mode is different then the way I'd previously implemented non-operator arithmetic operator precedence mode. For a lot of operators. This needs to be fully documented. See comment #8 in bug #309210. Your percent patch looks good. Please check it in. Please also add another new comment to bug #309210, so that if/when the gcalctool documentation ever gets updated, the new correct way that percent now works, can be given. Thanks.
Checked in to CVS HEAD.