"1/4x" and "1/(4)x" evaluate differently

[ChristopherChudzicki]

This difference in parsing surprised me and seems like a bug:

const x1 = math.evaluate('1/4x', {x: 2})
const x2 = math.evaluate('1/(4)x', {x: 2})
console.log(`x1: ${x1}`) // 0.5
console.log(`x2: ${x2}`) // 0.125

Describe the bug
I would not expect parentheses to affect the grouping of items outside the parens. But "1/4x" vs "1/(4)x" changes whether "x" is in the denominator.

[josdejong]

Thanks for your input!

The behavior of implicit multiplication was changed a year a go or so, it will be good to read up on the following discussions:

• '-9/4 x' vs '9/4 x' #2370
• Negated fraction multiplied implicitly not stringified correctly #1431

Coming up with a simple, coherent rule to deal with division in combination with implicit multiplication is hard. For example, if you evaluate 1 / (4) x as (1/(4))*x, you would probably expect 1/ (x) y to evaluate as (1/(x))*y too? (it would be weird if the result changes after moving a constant value into a variable...). That would mean though that 1 / (x) y would evaluate differently then 1 / x y, which is currently evaluated as 1 / (x * y). Which is also inconsistent. Etc.

I'm always open to see if we can improve it further. But if you want to rethink the behavior, we have to work out the full list with all cases to see how it would fit in the bigger whole, and weigh the pros/cons again.

[ChristopherChudzicki]

@josdejong Thanks for the context and issues. I've seen 'Rule 2' discussed in issues now and then, I guess this is it 😄

These comments were particularly helpful and still seem accurate, though they're a bit old:

• Implicit multiplication and unit division #792 (comment) on Rule 2
• Implicit multiplication and unit division #792 (comment) on rationale for treating implicit multiplication differently

My opinion, which is just of course only that, is that the parser would be better off without this. Less mathematically inclined users might be surprised by the result of 1/2 x, but I suspect they and others would be more surprised that it's different from 1/(1+1) x. And I don't think the solution is to try and add even more special cases. Instead, remove the special cases.

The fact that "whether an operand is a numeric literal or a symbol can affect operator precedence" means that changing a constant to a symbol does change results:

with b=4, a=2
-----------------------------------------------
1/2 b               2           (1 / 2) b
1/(1+1) b           0.125       1 / ((1 + 1) b)
1/(2) b             0.125       1 / (2 b)
1/a b               0.125       1 / (a b)

I'm mostly agnostic on whether implicit multiplication should be higher or lower precendence than division, but I strongly believe the examples above should all evaluate the same (whether to 2 or 0.125, but it should be consistent). Guiding principles for me would include:

• Moving a constant to a symbol should not affect parsing
• Wrapping isolated symbols/constants in parenthesis should not affect the evaluation

I suspect that only division with implicit multiplication breaks these rules.

Why use implicit multiplication?: I run a site which uses LaTeX input for mathematical expressions, which are then transformed to something MathJS can parse. Since users might use implicit multiplication, I don't have control over that.

The actual issue came up when upgrading MathJS from pre-Rule 2 to post-Rule 2 versions. Previously \\frac{a}{b} c was converted to (a)/(b) c which worked fine. Probably now I will just convert it to divide(a, b) c which seems better anyway.

[josdejong]

Thanks for the clear write-up. I agree with your guiding principles. There is an important third one though:

• Moving a constant to a symbol should not affect parsing
• Wrapping isolated symbols/constants in parenthesis should not affect the evaluation
• Evaluate like the user expects

And that third one is a tough one, coming into play with implicit multiplication mostly. Before this special rule we had a behavior satisfying the first two principles, but people where confused why for example 1/2 hour evaluates "wrong" (expecting it to evaluate as (1/2)*hour).

The current situation is a compromise, and is not adhering to the guide lines in some cases. Do you have a proposal for a better compromise?

It maybe best to work out the desired outcome of the existing unit tests:

mathjs/test/unit-tests/expression/parse.test.js

