A shorter way to do Math.floor – A little known trick
tapper-ware.net
tapper-ware.net
Also, it only gives the right answer for positive numbers, its off by one on negative numbers.
In other words, this is micro-optimisation at a pointless level.
Math.floor = 2224ms for 100,000,000 iterations 0| = 302ms for 100,000,000 iterations.
So in terms of performace, the difference is moot. If you want hacky non readable code that sometimes works, use 0|
> ... if someone else sees your code
> they won't know what is going on.
I don't see that as a problem. If you're really worried about readability, wrap it in a macro.
Only giving the same answer as floor for positive numbers need not be a problem - you just need to know that it will do what you want in the context you have. So often one uses "floor" because it gives the right answer, and not because it's actually "floor".
If performance is an issue, then use these obfuscating idioms, but only if you are able to abstract them well and maintain performance (as you suggest), or document them completely and concisely.
There is a balance to achieve. This is one example, and arguing the specifics of this one example is not as useful as being able to make judgement calls in the wild, for real, and get most of the close enough to right. It's not exact.
But idioms, per se, should not be rejected out of hand purely because they're unknown to you.
This idiom obfuscates, as you state yourself, because people who aren't comfortable with the language will find it jarring at first. I understand where you are coming from: If everyone knew it, it wouldn't be obfuscating. But I argue that people forget idioms or never learn idioms that don't map to our human explanations rather quickly, so it increases maintenance costs.
I argue that in this case, it obfuscates simply because bitwise or'ing data is too low level and doesn't have a lot to do with rounding down without understanding the internal representation of the number.
I agree that code should be written at the highest level possible to express the intent, but sometimes that's not possible. In this case it's likely that performance wasn't an issue, and this particular idiom is actually of no value, but I contend that the principle remains: an idiom need not immediately be clear, and yet can still sometimes be the right thing to do/use.
Your last point is simply acknowledging that this is an idiom - what you say is characterising what an idiom, as opposed to an expression, is. It's not what you might expect, it's short, it accomplishes its purpose.
Finally, and again, I say that this particular example may not be a good one, but I say again that sometimes idioms are appropriate. You may disagree, but you haven't persuaded me. Our experiences no doubt differ, and may be the root cause.
It’s clear that using the bitwise or operator adds some bit of mental overhead, at least the first few times the reader looks at it, while floor is completely obvious and clear to the average novice programmer. This mental overhead slows the reader down, and makes the code harder to understand. If it’s just one line like that every few hundred lines, or some optimization in an inner loop that is clearly commented, that’s not a problem. But code written by someone who has decided that all of their tricky lines that first look like one thing but actually do something unexpected are actually wonderful “idioms”, is code that can become a serious pain in the ass for whatever poor sap has to build on top of it or fix its bugs.
Well, "obfuscate" does, but "idiom" doesn't.
Consider. I've dealt with people who were considered above average programmers and yet for whom "floor" wasn't obvious. They needed to look it up, and then they needed to look it up again when they saw it the second, and sometimes the third time. It cost them mental overhead because it was something they didn't know immediately, it's in a library, they needed to find it, and it's not actually part of the language.
The bitwise operators, however, they knew immediately. They were part of the library, they could immediately deduce what was happening, because it was part of the language. They were glad that someone didn't use some library call that they'd have to look up, and instead used the actual language itself, the built-in operators. And it was clear from the context that the desired result was an int that was close to, and preferably smaller than, the float they started with.
So there's an alternative viewpoint, and one from my direct personal experience. I agree entirely that code should express the intent of the programmer, and it should be clear, and that future maintenance is critical.
I'm not for a moment advocated that every clever, unobvious, difficult to disentangle trick you know should be used. Of course it shouldn't. Code should be clear, concise, and express its purpose.
But it should, above all, be maintainable. And sometimes an idiom is short, precise, unambiguous and does what is needed, and sometimes it's easier to simply regard it as an idiom of the language and get on with it.
Sometimes idiomatic code is, well, OK.
And I'll stop there. Feel free to disagree, feel free to dismiss my experience, thoughts and comments with an airy "no - it's not maintainable - it's not instantly readable - it's not possible for a programmer with no experience to modify effortlessly." It's not fashionable to expect maintenance programmers to have brains and skills.
Sorry. </rant>
That said, could we fix the negative value issue as follows and still see performance benefits (don't have the time to test at the moment)?
x = x < 0 ? (0|x) - 1 : 0|x;
---or maybe---
x |= 0;
x = x < 0 ? x-1 : x;
---or possibly---
x |= 0;
x = ((x ^ (x >> 31)) - (x >> 31)) - 1;
If the above bitwise operation were wrapped in a helper function, would we still see any performance gain?
function doubletilda() {
~~0.12341234;
~~0.2;
~~-3.1234;
~~100000.23;
~~2.12341234123412341324;
~~100.0000000000000000001;
}
function pipe() {
0.12341234|0.12341234;
0.2|0.2;
-3.1234|-3.1234;
100000.23|100000.23;
2.12341234123412341324|2.12341234123412341324;
100.0000000000000000001|100.0000000000000000001;
}
And the loop is:
// var fn = doubletilda;
for (var n = 0, t = 0; t < 1000; n++) {
fn();
t = new Date() - start;
}