Evaluate 10% + 20% as 30% or 0.3 instead of 0.12

[hamodey]

Hi,

I am fairly new to using mathjs and I have been using it for my excel-like datasheets on my online application.

However, recently I have seen an issue with evaluating decimal numbers, even the simplest expression does not output the correct answer, or what I believe should be correct.

Describe the bug

const expression = '10.00% + 20.00%'
const evaluation = math.evaluate(expression);

I am getting a weird output as follows:

I believe the correct output should be 30 (%)

Could I get some clarification pls?

Thanks :)

[josdejong]

The expression parser evaluates this expression as follows:

math.evaluate('50%') 
// = 50 * 0.01
// = 0.5

math.evaluate('50% + 20%') 
// = (50 * 0.01) + 20%
// = 0.5 + 20%
// = 0.5 * 1.2
// = 0.6

If you want to get the result of 30%, you can provide parenthesis, like:

math.evaluate('(10 + 20)%') 
// 0.3

The percentage operator is listed here in the docs: https://mathjs.org/docs/expressions/syntax.html

Does that help?

[gwhitney]

I think the original post does raise a legitimate issue that 10% + 20% is at least ambiguous between adding the percentages and increasing the left operand by 20%. In fact I would say that the most common "everyday" interpretation of this expression would be to add the percentages and get 30%. So it seems as though perhaps it ought to be flagged as ambiguous or perhaps even be interpreted as the percentage addition. It's a real oddity that there isn't any parenthesization that disambiguates between these two interpretations-- note you had to remove one percent operator to get the desired 30% interpretation, with the current parser. I don't have a specific proposal offhand, but perhaps this should be moved to design discussions for further thought?

[josdejong]

Yes you're right, it would be much more intuitive to evaluate 10% + 20% as 30%.

OK I'll move this into a discussion/idea. We'll have to think though how we can support this and in what cases exactly.

[josdejong]

So, some cases we need to think through:

10% + 20%
10% - 20%

x + 10% + 20%
x - 10% - 20%
10% + 20% + x
10% - 20% - x

10% + 20% + 30%
10% + 20% - 30%

Are there more?

[gwhitney]

Well, we need to preserve things like 50 + 20% and 10cm + 20%
And what about:
x + 20%
20% + 5
10% + 5 + 20%

And is it associative? I.e. are
10% + 20% + 30%, (10% + 20%) + 30%, and 10% + (20% + 30%) all the same or not? What about 50 + 20% + 10% vs. 50 + (20% + 10%) ? If you add percentages first in the latter you get 50 + 30% = 65 whereas if you operate left to right in the former you get 60 + 10% = 66

And suppose you do want to increase a percentage by a percentage, i.e get 10% more than a 50% increase, i.e. a 55% increase, what do you write? (I mean, supposing that we change 50% + 10% to 60%, how do you get back the old behavior if you want it?)

[josdejong]

Good points @gwhitney , thanks. We'll need to think all of those cases through.

[renyuneyun]

Well, I have counter examples of why the current behaviour should not be preserved as the default. In particular, when you need to calculate complex expressions at the second addend, the current behaviours do not make sense that much:

• 10% + (20 + 30)% = 10% * (1 + 0.5) = 0.15 ??
• 10% + (20% + 30%) = 10% + 0.2 * (1 + 0.3) = 0.36 ??
• And, as we know, 20% + (10% + 30%) = 0.33 != 10% + (20% + 30%)

I'm using 20% and 30% for easier demonstration in actual results. But they can be arbitrary like 12.3% * 4 + 56.78%, which you won't expect to be immediately known. It's doubtable that people would intuitively want to "increase" the first adder by such a complex expression result, rather than really wanting to "add" the two numbers together.

Basically, it's not distributive, commutative and associative in the current behaviour already. It doesn't make sense to require a change to satisfy them anyway.

[josdejong]

@renyuneyun the current behavior is not ideal in all cases (hence this discussion). Do you have a concreate proposal on how to improve it?

[gwhitney]

I haven't looked at parse trees yet so am not really ready to put forward any concrete possibilities. But conceivably 50% + 20% and (50%) + 20% could mean different things. Or is that too undesirable?

[josdejong]

Intuitively I would say (50%) + 20% is the same as 50% + 20%. But it may work out that way. Currently the % operator has a higher precedence then +, resulting in the current behavior. How we want to make changes in the precedence of these two operators in specific cases, so it may turn out that you have to use parenthesis like in (50%) + 20% to override default behavior if that doesn't match what you want to do.

[renyuneyun]

I randomly entered into this topic today, as I found the unintuitive and interesting behaviour, and inconsistency in behaviour and description. In particular:

Currently the % operator has a higher precedence then +

• If % has higher precedence, you should evaluate all % first, and then all +, meaning 50% + 20% = 0.5 + 0.2 = 0.7.
• However, in reality, the current behaviour is 50% + 20% = 0.6 (= 0.5 * (1+0.2)).

I see from the discussion above about the rationale (which would be commented on separately), but it is different from what is describe here. So which one is more correct?

[josdejong]

To me, 50% + 20% = 0.5 + 0.2 = 0.7 makes most sense, so I think we should change the behavior to make that work. I'm not sure where the current behavior originates from, so we have to do some debugging there. Help would be welcome.

[josdejong]

Ok the related code is here:

mathjs/src/expression/parse.js

Lines 1016 to 1020 in 0fc6d49

	if (rightNode.isPercentage) {
	params = [node, new OperatorNode('*', 'multiply', [node, rightNode])]
	} else {
	params = [node, rightNode]
	}

This code handles cases like 100+3% and 50+50+3%. If we remove this special case, 10%+20% and 10%+50%-20% work as expected. So, we have to figure out a more precise logic to detect these different cases.