Lines 1332 to 1364 in 23cf6e8

	it('should follow precedence rules for implicit multiplication and division', function () {
	assert.strictEqual(parseAndStringifyWithParens('2 / 3 x'), '(2 / 3) x')
	assert.strictEqual(parseAndStringifyWithParens('-2/3x'), '((-2) / 3) x')
	assert.strictEqual(parseAndStringifyWithParens('+2/3x'), '((+2) / 3) x')
	assert.strictEqual(parseAndStringifyWithParens('2!/3x'), '(2!) / (3 x)')
	assert.strictEqual(parseAndStringifyWithParens('(2)/3x'), '2 / (3 x)')
	assert.strictEqual(parseAndStringifyWithParens('2/3!x'), '2 / ((3!) x)')
	assert.strictEqual(parseAndStringifyWithParens('2/(3)x'), '2 / (3 x)')
	assert.strictEqual(parseAndStringifyWithParens('(2+4)/3x'), '(2 + 4) / (3 x)')
	assert.strictEqual(parseAndStringifyWithParens('2/(3+4)x'), '2 / ((3 + 4) x)')
	assert.strictEqual(parseAndStringifyWithParens('2.5 / 5 kg'), '(2.5 / 5) kg')
	assert.strictEqual(parseAndStringifyWithParens('2.5 / 5 x y'), '((2.5 / 5) x) y')
	assert.strictEqual(parseAndStringifyWithParens('2 x / 5 y'), '(2 x) / (5 y)')
	assert.strictEqual(parseAndStringifyWithParens('17 h / 1 h'), '(17 h) / (1 h)')
	assert.strictEqual(parseAndStringifyWithParens('1 / 2 x'), '(1 / 2) x')
	assert.strictEqual(parseAndStringifyWithParens('+1/2x'), '((+1) / 2) x')
	assert.strictEqual(parseAndStringifyWithParens('~1/2x'), '((~1) / 2) x')
	assert.strictEqual(parseAndStringifyWithParens('1 / -2 x'), '1 / ((-2) x)')
	assert.strictEqual(parseAndStringifyWithParens('-1 / -2 x'), '(-1) / ((-2) x)')
	assert.strictEqual(parseAndStringifyWithParens('1 / 2 * x'), '(1 / 2) * x')
	assert.strictEqual(parseAndStringifyWithParens('1 / 2 x y'), '((1 / 2) x) y')
	assert.strictEqual(parseAndStringifyWithParens('1 / 2 (x y)'), '(1 / 2) (x y)')
	assert.strictEqual(parseAndStringifyWithParens('1 / 2x * y'), '((1 / 2) x) * y')
	assert.strictEqual(parseAndStringifyWithParens('y / 2 x'), 'y / (2 x)')
	assert.strictEqual(parseAndStringifyWithParens('y / 2 * x'), '(y / 2) * x')
	assert.strictEqual(parseAndStringifyWithParens('y / 2 x w'), 'y / ((2 x) w)')
	assert.strictEqual(parseAndStringifyWithParens('y / v x w'), 'y / ((v x) w)')
	assert.strictEqual(parseAndStringifyWithParens('1 h / (1+1) h'), '(1 h) / ((1 + 1) h)')
	assert.strictEqual(parseAndStringifyWithParens('4 lb + 1/2 lb'), '(4 lb) + ((1 / 2) lb)')
	assert.strictEqual(parseAndStringifyWithParens('4 lb + 1 lb^2 / 2 lb'), '(4 lb) + ((1 (lb ^ 2)) / (2 lb))')
	assert.strictEqual(parseAndStringifyWithParens('1 m/s^2 + 1 m / 2 s^2'), '((1 m) / (s ^ 2)) + ((1 m) / (2 (s ^ 2)))')
	assert.strictEqual(parseAndStringifyWithParens('8.314 J/mol K'), '(8.314 J) / (mol K)')
	})

[ChristopherChudzicki]

Thanks for pointing out that test. This commit ChristopherChudzicki@55cbd92 on branch cc/consistent-implicit-mul shows the changes to that test. (That test passes on branch; others still fail.)

