calculators giving different answers

Indeed, although I believe Thudlow Boink is pointing out that Fermat was both a lawyer and a mathematician.

Yes, I love Google calculator. However, I wish it would also helpfully display, in the same manner, its preference for degrees vs radians, or other units.

Google’s outputs are either (depending if you specify degrees or not)

sin(45) = 0.850903525
sin(45 degrees) = 0.707106781

insert preemptive “shut up” to radians-being-non-dimensioned pedantry sure to follow

It is equally awkward and unhelpful when trying to convert between bases (binary to decimal to octal, and such) unless I monkey with testing known results to deduce what defaults it likes.

Now, one might say “Gargoyle, get a real calculator to crunch engineering math”. But when I’m in an airport and all I’ve got is my Nintendo DSLite or a rentacomputer, I’d like access to something nice and Googly for math beyond basic arithmetic.

I tried it in my Casio fx-991MS and also got 2. The calculator places implicit multiplication of a quantity in parentheses above explicit multiplication and division in its order of operations.

Seems reasonable, because normally the only reason you would place a number outside of parentheses with no operator is if your intention was to immediately multiply it.

Excuse me?

8/2*(5-3) as written, using proper order of operations, would be resolved in the following sequence:

8/2*(5-3)

8/2*2

8/4

2

This is because you resolve the multiplication before you resolve the division, to eliminate the otherwise ambiguous nature of the symbol for division.

And no, not “every” programming language would resolve them your way. But the TI-83 says “8”.

(To answer the question about “Esq”, I used to work as an attorney (still licensed in one state), but I’ve moved on to better things. :slight_smile: )

Do you have a cite for this?

Because the way all the beginning algebra textbooks I’ve seen explain the rule for the order of operations, “multiplication and division, in order from left to right” is a single step. And my scientific calculator interprets “8 / 2 x 2” as 8.

(And yes, Fermat is the name that springs to mind when I think of a “a lawyer, though one with a marked interest in math.”)

It’s not how any programming language would interpret it. In fact, it’s not even how every calculator would interpret it. According to wiki because I don’t own any calculators,

Now, I think this makes more sense because, as I stated, if you wanted x/2 you should have written x/2. The order of keying into an RPN calculator assumes that you are smarter than the machine and will tell it what you want. TI-82 also seems to do so.

Now that’s fine that algebra text books say to do one thing, but I maintain that it is ambiguous. In fact, the number one hit when I searched “order of operations algebra” in Google was this page which contains the following gem:

which is certainly not true. :mad:

This statement is false.

cybernetic head asplodes

Agreed. Parentheses are a kludge.

Oof, that’s horrible! Yeah, it doesn’t matter in their specific example, but only because the division is last.

Every language I’ve used requires the * for multiplication and will raise a syntax error if you write

8/2(5-3)

If you make the multiplication explicit like this

8/2*(5-3)

the following languages, off the top of my head, apply division and multiplication at the same level from left to right and would render an 8:

Ada
C
C++
Excel
Fortran
Java
PL/1
VBA
SNOBOL
VBA

Please cite one that won’t. Calculators are another issue because they can interpret an implied multiplication, and may give a higher precedence to implied mulitiplication than explicit multiplication, which I still believe is erroneous.

I don’t think Wikipedia is an authoritative source on this.

APL evaluates everything from right to left in order. You still need an explicit multiplication, of course, but 8/2*(5-3) would be evaluated as 8/(2*(5-3)) = 2. In fact, without parentheses 8/2*5-2 gives the exact same result.

Not the tech manual, but a description of the syntax can be found here:

The reason the language interprets everything right to left and in order is that it is based around an idea of functions rather than operations.
The “order of operations” isn’t something which is a fundamental truth of mathematics. It’s just a convention. Sometimes it comes into conflict with the conventions for typing things. When writing longhand, especially when space is tight, it would not be ambiguous to write 8/2(5-3) to instead of 2. Especially if you did something more like [sup]8[/sup]/[sub]2(5-3)[/sub]. It’s certainly more convenient if your calculator can interpret 8/2(5-3) or 8/2*(5-3) as 2, because it avoids an explosion of parentheses. Anytime you needed 4 you could just write 8*(5-3)/2 and be done with it.
As for which is “right” well, it’s all just convention. Should punctuation go inside or outside of quotation marks? Depends on which side of the Atlantic you’re on. Both conventions have their merits.

By the way, what does Excel return when you input =-1^2 what about =1-2^2 or =1±2^2? Are those answers right or wrong?

I’m a bit confused; what do you mean by this?

Only if they’re only required sometimes in ill-defined circumstances. If they’re always needed you can have functions with variable arity without needing arbitrary kludges to delimit how many operands they consume. Plus, parenthesizing everything means your source code is a trivial representation of a parse tree, so making real macros (functions that apply arbitrary transformations to parse trees) is easy.

If you need a concrete example, look at Lisp and Scheme.

A middle path is to use APL rules: Everything is evaluated right to left unless parentheses explicitly force another ordering. So 56+3 == 59 == 45, but (56)+3 == 30+3 == 33. Nobody likes APL-like languages enough to apply this to any other family of languages, so it will make people scream because it looks normal until 56+3 evaluates to 45. :wink:

Because functions are evaluated right-to-left when written in the usual fashion: f(g(h(x))) evaluates h(x) first, then feeds the result to g(), then feeds the result to f(); f(), the leftmost function, is evaluated last.

APL-like languages seem to sit in an uncomfortable position between traditional infix (their syntax) and functional (their semantics), because Ken Iverson wanted a mathematical notation that was unambiguous and (presumably) didn’t like parentheses all that much.

Oh. I suppose that’s true. Though, when written in the usual fashion, there’s also so many parentheses around that there isn’t even any potential ambiguity. But, yeah, I can understand the motivation of taking that convention and just removing the necessity of the parentheses.

I’m, of course, used to languages like Haskell, where currying is so ubiquitous that the traditional function-on-left, argument-on-right convention actually leads to the opposite decision, to left-associate by default (so that one might define a function “add” with the property that add 1 2 = (add 1) 2 = (the function which adds 1 to its argument) 2 = 3, rather than having add 1 2 = add (1 2) = add (the result of applying 1 to 2?) = add (WTF?) = death.

I forgot to close a parenthesis there. I am duly chagrined.

What Derleth said, although I’d say that fgh(x) is more usual than f(g(h(x))), just because the latter is so much more difficult to read.

And the reason you think 5*6+3 should be 33 is just because they told you so in elementary school. Lots of stuff they told you in school turned out to be wrong. :wink:

i think i understand the point about conventions and that either answer might be correct depending. but, judging from the reactions so far, can someone spell out exactly why the BODMAS rule for order of operations is so, so “brains splattering on the pavement” wrong? and considering that it doesn’t seem to have a use outside of its own topic in primary school, why is it taught at all?

you would think Maths is the one subject where the rules would not change with the playing field.

It’s not that wrong. It is the convention almost everywhere you go. But sometimes it’s not.