More intuitive and useful percentage operator

[Former user]

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

[Former user]

``` 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`

[Former user]

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

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

[Former user]

``` 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

[Former user]

``` 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

[Former user]

``` 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

[Former user]

``` 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

[Former user]

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

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

[Former user]

``` 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

[Former user]

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

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

[Former user]

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

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

[Former user]

Issue 422 has been merged into this issue.

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

[Former user]

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

[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.

[Helder Correia]

I couldn't agree more with @polwel. I'm up for removing the operator. Would like to ask the opinions of @Teyut @fk @thadrien before asking for someone to kindly provide a PR linked to a task # :)

[Hadrien Theveneau]

@heldercorreia 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.

@polwel 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.

@heldercorreia 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 ?

[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 @thadrien 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.

[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.

[Helder Correia]

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 @fk 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.

[Helder Correia]

Remove ambiguous '%' operator.

Fixes issue #583; see #239 for context.

→ <<cset ddf5ba87b59a>>

[Pol Welter]

Issue #662 was marked as a duplicate of this issue.

[Musor]

Hello world. I don't quite understand why it was so radically delete the very demanding function of any Calculator. Take any table button calculator. As there is handled by this button? In my humble opinion, you have dealt such a discussion because of trifling issues. Because obviously, if there are several ideological interpretations and ways of use of the sign "%", therefore you just need to provide the user choose in preferences-> input format-> "%"-1) processing is disabled 2) converts the number in decimal. 3) executes the "%" the previous number. P.s. sorry for automatic translation, language does not speak.

[Musor]

Strongly recommend to reading: "The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity" by Alan Cooper

[Helder Correia]

Issue #939 was marked as a duplicate of this issue.

[Daniel Jackel]

I’m fine with removing the %, but please do also remove the button from the keypad!
I was a little confused seeing the button but getting an “invalid expression” on using it…