We Keep Coding

Why is this unsigned unshift assignment operator used in the find polyfill? [duplicate]

I was looking at code from Mozilla that add a filter method to Array and it had a line of code that confused me.
var len = this.length >>> 0;
I have never seen >>> used in JavaScript before. What is it and what does it do?

It doesn't just convert non-Numbers to Number, it converts them to Numbers that can be expressed as 32-bit unsigned ints.
Although JavaScript's Numbers are double-precision floats(*), the bitwise operators (<<, >>, &, | and ~) are defined in terms of operations on 32-bit integers. Doing a bitwise operation converts the number to a 32-bit signed int, losing any fractions and higher-place bits than 32, before doing the calculation and then converting back to Number.
So doing a bitwise operation with no actual effect, like a rightward-shift of 0 bits >>0, is a quick way to round a number and ensure it is in the 32-bit int range. Additionally, the triple >>> operator, after doing its unsigned operation, converts the results of its calculation to Number as an unsigned integer rather than the signed integer the others do, so it can be used to convert negatives to the 32-bit-two's-complement version as a large Number. Using >>>0 ensures you've got an integer between 0 and 0xFFFFFFFF.
In this case this is useful because ECMAScript defines Array indexes in terms of 32 bit unsigned ints. So if you're trying to implement array.filter in a way that exactly duplicates what the ECMAScript Fifth Edition standard says, you would cast the number to 32-bit unsigned int like this.
In reality there's little practical need for this as hopefully people aren't going to be setting array.length to 0.5, -1, 1e21 or 'LEMONS'.
Summary:
1>>>0 === 1
-1>>>0 === 0xFFFFFFFF -1>>0 === -1
1.7>>>0 === 1
0x100000002>>>0 === 2
1e21>>>0 === 0xDEA00000 1e21>>0 === -0x21600000
Infinity>>>0 === 0
NaN>>>0 === 0
null>>>0 === 0
'1'>>>0 === 1
'x'>>>0 === 0
Object>>>0 === 0
(*: well, they're defined as behaving like floats. It wouldn't surprise me if some JavaScript engine actually used ints when it could, for performance reasons. But that would be an implementation detail you wouldn't get to take any advantage of.)

The unsigned right shift operator is used in the all the array extra's method implementations of Mozilla, to ensure that the length property is a unsigned 32-bit integer.
The length property of array objects is described in the specification as:
Every Array object has a length property whose value is always a nonnegative integer less than 232.
This operator is the shortest way to achieve it, internally array methods use the ToUint32 operation, but that method is not accessible and exist on the specification for implementation purposes.
The Mozilla array extras implementations try to be ECMAScript 5 compliant, look at the description of the Array.prototype.indexOf method (§ 15.4.4.14):
1. Let O be the result of calling ToObject passing the this value
as the argument.
2. Let lenValue be the result of calling the [[Get]] internal method of O with
the argument "length".
3. Let len be ToUint32(lenValue).
....
As you can see, they just want to reproduce the behavior of the ToUint32 method to comply with the ES5 spec on an ES3 implementation, and as I said before, the unsigned right shift operator is the easiest way.

That is the unsigned right bit shift operator. The difference between this and the signed right bit shift operator, is that the unsigned right bit shift operator (>>>) fills with zeroes from the left, and the signed right bit shift operator (>>) fills with the sign bit, thus preserving the sign of the numerical value when shifted.

Driis has sufficiently explained what the operator is and what it does. Here's the meaning behind it/why it was used:
Shifting any direction by 0 does returns the original number and will cast null to 0. It seems that the example code that you are looking at is using this.length >>> 0 to ensure that len is numeric even if this.length is not defined.
For many people, bitwise operations are unclear (and Douglas Crockford/jslint suggests against using such things). It doesn't mean that its wrong to do, but more favorable and familiar methods exist to make code more readable. A more clear way to ensure that len is 0 is either of the following two methods.
// Cast this.length to a number
var len = +this.length;
or
// Cast this.length to a number, or use 0 if this.length is
// NaN/undefined (evaluates to false)
var len = +this.length || 0;

>>> is the unsigned right shift operator (see p. 76 of the JavaScript 1.5 specification), as opposed to the >>, the signed right shift operator.
>>> changes the results of shifting negative numbers because it does not preserve the sign bit when shifting. The consequences of this is can be understood by example, from an interpretter:
$ 1 >> 0
1
$ 0 >> 0
0
$ -1 >> 0
-1
$ 1 >>> 0
1
$ 0 >>> 0
0
$ -1 >>> 0
4294967295
$(-1 >>> 0).toString(16)
"ffffffff"
$ "cabbage" >>> 0
0
So what is probably intended to be done here is to get the length, or 0 if the length is undefined or not an integer, as per the "cabbage" example above. I think in this case it is safe to assume that this.length will never be < 0. Nevertheless, I would argue that this example is a nasty hack, for two reasons:
The behavior of <<< when using negative numbers, a side-effect probably not intended (or likely to occur) in the example above.
The intention of the code is not obvious, as the existence of this question verifies.
Best practice is probably to use something more readable unless performance is absolutely critical:
isNaN(parseInt(foo)) ? 0 : parseInt(foo)

Two reasons:
The result of >>> is an "integral"
undefined >>> 0 = 0 (since JS will try and coerce the LFS to numeric context, this will work for "foo" >>> 0, etc. as well)
Remember that numbers in JS have an internal-representation of double.
It's just a "quick" way of basic input sanity for length.
However, -1 >>> 0 (oops, likely not a desired length!)

Sample Java Code below explains well:
int x = 64;
System.out.println("x >>> 3 = " + (x >>> 3));
System.out.println("x >> 3 = " + (x >> 3));
System.out.println(Integer.toBinaryString(x >>> 3));
System.out.println(Integer.toBinaryString(x >> 3));
Output is the following:
x >>> 3 = 536870904
x >> 3 = -8
11111111111111111111111111000
11111111111111111111111111111000

In JavaScript, why is (-1).toString and (-1 >>> 0).toString identical, yet they give different results?

The background information is: in JavaScript, there is no different between float and int. There is only Number and it is IEEE 754 standard. So there shouldn't be any "float" vs "int" in JavaScript. Even when the number is treated as a 32-bit integer when you do bitwise operations, the result should be Number. In order words, there should not be a type which is "integer".
But at least on Google Chrome and on Node.js:
Comparing 2 functions (function as an object):
(-1).toString === (-1 >>> 0).toString // => true
So they are the same, identical function object. In fact, the "wrapped objects" are of the same type:
(-1).__proto__ === (-1 >>> 0).__proto__ // => true
But when you use
(-1).toString(2) // => "-1"
and
(-1 >>> 0).toString(2) // => "11111111111111111111111111111111"
It seems like the object wrapper (the wrapper that make the primitive type 1 to become an object), will create the two objects as having the same object type (as shown by the __proto__), but somehow, it thinks of itself not as the same type, one as a float, and one as 32-bit integer. Why is that?
According to the usual general principles of OOP Interface, if two objects are of the same type (of the identical type, as shown by __proto__ being identical), shouldn't they give the same, identical result when responding to the same "message", which is toString(2)?

Both -1, -1>>>0 are of type 'number'
You can check it from typeof -1 and typeof -1>>>0 respectively.
So, both of their methods .toString are literally Number.prototype.toString, identically.
Which means all following refers to the same Number.prototype.toString.
(1).toString // Number.prototype.toString
(2).toString // Number.prototype.toString
(1.55555).toString // Number.prototype.toString
(Infinity).toString // Number.prototype.toString (Yes, typeof Infinity is Number)
(NaN).toString // Number.prototype.toString (typeof NaN is Number)
(1>>0).toString // Also Number.prototype.toString
That's why comparison results of their method .toString yields true. They are all Number.prototype.toString.
It derives the same Number.prototype.toString doesn't mean it always yield the same output.
The method takes the different input value will definitely return you different resultant value.
To illustrate the effect. Calling this.
(-1).toString(2);
Is identical to:
Number.prototype.toString.apply(-1,[2]); // Yields -1
Also, calling this:
(-1>>>0).toString(2);
Is identical to:
Number.prototype.toString.apply(-1>>>0,[2]); // Yields 11111111111111111111111111111111
Now you noticed how they behave.

This is become you are mixing up things a bit...
Why is this true?
(-1).toString === (-1 >>> 0).toString // => true
Because both are Number and Number.toString === Number.toString.
I suppose that what you meant to do was:
(-1).toString() === (-1 >>> 0).toString() // => false!!!
Notice the extra parenthesis?
In terms of number handling, as Frédéric Hamidi pointed out, the shift operations (and the bitwise operations) convert the Number to a 32 bit integer, do the math, and then convert that back to a Number. You could write the following in a typed language such as a C++ to make it clear:
double d = -1;
uint32_t u = static_cast<uint32_t>(d)
u >>= 1
d = static_cast<double>(u)
The static_cast<>() are not required, the language would automatically do those for you, but I put them there for clarity.
Important point, the >>> operator assumes that the input integer is unsigned (hence the uint32_t) You could think that a signed integer should be used as an intermediate, like this:
double d = -1;
int32_t i = static_cast<int32_t>(d)
uint32_t u = static_cast<uint32_t>(i);
u >>= 1
i = static_cast<int32_t>(u)
d = static_cast<double>(i)
However, this is not the case. JavaScript really converts the unsigned integers back to a Number (double). If you look at the output of (-1 >>> 0).toString(), you will notice that it is not -1 anymore, instead it is 4294967295. The largest unsigned number that can fit in 32 bits (1 << 32 - 1.)
Now, I suppose you understand the unsigned shift problem which means that the sign bit is lost. On 8 bits it would look like this with a 1 bit shift:
1111 1111 >> 1 = 1111 1111
1111 1111 >>> 1 = 0111 1111 (bit 7 becomes zero)
In your case, though, you used a 0 bit shift, so the value doesn't get shifted at all:
1111 1111 >> 0 = 1111 1111 signed, so it is -1
1111 1111 >>> 0 = 1111 1111 unsigned, so it is 255
but in the second case the integer becomes unsigned. Since there is enough room in the double mantissa to save the uint32_t as is, you do not lose the precision (an interesting JavaScript trick! in C++ you would certainly expect to get the sign back when you save the uint32_t in an int32_t... if you think like a C/C++ programmer.)
P.S. your second test of the __proto__ has the same issue. You are comparing references, not the content. In JavaScript, you have this concept of deep compare of arrays and objects (and it can become hairy). __proto__ is an object and you just compared the references. That being said, since both are Numbers, a deep compare would also return true.

Flooring numbers in JavaScript: ~~n, n|0 or Math.floor(n)?

I've recently discovered some other ways to remove the fractional part of numeric values in JavaScript other than Math.floor(n), specifically the double bitwise NOT operator ~~n and performing a bitwise or with 0 n|0.
I'd like to know what are the difference between these approaches and what the different scenarios are where one method is recommended over another.

The operands of all bitwise operators are converted to signed 32-bit integers:
Math.floor(2147483648) // 2147483648
2147483648 | 0 // 2147483648
~~2147483648 // 2147483648
Math.floor(2147483649) // 2147483649
2147483649 | 0 // -2147483647
~~2147483649 // -2147483647
So use Math.floor();

Be clear to the next person looking at your code and use Math.floor().
The performance gain of 1%-40% isn't really worth it, so don't make your code confusing and hard to maintain.

(I entirely agree with josh's answer: favor clear maintainable code.)
Here is an explanation on the other bit-wise approaches:
The bit-wise operators work because they only operator on 32-bit (signed) integers but numbers in JavaScript are all IEEE-754 values. Thus, there is an internal conversion (truncation, not floor!) that happens to operands for bit-wise operators.
The applied bit-wise operation (e.g. n<<0, ~~n or n|0) then acts as an identity function which "does nothing" to the converted values: that is, all of these approaches rely on the same conversion applied to bit-wise operands.
Try n as a negative number or a value outside of [-231, 231-1]:
(-1.23|0) // -1
Math.floor(-1.23) // -2
var x = Math.pow(2, 40) + .5
x|0 // 0
Math.floor(x) // 1099511627776
Happy coding.

JavaScript triple greater than

I saw this syntax on another StackOverflow post and was curious as to what it does:
var len = this.length >>> 0;
What does >>> imply?

Ignoring its intended meaning, this is most likely where you'll see it used:
>>> 0 is unique in that it is the only operator that will convert any type to a positive integer:
"string" >>> 0 == 0
(function() { }) >>> 0 == 0
[1, 2, 3] >>> 0 == 0
Math.PI >>> 0 == 3
In your example, var len = this.length >>> 0, this is a way of getting an integer length to use to iterate over this, whatever type this.length may be.
Similarly, ~~x can be used to convert any variable into a signed integer.

That's an unsigned right shift operator. Interestingly, it is the only bitwise operator that is unsigned in JavaScript.
The >>> operator shifts the bits of expression1 right by the number of
bits specified in expression2. Zeroes are filled in from the left.
Digits shifted off the right are discarded.

That operator is a logical right shift. Here the number is shifted 0 bits. A shift of zero bits mathemetically should have no effect.
But here it is used to convert the value to an unsigned 32 bit integer.

>>> is a bit-wise operator, zero-fill right shift.
I think the only effect of >>> 0 on a positive number is to round down to the nearest integer, same as Math.floor(). I don't see why this would be necessary in your example, as generally a .length property (e.g. of an Array) would be an integer already.
I've also seen the slightly shorter ~~ used in the same way: ~~9.5 == 9; // true.

What good does zero-fill bit-shifting by 0 do? (a >>> 0) [duplicate]

I was looking at code from Mozilla that add a filter method to Array and it had a line of code that confused me.
var len = this.length >>> 0;
I have never seen >>> used in JavaScript before. What is it and what does it do?

It doesn't just convert non-Numbers to Number, it converts them to Numbers that can be expressed as 32-bit unsigned ints.
Although JavaScript's Numbers are double-precision floats(*), the bitwise operators (<<, >>, &, | and ~) are defined in terms of operations on 32-bit integers. Doing a bitwise operation converts the number to a 32-bit signed int, losing any fractions and higher-place bits than 32, before doing the calculation and then converting back to Number.
So doing a bitwise operation with no actual effect, like a rightward-shift of 0 bits >>0, is a quick way to round a number and ensure it is in the 32-bit int range. Additionally, the triple >>> operator, after doing its unsigned operation, converts the results of its calculation to Number as an unsigned integer rather than the signed integer the others do, so it can be used to convert negatives to the 32-bit-two's-complement version as a large Number. Using >>>0 ensures you've got an integer between 0 and 0xFFFFFFFF.
In this case this is useful because ECMAScript defines Array indexes in terms of 32 bit unsigned ints. So if you're trying to implement array.filter in a way that exactly duplicates what the ECMAScript Fifth Edition standard says, you would cast the number to 32-bit unsigned int like this.
In reality there's little practical need for this as hopefully people aren't going to be setting array.length to 0.5, -1, 1e21 or 'LEMONS'.
Summary:
1>>>0 === 1
-1>>>0 === 0xFFFFFFFF -1>>0 === -1
1.7>>>0 === 1
0x100000002>>>0 === 2
1e21>>>0 === 0xDEA00000 1e21>>0 === -0x21600000
Infinity>>>0 === 0
NaN>>>0 === 0
null>>>0 === 0
'1'>>>0 === 1
'x'>>>0 === 0
Object>>>0 === 0
(*: well, they're defined as behaving like floats. It wouldn't surprise me if some JavaScript engine actually used ints when it could, for performance reasons. But that would be an implementation detail you wouldn't get to take any advantage of.)

The unsigned right shift operator is used in the all the array extra's method implementations of Mozilla, to ensure that the length property is a unsigned 32-bit integer.
The length property of array objects is described in the specification as:
Every Array object has a length property whose value is always a nonnegative integer less than 232.
This operator is the shortest way to achieve it, internally array methods use the ToUint32 operation, but that method is not accessible and exist on the specification for implementation purposes.
The Mozilla array extras implementations try to be ECMAScript 5 compliant, look at the description of the Array.prototype.indexOf method (§ 15.4.4.14):
1. Let O be the result of calling ToObject passing the this value
as the argument.
2. Let lenValue be the result of calling the [[Get]] internal method of O with
the argument "length".
3. Let len be ToUint32(lenValue).
....
As you can see, they just want to reproduce the behavior of the ToUint32 method to comply with the ES5 spec on an ES3 implementation, and as I said before, the unsigned right shift operator is the easiest way.

That is the unsigned right bit shift operator. The difference between this and the signed right bit shift operator, is that the unsigned right bit shift operator (>>>) fills with zeroes from the left, and the signed right bit shift operator (>>) fills with the sign bit, thus preserving the sign of the numerical value when shifted.

Driis has sufficiently explained what the operator is and what it does. Here's the meaning behind it/why it was used:
Shifting any direction by 0 does returns the original number and will cast null to 0. It seems that the example code that you are looking at is using this.length >>> 0 to ensure that len is numeric even if this.length is not defined.
For many people, bitwise operations are unclear (and Douglas Crockford/jslint suggests against using such things). It doesn't mean that its wrong to do, but more favorable and familiar methods exist to make code more readable. A more clear way to ensure that len is 0 is either of the following two methods.
// Cast this.length to a number
var len = +this.length;
or
// Cast this.length to a number, or use 0 if this.length is
// NaN/undefined (evaluates to false)
var len = +this.length || 0;

>>> is the unsigned right shift operator (see p. 76 of the JavaScript 1.5 specification), as opposed to the >>, the signed right shift operator.
>>> changes the results of shifting negative numbers because it does not preserve the sign bit when shifting. The consequences of this is can be understood by example, from an interpretter:
$ 1 >> 0
1
$ 0 >> 0
0
$ -1 >> 0
-1
$ 1 >>> 0
1
$ 0 >>> 0
0
$ -1 >>> 0
4294967295
$(-1 >>> 0).toString(16)
"ffffffff"
$ "cabbage" >>> 0
0
So what is probably intended to be done here is to get the length, or 0 if the length is undefined or not an integer, as per the "cabbage" example above. I think in this case it is safe to assume that this.length will never be < 0. Nevertheless, I would argue that this example is a nasty hack, for two reasons:
The behavior of <<< when using negative numbers, a side-effect probably not intended (or likely to occur) in the example above.
The intention of the code is not obvious, as the existence of this question verifies.
Best practice is probably to use something more readable unless performance is absolutely critical:
isNaN(parseInt(foo)) ? 0 : parseInt(foo)

Two reasons:
The result of >>> is an "integral"
undefined >>> 0 = 0 (since JS will try and coerce the LFS to numeric context, this will work for "foo" >>> 0, etc. as well)
Remember that numbers in JS have an internal-representation of double.
It's just a "quick" way of basic input sanity for length.
However, -1 >>> 0 (oops, likely not a desired length!)

Sample Java Code below explains well:
int x = 64;
System.out.println("x >>> 3 = " + (x >>> 3));
System.out.println("x >> 3 = " + (x >> 3));
System.out.println(Integer.toBinaryString(x >>> 3));
System.out.println(Integer.toBinaryString(x >> 3));
Output is the following:
x >>> 3 = 536870904
x >> 3 = -8
11111111111111111111111111000
11111111111111111111111111111000