Hacker News Reader

Comment by riebschlager | Hacker News Reader

Maybe it's a weird takeaway, but this line is really clever:

var suit = i / 13 | 0;

That's such a clean way to get a 0, 1, 2 or 3 from each card's `i` and I never would have thought of it.

If you're referring to |0 then I would disagree. It shows how horrible JavaScript is. This is very confusing if you're not familiar with this trick or strange behavior of the language.

    suit = int(i / 13)
    suit = (int)(i / 13)
    suit = math.floor(i / 13)

Are much easier to understand for someone not familiar with the code.

The behaviour of JavaScript's bitwise operators isn't that unreasonable, but the excessive use of this trick for tiny performance gains at the expense of readability is a shame.

I take your point, but that's some crazy non-JS typecasting in your first two examples :)

Languages are what they are, and if you're going to use one you might as well use it idiomatically. Maybe it's just me, but I see "|0" all the time in JS, not as some kind of crazy performance hack, but used idiomatically to mean "truncate".

And on the flip side with JS's lack of number types, any code that looks like it's doing type casts (rather than math) looks out of place. If one must mess around with JS number types then all you can really do is give hints to the optimizing compiler, in which case "|0" is the standard way to hint that you want a small int.

Obviously what looks clean is a matter of opinion, but FWIW.

suit = Integer(i / 13) suit = Math.floor(i / 13)

1.89% faster than Math.Floor, 100% more hard to read.

I used http://jsperf.com/or-vs-floor/2 in Firefox 40.0.3 and it was only 0.37% faster. Was similar in Chrome.

I think "value | 0" is basically same as "Math.floor(value)"

Yes, but it is 18% faster do run the bitwise or on my machine:

https://jsperf.com/or-vs-floor/2

Its because they don't do the same thing

Math.floor() favors the number equal to/less than the parameter, Math.floor(-15.5) is -16 while (-15.5 | 0) is -15

Also because the returned value is int32[0],

Math.floor(2147483648.5) is 2147483648 while (2147483648.5 | 0) is -2147483648

You are fine if you know the input is less than (2^31) + 1 and you want to truncate, rather than floor.

[0]: http://www.ecma-international.org/ecma-262/6.0/#sec-binary-b...

ECMAScript 2016 adds Math.trunc()[0] which should give the same value as | 0 for inputs that fit in 32 bits.

[0] http://www.javascripture.com/Math#trunc

Hmm, pretty sure floor rounds a number downward to its nearest integer. So Math.floor(-15.5) would be 15.

https://developer.mozilla.org/pt-PT/docs/Web/JavaScript/Refe...

Literally the first example on that page:

> Math.floor( 45.95); // 45

> Math.floor(-45.95); // -46

Its not like its hidden or anything... Its in the center of the page on my 1920x1080 screen.

Nope. Math.floor(-15.5) would be -16. It rounds a number downwards. -16 < -15.

There is no substantial difference in performance on mine (within 2%), although the OR was always a little bit faster.

Chrome 45 on Linux

It's odd that a bitwise operator should have the effect of truncating the float (since X|0 == X)? I'm guessing there's an implicit type conversion to int in the middle?

The bitwise operators don't make sense for floating-point values. So they work by converting to a 32-bit integer first.

And every time a developer sees that, they're going to google "bar javascript" "single bar javascript" "bitwise or javascript" "bitwise or javascript effect" until they figure out WTF is going on.

This all to save a fraction of a microsecond on an operation that's called 60 times on the page.

Actually only 52 :D

But yeah, I agree about googling part: I remember having Googled "tilde javascript" and "pipe javascript".. :)

Tilde is useful with indexOf:

if (~array.indexOf(item)) {}

..equals to:

if (array.indexOf(item) > -1) {}

This is the sort of thing that makes Perl readable in comparison to Javascript :)

i/13|undefined works too

plus

  i/13|undefined

has that "this was originally written in javascript, not ported halfheartedly from some other language" feel. (Well, maybe PHP.)

That's just adding another conversion from undefined to Number to Int32 for the right operand. You could probably use false as well. Or the empty string.

gulp I guess I should stop using parseInt :/

value | 0 will always return a 32 bit integer.

Math.floor(value) can return some weirder values such as: NaN (for anything that isn't a number), and Infinity, -Infinity, -0. And Math.floor(-1e-300); is -1 so care needs to be taken with floating values near zero.

Why not just i % 4?

that would alternate the suit for each card, and all the aces would be the same suit, etc.

If you also take the cards modulo 13 for their face, this approach works.

4 and 13 are relatively prime, so each number between 1 and 52 can be uniquely represented by the function (x) -> (x%13, x%4).

Yes, obviously it's not a drop in replacement as the behavior is different, but it does the same thing, giving you a number from 0 to 3 based on the card number. Pairing it with i%13 works just fine.

on my deck hacks i use proper data structures but on the initializer for the deck i have `suit = i % 4`.

which has the advantage of working with any size of deck. important since in brazillian truco you leave most of the numbers out ;)

In asmjs you see this sort of syntax 'num | 0' a lot [0] to enforce that the number is an int, so that may be where he got the idea.

[0] http://www.sitepoint.com/understanding-asm-js/

It exists in other languages, too, like PHP.

You can do this in PHP, but you shouldn't.

Use (int), like C.

It is not much worse than using it in javascript. People do this in js because it saves a few keystrokes and its faster, not that it matters. Its a small thing. Its dirtier, for sure.

I just tested it in PHP and it seems it is 20% faster in PHP compared to casting to int. Maybe someone out there will have a weird use case for that, or someone doesn't want to put more effort into writing code into terminal and doesn't care about his code being unreadable. I think its useful to know it exists.

Btw, do you or someone else know why its faster in php too? Its a bitwise operation and I assume under the hood its casting to int, its weird to have it faster than casting it to int, why does this happen? It makes sense in javascript to that its faster than functions, but why it is faster than a cast in PHP?

> It is not much worse than using it in javascript.

It is worse because people are even less familiar with this in PHP. It's not idiomatic.

> I just tested it in PHP and it seems it is 20% faster in PHP compared to casting to int.

How rigorous was your testing? Which version of PHP were you using?

> It makes sense in javascript to that its faster than functions, but why it is faster than a cast in PHP?

It shouldn't be. It might save an allocation in older PHP versions, I'm not sure.

Putting aside whether this sort of thing is clever and clean or occult and confusing, another pattern of the same ilk is:

  ~~(i/13)

for me I see `~~` and I think coerce to integer value (the result will be an integer regardless of i's value, 0 if it fails a clean coercion)

Similar to seeing `!!` and thinking true/false coercion.

Reply on news.ycombinator.com