(and does that need the outer parentheses?) I doubt the first passes dieharder, as (if my C isn't too rusty) it alternates between odd and even numbers.
Yeah ok. I'd consider that just a thing you gotta know. Like how for certain floating point values (a / b) * (c / d) can be fine while (a * c) / (b * d) gives you +/- infinity.
It's a separate operator after all, one I also miss a lot...
> My thought is just to remove precedence and associativity entirely -- instead of "a + b + c/2" you have to make it explicit -- "a + (b + (c/2))". The only problem that I see is that there are two ways of writing this, you could also write "(a + b) + (c/2)".
Sure. But somebody writes it once and you can benefit from it. If you don't have operator overloading there isn't any chance of doing this.
At any rate, I feel like the goalposts have been moved a bit. You originally said:
But then you'll soon want to do A*B+C, and you'll find that fused multiply/add is a much faster operation than doing a multiplication and then addition, and soon you'll either be writing mul_add(A, B, C) anyway
Which I just wanted to point out that you can fuse these operations with operator overloading as well. I am pretty sure that
or you'll overengineer a complex solution to make A*B return some kind of object that can recognize the subsequent + operation etc.
was a later edit, I don't remember reading it when I first reacted to your comment. If so, doing that is not really nice, since it breaks the flow of the reactions.
At any rate, I think we agree on all the trade-offs.
And typing the multiplication operator in HN syntax sucks :).
The unintuitive part is the choice of operator `<<` instead of `>>`. in your example `f << g` means do `g` first (i.e. 2 + 4 = 6) then do `f` on the result (i.e. 6 * 3 = 18). I would have expected `f >> g` for this behavior.
There is the symbol '*'. And when there's two integers it does one thing, and you can think about it as repeated addition. But when there's something different, it works differently. But now we're just going to concentrate on integers.
Mentally, I perform no-written-operator multiplication first, then anything else, so I can see why the calculators (and WolframAlpha, in some cases) are getting the intention wrong:
"6 ÷ 2x" gets parsed as "6 / (2 * x)"
"6 ÷ 2 * x" gets parsed as "(6 / 2) * x"
All that's done in the equation in the article is having a pair of brackets instead of a variable, but the result is the same to my brain.
I've recently had to deal with some code that did this for work (and also used operator* for dot product) and it made the equations incredibly difficult to read. Please don't make the mistake of doing this in your own code.
The disconnect is that a lot of people mentally treat implicit multiplication with a higher priority than explicit, which is pretty understandable. For instance:
1/3x
is likely to be understood as 1/(3*x), because otherwise it would’ve been written like x/3. If that’s true, then so surely
1/3(x)
should be the same, right?
Smarter people than I have argued both sides of this, and I don’t have a strong opinion except to use parentheses if there’s any possible ambiguity. Just saying, I totally understand why you’d come to that conclusion, and I probably would too.
The problem with that is by the time I reach `20)` I have already forgotten what operation I'm in. I'd write it more like this:
actually I'd write this as > ((34 + 68 + 12 + 9 + 20) / 140) * 1.5 * 2Why not (34 + 68 + 12 + 9 + 20) * 1.5 * 2 / 140?
reply