feat: give unary % operator (percentage) higher precedence than binary % operator (modulus)

[kiprobinsonknack]

This is a fix/change to #3349

This gives unary % operator (percentage) higher precedence than binary % operator (modulo). This also makes unary % operator have higher precedence than *, /, .*, ./, and mod operators.

This partially rolls back changes from #3311; however, intended behavior from that change is preserved: the precedence of binary % operator (modulo) has not changed. For example, 11*12%13 is still treated as (11*12)%13, whereas in MathJS v13 it was treated as 11*(12%13).

Breaking Change

This is a BREAKING CHANGE and should get a new major version:

• v13: 100 / 50% = 100 / (50%) = 100 / 0.5 = 200
• v14: 100 / 50% = (100 / 50)% = 2% = 0.02
• this PR: 100 / 50% = 100 / (50%) = 100 / 0.5 = 200 (restores v13 behavior in this scenario)

Another example where 13/14/PR behavior are all different:

• MathJS v13: 10 / 200 % % 3 = 10 / ((200%) % 3) = 10 / (2 % 3) = 10 / 2 = 5
• MathJS v14: 10 / 200 % % 3 = ((10 / 200)%) % 3 = ((0.05)%) % 3 = 0.0005 % 3 = 0.0005
• This PR: 10 / 200 % % 3 = (10 / (200%)) % 3 = (10 / 2) % 3 = 5 % 3 = 2

---

Additional change:

200%% previously failed with Unexpected end of expression (char 5) error; with this PR it fails with Unexpected operator % (char 5) error. (This was intentional as I believe it is a clearer error.)

---

Additional comments

I looked into ways of handling something like 200%%% = (200%)%)% = ((2)%)% = (0.02)% = 0.0002, but I couldn't find a way to make it work without breaking other tests. Given that it was already an error in previous version, and it's unlikely (in my estimation) that someone would actually want to do that, I didn't investigate further into fixing.

Additionally, I found that 5%(13) is treated as 5 mod 13 rather than (5%) * 13 (implicit multiplication). My PR doesn't change this behavior, and I believe it is actually desirable because the parser doesn't care about whitespace so 5%(13) and 5% (13) and 5 % (13) are all handled the same way. But it may technically be wrong based on the operator precedence documented in syntax.md.

[josdejong]

Thanks Kip, this looks good at fist sight! I'll review and test this in more indepth next week.

[kiprobinsonknack]

Thanks Kip, this looks good at fist sight! I'll review and test this in more indepth next week.

@josdejong any update?

[josdejong]

Yeah sorry for the delay, I'm having trouble keeping up with all the mathjs issues lately but it is definitely on my list. Thanks for the reminder.

[josdejong]

Thanks Kip! The PR looks well taken care of. I really like this improvement/fix, it makes sense.

About cases like 200%%%: thanks for improving the error message. This makes sense. If someone really want to do this calculation, he/she, can add parenthesis like ((200%)%)%.

I made one inline remark to simplify parseUnaryPercentage a bit, can you have a look into that?

Also, I changed the base of the PR to a new v15 branch, since this will be a breaking change.

[josdejong]

Thanks @kiprobinsonknack, I'll merge your PR now. I do not know when we'll release v15, but I keep track of that in #3453.