1. Helder Correia
  2. speedcrunch
  3. Issues
Issue #239 wontfix

More intuitive and useful percentage operator

Anonymous created an issue

Originally reported on Google Code with ID 239

What steps will reproduce the problem?
1. Start with any number, say 10 for example.
2. Enter + then amount of  %  try 10 for example.
3. then enter =.

What is the expected output? What do you see instead?

11 is expected. 10.1 is the result.
What version of the product are you using? On what operating system?
0.10.1 version on windows XP service pack 3.

Please provide any additional information below.

Reported by kj1photo on 2009-01-29 20:59:08

Comments (21)

  1. Anonymous

    ``` Hi, that's not a bug. The percentage operator just turns a value into normalized form. So if you enter "10%", the result will be "0.1". So you should calculate your

    expression as "10+10%*10". ```

    Reported by `helder.pereira.correia` on 2009-01-29 23:03:07 - Status changed: `Invalid`

  2. Anonymous

    ``` Issue 263 has been merged into this issue. ```

    Reported by `helder.pereira.correia` on 2009-02-26 22:14:05

  3. Anonymous

    ``` Hi Helder, is there a technical reason to make the % operator behave like this or only a 'philosophical' one? I write this because there are at least 2 good reason to change the behaviour: 1- almost all the users expect this (100+20% =120) 2- it's extremely user-unfriendly. Imagine having to do many operation using the percentage operator (in the businnes world, where you add and subtract VAT, it's very common): you have to write for every single operation x+y%*x instead of x+y% !! Do you think this isn't so bad? Try doing it for 10 times! Or 50! ```

    Reported by `axela74` on 2009-07-05 19:01:57

  4. Anonymous

    ``` Hi axela, sorry for the delay. The % operator was implemented before I took over SC, but I believe it has to do with the nature of the calculator. In a regular pockect calculator, when you push the % button it will calculate automatically using the very last evaluation. In SC's case, a trick must be performed in the expression parslr, but I do agree with you completely, so I'm reopening this issue (not sure about its implementation though). Cheers ```

    Reported by `helder.pereira.correia` on 2009-08-10 10:39:08 - Status changed: `Accepted` - Labels added: Type-Enhancement, Priority-Medium, OpSys-All, Component-Logic, Usability

  5. Anonymous

    ``` I agree with this post. I didn't know it was an active issue. Here is a post I made

    about the issue:

    This is something that would save me a lot of time and I would love speedcrunch even more for it. Here is an example problem:

    35 - 7% = ANSWER

    Right now, speed crunch does this...

    35 - .07 = 34.95

    This is what I would prefer it to do (this is what wolfram alpha does)....

    35 - (35 * .07) = 32.55

    This would help me out a LOT. I use speedcrunch all day long at work, and I do this calculation a lot. ```

    Reported by `whyamionfire` on 2009-08-10 13:03:00

  6. Anonymous

    ``` It would be great to have this done... Otherwise excellent software except this weird

    behaviour. ```

    Reported by `mikajm` on 2009-10-15 14:24:39

  7. Anonymous

    ``` Issue 360 has been merged into this issue. ```

    Reported by `helder.pereira.correia` on 2010-11-09 06:08:26

  8. Anonymous

    ``` the percentage interface is horrible! 316+10% = 316.1 and not 347,6 impossible to use. please please do something ```

    Reported by `lcn.mustard` on 2011-06-27 14:37:01

  9. Anonymous

    ``` Does this help:- 316 = ans+10%*ans= 347.6 ```

    Reported by `shughes.linux` on 2011-10-26 18:53:45

  10. Anonymous

    ``` Does this help:- 316 = ans+10%*ans= 347.6 ```

    Reported by `shughes.linux` on 2011-10-26 18:55:35

  11. Anonymous
    Issue 422 has been merged into this issue.
    

    Reported by helder.pereira.correia on 2012-12-28 21:01:10

  12. Anonymous
    Until this gets addressed there is an obvious workaround. Instead of this nonsense:
    316 =
    ans+10%*ans= 347.6
    
    Do the following:
    316 =
    ans*110%= 347.6
    
    You just have to input the 'target' percentage, rather than the 'modifier' percentage.
    

    Reported by richardtkemp on 2014-11-24 16:21:28

  13. Pol Welter

    I object to changing the current behaviour. If anything, I would prefer to get rid of the percent operator entirely.

    A very nice discussion on this can be found on math.stackexchange. There you can find some convincing arguments for why it really is no good to treat 20 + 10% = 22. What should e.g. 10 + 5 - 10% even mean? This will give us way more trouble than what we currently have. (I highly recommend reading the post; imo the last answer + comments really nail it.)

    I've seen way to many people struggle with simple percentage calculations (mostly because of incompetence in basic mathematics). Learn what is the mathematical operation you want to perform, and enter a non ambiguous expression (for the example above: 20 * 1.10 = 22). No offense, this is my honest opinion :)

    The percent symbol should be reserved for giving the result of a calculation (e.g. "We see a 50% increase in costs", or, "17/65 = 26%"), and not be used as an operator.

  14. Hadrien Theveneau

    Helder Correia I will give my humble opinion, based on both the user and developer side.

    On the developer side, % operator is a real mess to manage.

    On the user side, I never use such operator because I can never predict the behaviour of this operator. I saw too much ways this operator behaves to trust one in particular.

    Additionally, the % operator looks like modulo operator in C, comment operator in LaTeX.

    Pol Welter I agree that % should never be used as an operator to write expressions for computers. However, writing expressions for human reading and for computer parsing are highly different tasks, needing different needs. For example, for my work, I write the same expression in Python to crunch numbers and in LaTeX for the presentation in reports. I will never write % in expressions for a computer, but I might use them in expressions for humans.

    Same conclusion: we should remove this stuff.

    Helder Correia If someone really want to implement % operators for people working in finance, the only reliable solution I see which gives the attended results is to treat 10% not like 0.1 but like a special object in such a way that this special object will add 10% to any number to which it is added... Should I precise that it will be a real mess ?

  15. Felix Krull

    TBH, I didn't know that % did that. My thoughts on it:

    • The current implementation is not terribly useful; literally * 0.01. And it's obviously confusing, with people expecting it to work differently.
    • I agree with Hadrien Theveneau that implementing a % operator as in this bug report would be... very painful, at least.
    • Also agree that properly defining the behaviour for such an operator is difficult. The concept looks useful if you consider "friendly" examples like x+y%, but what would e.g. y%+x mean? It's all too ambiguous for my liking.

    So yeah, I agree on removing the operator as it stands.

    One workaround I came up with would be dedicated +% and -% operators, with x +% y = x + x * (y / 100). Those would be an unambiguous and easy-to-implement way to express the calculations that the OP expected (if not quite as pretty); but I'm doubtful whether an addition like that would be sufficiently obvious, clear and useful to justify.

  16. Pol Welter

    Funny fact: the windows calc.exe disables the % button once you switch to 'Scientific' or 'Programmer' mode. Clearly some people at MS had the same discussion as we do now ^^

    Finally an example that I think is really symptomatic of the problem: 500 * 5%. You'd think 25? Some calculators output 12500. Go figure.

    The fact that I found an entire webpage dedicated to the syntax of various calculators speaks for itself.

  17. Helder Correia repo owner

    Thank you for all the comments, guys. It's great to have all of you around in this project. Although I don't dislike the +% and -% idea mentioned by Felix Krull I think we should just avoid ambiguity and traps altogether. I've created issue #583 for the removal task. If one of you has availability and is kind enough, please assign yourself and upload a PR on this.

  18. Log in to comment