# Javascript: Math.floor(var) versus var | 0

**URL:** <https://boards.straightdope.com/t/javascript-math-floor-var-versus-var-0/675592>\
**Category:** Factual Questions\
**Created:** [December 5, 2013, 6:20pm UTC](https://boards.straightdope.com/t/javascript-math-floor-var-versus-var-0/675592 "2013-12-05T18:20:50Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![Zyanthia](https://avatars.discourse-cdn.com/v4/letter/z/d6d6ee/32.png) [@Zyanthia](https://boards.straightdope.com/u/Zyanthia)\
**Post date:** [December 5, 2013, 6:20pm UTC](https://boards.straightdope.com/t/javascript-math-floor-var-versus-var-0/675592/1 "2013-12-05T18:20:50Z")

</div>

So I was looking at a javascript and I saw someone using the bitwise or ( ‘|’ ) in a function. I had never seen this so I tested it out using the console.

console.warn (5 | 0); \<— returns 5  
console.warn (5.1 | 0); \<— returns 5  
console.warn (5.9 | 0); \<— returns 5

Is doing a bitwise or on a number cheaper than calling the Math.floor function? Is it doing something else that I’m not seeing?

Here’s the script I found it in:

```auto

function shuffle (inArray){
   var slotToSwap = inArray.Length, temp, newSlot;
   while (slotToSwap-- ){
      **newSlot = (Math.random() * slotToSwap) | 0;**
      temp = inArray[slotToSwap];
      inArray[slotToSwap] = inArray[newSlot];
      inArray[newSlot] = temp;
   }
   return inArray;
}

```

---

<div class="post-metadata">

**Author:** ![friedo](https://avatars.discourse-cdn.com/v4/letter/f/8edcca/32.png) [@friedo](https://boards.straightdope.com/u/friedo)\
**Post date:** [December 5, 2013, 6:31pm UTC](https://boards.straightdope.com/t/javascript-math-floor-var-versus-var-0/675592/2 "2013-12-05T18:31:40Z")

</div>

Hint: what happens if you try

```auto

console.warn( 43674343743.87373 | 0 )

```

---

<div class="post-metadata">

**Author:** ![Zyanthia](https://avatars.discourse-cdn.com/v4/letter/z/d6d6ee/32.png) [@Zyanthia](https://boards.straightdope.com/u/Zyanthia)\
**Post date:** [December 5, 2013, 6:46pm UTC](https://boards.straightdope.com/t/javascript-math-floor-var-versus-var-0/675592/3 "2013-12-05T18:46:00Z")

</div>

console.warn (Math.floor (43674343743.87373)) \<— 43674343743  
console.warn (43674343743.87373 | 0) \<-- 724670783

It looks like for really large arrays, the above function would fail. So to be safe it really is better to use the Math.floor.

On a hunch, I guessed it was breaking on 2^32, but I was wrong. 2^32 returns a negative number.

---

<div class="post-metadata">

**Author:** ![friedo](https://avatars.discourse-cdn.com/v4/letter/f/8edcca/32.png) [@friedo](https://boards.straightdope.com/u/friedo)\
**Post date:** [December 5, 2013, 6:57pm UTC](https://boards.straightdope.com/t/javascript-math-floor-var-versus-var-0/675592/4 "2013-12-05T18:57:44Z")

</div>

> [@Zyanthia](#):
>
> On a hunch, I guessed it was breaking on 2^32, but I was wrong. 2^32 returns a negative number.

Your suspicion is right. Bitwise operators in JavaScript only work on signed 32-bit ints. Since JS doesn’t really have integers, the argument is silently converted to one internally before the operation is applied. That truncates the decimal portion, and for any float that holds a really big number, you’ll get a weird result.

Also note that truncation is a different operation than floor.

```auto

console.warn( -42.9 | 0 )
console.warn( Math.floor( -42.9 )

```

---

<div class="post-metadata">

**Author:** ![Zyanthia](https://avatars.discourse-cdn.com/v4/letter/z/d6d6ee/32.png) [@Zyanthia](https://boards.straightdope.com/u/Zyanthia)\
**Post date:** [December 5, 2013, 7:02pm UTC](https://boards.straightdope.com/t/javascript-math-floor-var-versus-var-0/675592/5 "2013-12-05T19:02:12Z")

</div>

Gotcha, thank you.

---

<div class="post-metadata">

**Author:** ![Learjeff](https://avatars.discourse-cdn.com/v4/letter/l/94ad74/32.png) [@Learjeff](https://boards.straightdope.com/u/Learjeff)\
**Post date:** [December 5, 2013, 7:09pm UTC](https://boards.straightdope.com/t/javascript-math-floor-var-versus-var-0/675592/6 "2013-12-05T19:09:26Z")

</div>

Never mind!

---

<div class="post-metadata">

**Author:** ![Punoqllads](https://avatars.discourse-cdn.com/v4/letter/p/d2c977/32.png) [@Punoqllads](https://boards.straightdope.com/u/Punoqllads)\
**Post date:** [December 5, 2013, 7:16pm UTC](https://boards.straightdope.com/t/javascript-math-floor-var-versus-var-0/675592/7 "2013-12-05T19:16:51Z")

</div>

It’s safer to use Math.floor, it produces far more intelligible code, it gives the reader a better understanding of the intent of the code, and optimizing javascript code by avoiding a call to Math.floor is like ordering a Diet Coke with your ice cream sundae.

---

<div class="post-metadata">

**Author:** ![Chronos](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/chronos/32/134_2.png) [@Chronos](https://boards.straightdope.com/u/Chronos)\
**Post date:** [December 5, 2013, 7:17pm UTC](https://boards.straightdope.com/t/javascript-math-floor-var-versus-var-0/675592/8 "2013-12-05T19:17:20Z")

</div>

Even if it always worked, it’d still be a bad idea. It’s reaching down into a lower level of abstraction. The whole point of a programming language is that you shouldn’t have to do that-- What happens when someone writes a new implementation that interacts with that lower level in a different way?

And even if that doesn’t happen, either, it makes the code harder to understand for no good reason: Even if it really were the most efficient way to do it, it’s not your responsibility to recognize that-- It’s the responsibility of whoever wrote the floor() function. Trust that he was doing his job right, and just use the tool designed for the purpose.

---

<div class="post-metadata">

**Author:** ![Zyanthia](https://avatars.discourse-cdn.com/v4/letter/z/d6d6ee/32.png) [@Zyanthia](https://boards.straightdope.com/u/Zyanthia)\
**Post date:** [December 5, 2013, 7:51pm UTC](https://boards.straightdope.com/t/javascript-math-floor-var-versus-var-0/675592/9 "2013-12-05T19:51:47Z")

</div>

Okay, for fun here’s the completed version. I made it a prototype function just because that’s what I was trying to teach myself at the time. Thanks for all your input 🙂

```auto

// Create a function to shuffle the elements of an array
if (!Array.prototype.shuffle){
   Array.prototype.shuffle = function (){
      var eltToSwap = this.length, temp, idx;
      while (eltToSwap--){
      idx = Math.floor((Math.random() * eltToSwap));
         temp = this[eltToSwap];
         this[eltToSwap] = this[idx];
         this[idx] = temp;
      }
   };
}

```

and a test web page that scrambles the words every second:

```auto

<!DOCTYPE html>
<html>
  <head>
   <base href="file:///c:/xxxxxx/program/web/" target="_blank" />
   <meta name="description" content="Test Javascript" />
   <script src="JavaScriptLibrary.js"></script>
   <script>
      var a = ["This", "Is", "A", "Test"];
   </script>
  </head>

  <body>
   <div id="main">
     <div id="title">WEB PAGE</div>
      <p><hr width="50%" align="left" />This is a Sentence</p>

      <!-- This below paragraph should not be displayed -->
      <p hidden="hidden">This paragraph is hidden</p>
    </div>

    <script>
       var randomWords = setInterval (function (){
           var d=document.getElementById("title");
	   a.shuffle();
	   d.innerHTML=a;
	}, 1000);
    </script>

  </body>
</html>

```

---

<div class="post-metadata">

**Author:** ![Senegoid](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/senegoid/32/6606_2.png) [@Senegoid](https://boards.straightdope.com/u/Senegoid)\
**Post date:** [December 6, 2013, 9:13am UTC](https://boards.straightdope.com/t/javascript-math-floor-var-versus-var-0/675592/10 "2013-12-06T09:13:40Z")

</div>

> [@Chronos](#):
>
> Even if it always worked, it’d still be a bad idea. It’s reaching down into a lower level of abstraction. The whole point of a programming language is that you shouldn’t have to do that-- What happens when someone writes a new implementation that interacts with that lower level in a different way?

Abstractions are ideally supposed to interface with lower-level abstractions in specific well-defined ways such that the lower-level abstraction never shows through. In practice, this seems difficult to do, in which case the upper-level abstraction is called _leaky._

Joel Spolsky has an essay on the subject: [The Law of Leaky Abstractions](http://www.joelonsoftware.com/articles/leakyabstractions.html) (November 2002) in which he argues that _all_ non-trivial abstractions are leaky, and gives various examples.

His basic thesis is that abstractions never seem to quite simplify the programmer’s life as much as they were meant to, because there are always problems with them that the program has to allow for and program around (involving implementation details and problems with lower-level abstractions), which are the very things the programmer was supposed to not even have to know about.

---

<div class="post-metadata">

**Author:** ![bup](https://avatars.discourse-cdn.com/v4/letter/b/6bbea6/32.png) [@bup](https://boards.straightdope.com/u/bup)\
**Post date:** [December 6, 2013, 8:30pm UTC](https://boards.straightdope.com/t/javascript-math-floor-var-versus-var-0/675592/11 "2013-12-06T20:30:17Z")

</div>

Negative numbers would also produce different results.

---

<div class="post-metadata">

**Author:** ![Dr.Strangelove](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/dr.strangelove/32/6613_2.png) [@Dr.Strangelove](https://boards.straightdope.com/u/Dr.Strangelove)\
**Post date:** [December 6, 2013, 10:52pm UTC](https://boards.straightdope.com/t/javascript-math-floor-var-versus-var-0/675592/12 "2013-12-06T22:52:47Z")

</div>

> [@Chronos](#):
>
> And even if that doesn’t happen, either, it makes the code harder to understand for no good reason: Even if it really were the most efficient way to do it, it’s not your responsibility to recognize that-- It’s the responsibility of whoever wrote the floor() function. Trust that he was doing his job right, and just use the tool designed for the purpose.

Sometimes you need performance at all costs, though. Knuth was correct in that “premature optimization is the root of all evil”, but he didn’t use the word “premature” for no reason.

The first question here is if it’s actually faster. I used [jsperf.com](http://jsperf.com) to do a [quick comparison](http://jsperf.com/float-to-int-3), and it appears that there is some benefit–about 20% as reported, though a bit higher in reality since there’s a certain amount of loop overhead.

A while back I was writing some Javascript to do some heavy-duty signal processing. It’s about the worst possible language for this task, but it’s the only language that you can run on any device (from cell phone to desktop) with no installation required. I used several tricks but it was still too slow for portable devices. Having a few more tricks up my sleeve might have made it practical.

---

<div class="post-metadata">

**Author:** ![Chronos](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/chronos/32/134_2.png) [@Chronos](https://boards.straightdope.com/u/Chronos)\
**Post date:** [December 7, 2013, 5:42pm UTC](https://boards.straightdope.com/t/javascript-math-floor-var-versus-var-0/675592/13 "2013-12-07T17:42:51Z")

</div>

If it really is more efficient and the existing floor() function wasn’t written that way to begin with, then the proper course of action would be for you to be the guy who wrote the floor() function. That is, you’d write a new function that uses the trick, and then call that function whenever you need to use it, and hope that the compiler you’re using unfolds the necessary overhead out of the function call.

For a real-world example where all of this really is relevant: One operation often encountered in 3D graphics is the inverse square root: That is, given x, find 1/sqrt(x). Now, the naive way of doing this is fairly slow, but computer games absolutely must be fast. So it was worthwhile to find a quicker way to do it, at all costs, and in the early 90s, someone (precisely who is lost to history) figured out [a really clever but mostly incomprehensible trick](http://en.wikipedia.org/wiki/Fast_inverse_square_root) to do it.

But that person (whoever it was) didn’t just use that trick directly in the code everywhere it was needed. Instead, he wrote a function called Q\_rsqrt(), and hid all of the ugliness inside that function. A person reading most of the code, then, would just say “Oh, that’s the inverse square root function”, and not worry about how it works. Only if someone actually delved in to the function itself would they have to worry about the details, and if they did so, they would discover that even the original programmer thought it bizarre, with comments like “// evil floating point bit level hacking” and “// what the fuck?”.

It’s important to note, by the way, that “shuffle off the work to that poor sap writing the function” is a good idea even if you yourself are that poor sap. Even if you can think of all of the details, you can’t think of them all at once. Hiding them away in separate functions allows you to think about things only when necessary.

---

<div class="post-metadata">

**Author:** ![Dr.Strangelove](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/dr.strangelove/32/6613_2.png) [@Dr.Strangelove](https://boards.straightdope.com/u/Dr.Strangelove)\
**Post date:** [December 7, 2013, 11:04pm UTC](https://boards.straightdope.com/t/javascript-math-floor-var-versus-var-0/675592/14 "2013-12-07T23:04:14Z")

</div>

> [@Chronos](#):
>
> That is, you’d write a new function that uses the trick, and then call that function whenever you need to use it, and hope that the compiler you’re using unfolds the necessary overhead out of the function call.

I would agree, except that Javascript (on Chrome, IE, and Firefox) does not in fact fully compile away its high function call overhead, as you can see from [this](http://jsperf.com/float-to-int-4) comparison (oddly, Firefox seems to “semi-inline” the function, because Math.floor is actually faster than the local function).

Languages which are are perf oriented tend to have features that allow better expression of these kinds of hacks, such as a preprocessor, function inlining, and templates. Javascript has none of that, unfortunately. Ideally, one would choose a language better suited to the task, but there isn’t one (at least not until Google’s NaCl improves!).

Hacks like this are definitely the last thing you should do, but that doesn’t mean they should _never_ be done. Just… very sparingly. Algorithmic improvements come first, as always.

---

<div class="post-metadata">

**Author:** ![Learjeff](https://avatars.discourse-cdn.com/v4/letter/l/94ad74/32.png) [@Learjeff](https://boards.straightdope.com/u/Learjeff)\
**Post date:** [December 8, 2013, 4:28pm UTC](https://boards.straightdope.com/t/javascript-math-floor-var-versus-var-0/675592/15 "2013-12-08T16:28:11Z")

</div>

> [@Zyanthia](#):
>
> Is doing a bitwise or on a number cheaper than calling the Math.floor function? Is it doing something else that I’m not seeing?

There’s something you’re not seeing, because this isn’t the correct question.

The correct question is “is converting to integer and doing a bitwise OR faster than floor?”

Folks above covered quite well the issue of whether it’s better, regardless of whether it’s faster. The general rule is “do what’s better unless it _has_ to be faster”. For the vast majority of programming projects, only a small portion needs to be optimized. That is, most optimizations won’t provide a meaningful return on investment; only the code that is in the tightest loops needs to be optimized. There are lots of caveats, of course.

Sidestepping that, though, the question remains, which is faster? You’d have to test to find out. My suspicion is that they’d be pretty close.

Finally, I’m not a javascript guru, but if the language doesn’t have integers, then my guess is I didn’t quite get the question right, above. If so, it would be:

Which is faster: floor, or converting to integer, doing bitwise OR, and then converting back to float?

There may be cases when the javascript interpreter can avoid the latter conversion, though.

My guess is that floor is about the same cost as converting to integer, but I’ve never implemented it so I can’t say.