Before this special rule we had a behavior satisfying the first two principles, but people where confused why for example 1/2 hour evaluates "wrong" (expecting it to evaluate as (1/2)*hour)

One possible solution to this confusion without sacrifing properties like invariance under "wrap in parens" and "replace by variable" would be to issue a warning:

math.parse('1/2 h')
// Warning: Implicit multiplicatin detected in division. This can lead to
// unexpected results. See <<link to FAQ>> for more information. Silence this
// warning with `noDevWarnings: tru`

Such warnings could be issued always or only in development environments.

Even without a warning it seems much easier for users to understand how to control precedence in 1/2 h ("use parens to control precedence") than it to understand why 1/2 h and 1/(1+1) h evaluate differently. Without Rule 2, the parser is more cnsistent and easier to understand, though the initial result might surprise some (not "surprise all", I expect).

Regarding the 1/2 h a little further: I hypothesize that many people might intepret 1/2 h differently depending on whitespace (1/2 h vs 1 / 2h) and perhaps depending on whether they have in mind that h represents a unit (like hour) or a height. My view is that guessing which of these the user means is best left to some NLP / AI tool. MathJS does NOT do that sort of guessing right now, but "Rule 2" seems to fall in that vein. My view is that a parser like MathJS is better off prioritizing consistency and mathematical properties (invariance under variable replacement, ...).

A proposal

The current situation is a compromise, and is not adhering to the guide lines in some cases. Do you have a proposal for a better compromise?

My proposal is:

• Revoke Rule 2 => Parser gains (in this situation) invariance under variable substitution and parenthesization.
• Rewrite portions of the documentation about implicit multiplication. It is less "tricky", though 1/2 h may not match first expectations of some.
• Add a warning only when NODE_ENV==="development" and that can be supressed by a noDevWarnings config option.
  • note that NODE_ENV==="development" includes the development mode of frameworks like React, Vue, etc.

What to do

@josedejong All that said, I also recognize that Rule 2 has been in place for 5+ years, and I'm not sure it's caused that many problems. (Although, maybe it has? A code comment calls it "infamous".) So I completely understand if this is not something you're interested in pursuing further.

If you are interested in exploring this more, let me know. I would be happy to fix the remaining tests on my branch, open a proper PR for discussion, or put in other work towards (what I see as) this improvement. And I realize "more work" does not mean "yeah let's do this!".

[josdejong]

Thanks for working out the alternative results in this commit Chris.

The cases like 1/2 x are the main reason that this Rule 2 was implemented. We consciously weighted the pros and cons (pros: more user friendly, less WTF's of users in day-to-day usage, cons: less consistent behavior, more complex to understand). Evaluating this again as 1/(2*x) feels like a step in the wrong direction to me, to me that is still a no-go, sorry. I remember we also considered giving whitespaces meaning, but we dismissed that because that most likely give a lot of confusion (much more than Rule 2). I think in general there is room for improvement of Rule 2, though it will most likely become more complicated. If I enter some expressions containing implicit multiplications in Google, somehow it always nails it it seems. I don't know what rules are behind that calculator, but that could be interesting to explore further.

Outputting a warning is an interesting idea. Such warnings can be helpful for developers, that look at the console, but in general mathjs is used a lot by end users using a UI on top of mathjs, and they will not magically see such a warning unless support for it is implemented by the UI (not the case by default). In general, you can build such a warning yourself already by parsing the expression and then traversing it to see if it contains implicit multiplication.

An other idea for UI's is to display how the expression is interpreted exactly, showing parenthesis. I've seen that first by https://qalculate.github.io/, and also Google does this right now. That is a UI decision though, and does not require any change in mathjs itself.

The root of the issue is that implicit multiplication simply makes matters complex because it is ambiguous. One solution is simple: if it is so complicated... don't use it. We could implement an option to disable implicit multiplication. It is already possible to write a simple wrapper function for that yourself (parse an expression, check if it contains implicit multiplication, if so throw an error, if not evaluate it).