Wrong order of execution

[Former user]

Hi guys,

there is a little nice bug in speed crunch. Try these two calculations.

6/2*(1+2) 6/2(1+2)

The result should be 9, so the first one is correct.

[gilga]

It’s not a bug.

It’s the normal priority: division and (implicit or not) multiplication have the same priority, so they are evaluated from left to right.

To get 9, you need to write:

6/2(1+2)6/(2(2+1))

‌

[Ville Aakko]

Hi,

I just want to point out that the comment by gilga is self-contradicting. An implied multiplication is interpreted here differently than an explicitly written out (as pointed out by Former user). I.e. 6/2*(1+2) != 6/2(1+2) (according to Speedcrunch), i.e. in the absense of a multiplication sign, it takes precedence (the whole of 6/(1+2) is in the denominator). But according to gilga the examples in report should be equal?

There is also some typo on “To get 9” - both 6/2(1+2) and 6/(2(2+1)) give 1 as an answer (as does 1*1), as it does not seem to make sense.

Some food for discussion:

I believe it is also not a bug, but there is some room for improvement. This should well documented (well, TBH users will find out quite promptly, but would highlight the design choices and remove any need for future bug reports) and perhaps, more preferentially, made into a user-defined preference.

The crux of the problem is summarized here: https://math.ucr.edu/home/baez/physics/General/binaryOps.html (and elsewhere; but this is the best summary I can find). Also, Wikipedias article on Order of operations has a good write-up written in an objective, non-opinionated and non-heated fashion (this problem creeps up in memes and elsewhere all the time).

As someone with a background in physics - I’m kind of leaning towards interpretation ucr.edu arcitle interpretation B (i.e. juxtaposition or “leaving out the multiplication sign” always implies a block or a set of parentheses, or as they put it, “multiplication that is implemented before anything else)”, as this is what physicists quite often tend to do. But they in the article say we should follow interpretation A, i.e. different on what Speedcrunch does (but the same what op wants).

But the whole issue fact also highlights the fact that sometimes, the way people write maths, is context-sensitive. Outside calculators (in hand-written math) this kind of ambiguity is more often than not avoided one way or another - the ambiguity comes more prevalent when writing math on one line (usually calculators, but sometimes even in textbooks or journals, but the author(s) choose one convention or the other to remain consistent).

Also, I’m not trying to take sides here, just pointing out there is no agreed upon standard; I believe people should just find out how their calculators work and deal with it, whatever that way might be.

I can also see that some users might really, really like speedcrunch but have some difficulty to adapt to interpretation B. So it would be sensible to have a user-settable preference on how to deal with implied multiplication.

‌

TL;DR: Label as not-a-bug, improve documentation, make this a user-preference

EDIT: some minor clarifications / trying to remove some ambiguity and lessen the chance of mis-interpretation

[Ville Aakko]

I also noticed this has been “fixed” in dev builds since 2016, but not in any release so far. Also multiple previous duplicates (I’m using 0.12 on Arch Linux).

I do slightly (meaning I don’t have any strong feelings) disagree on the fix; as both ways of calculating are correct IMHO, the problem is just that it is ambiguous when not using a multiplication sign / there is no universally agreed upon standard.

I still feel the best way would be to make this a preference. Many users used to current (and also correct!) behavior might be confused when a new version is released.