2^3^4 - a comparison of math packages | Hacker News Reader

2^3^4 - a comparison of math packages

plus.google.com

30 pointsColinWright27 comments

This is exactly why when ever I need to do any sort of math in a program I make sure to put parens around any single operation. Even 2*2+2 gets the treatment because god knows there have been people who screwed that up.

> Even 2x2+2 gets the treatment

2+2x2 I can see (Smalltalk has strict left-to-right evaluation of operators, so it parses as (2+2)x2), but for 2x2+2 to give the "wrong" would require `+` to have a higher precedence than `*`, something I've yet to see (short of abusing haskell to redefine the operators with fucked up precedences)

edit: god fucking dammit HN can't you get any markup right?

My point exactly. Had I had to do something in Smalltalk and not known that, that would have been a fun bug to find had I decided to be frisky and write it as 2+2*2.

If I recall correctly, APL executes right to left -- so it would return 8 for 2*2+2.

Neat, I'd forgotten languages could execute RTL as well.

It makes more sense for 2^3^4 = 2^(3^4). If you meant (2^3)^4, then it would be more efficient to calculate 2^(3*4), because exponentiation takes much longer than multiplication.

On a related note, in Excel, -1^2 = 1 because they are calculating (-1)^2 instead of the more standard interpretation, -(1^2).

Incidentally, I mentally parse -1^2 as (-1)^2, but I parse -1² as -(1²). Reading your post I was thinking "well yeah, minus one squared is one, what else would it be?"

All of the "4096" results have exponentiation as left-associative, despite the common conventions that exponentiation is right associative.

Seeing the example really makes me wonder why that convention exists, and also makes me ponder whether having variate associativity is actually a good idea after all. Especially in languages like Scala, where you can change the associativity of your binary functions through function naming.

Though I can see why things like the cons operator "::" make a lot of sense.

Why is exponentiation associative? This:

      4
     3
    2

You should also try to visualize the 4 smaller and 3, and 3 smaller than 2. Because this is the way it was written for a long time.

At the first glance I thought 3 is smaller than 2, 4 is smaller than 3. But after reading your note, I realize they're of the same size. That's what "conventional" means for me. :-p

It's interesting to think that the whole notion of associativity and order of operations only exists because for some reason humans seem to find infix notation more "natural" for binary (or fixed arity) operators than more easily parseable and less ambiguous alternatives like prefix.

^ ^ 2 3 4

Prefix notation doesn't automatically solve the problem, you need to assume an evaluation order. More specifically, you need to not assume associativity.

Isn't the lack of associativity explicit in prefix notation? Prefix notation doesn't even contain the notion of order of operations. You would convert the infix "2^3^4" to prefix in different ways depending on the associativity of exponentiation:

For left associativity (uncommon):

    ^ ^ 2 3 4

For right associativity (common):

    ^ 2 ^ 3 4

Of course, all this is assuming all operators are fixed arity, otherwise you need parentheses no matter what.

Exponentiation is right associative because

  (a^b)^c = a^(b.c)

(using dot for multiplication because I fear that HN will mess up an asterisk)

So, a right associative exponentiation makes your expression language more powerful.

Common Lisp FTW:

        ? (expt 2 3 4)
        > Error: Too many arguments in call to #<Compiled-function EXPT #x3000000A6C2F>:
        >        3 arguments provided, at most 2 accepted.

And thus forces programmer to think about the order of non-commutative operations.

The fact that infix notation removes the need to think about that is a bad thing, because infix notation is inherently ambiguous unless you litter the expression with parentheses or explicitly think about operator precedence and associativity. Infix notation just appears to be easier on the mind, because we're first taught arithmetic using it.

No different from C / Java / most others.

Oh, it's different all right:

    ? (expt (expt 2 3) 4)
    4096
    ? (reduce 'expt '(2 3 4))
    4096
    ? (expt 2 (expt 3 4))
    2417851639229258349412352
    ? (expt 3 (expt 4 5))
     373391848741020043532959754184866588225409776783734007750636931722079040617265251229993688938803977220468765065431475158108727054592160858581351336982809187314191748594262580938807019951956404285571818041046681288797402925517668012340617298396574731619152386723046235125934896058590588284654793540505936202376547807442730582144527058988756251452817793413352141920744623027518729185432862375737063985485319476416926263819972887006907013899256524297198527698749274196276811060702333710356481

Not a comparison, just "does ^ bind to the left or the right in different software?"

But they shouldn't bind a^b^c to (a^b)^c without parentheses.

That's exactly the difference between binding to the right and binding to the left (aka left-associativity and right-associativity). A left-associative exponent will parse to `(a^b)^c`, a right-associative one will parse to `a^(b^c)`

What I was trying to say is that parsing exponents like that makes as much sense as parsing a+b* 2 to (a+b)* 2.

No, it makes as much sense as parsing a* b* 2 to (a* b)* 2.

Yes - which basically boils down to "if you are maths-centric enough to know which way ^ should bind, you probably shouldn't be working in excel"....

On a very unrelated note when I type "(2^3)^4" in google i get "4 096" and when I type "2^3)^4" I get "4096" (notice a space gone)

(4000+1.1 has a space and (4000+1 doesn't, not sure what that means.

Reply on news.ycombinator.com