JavaScript Triple Greater Than

JavaScript triple greater than

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.

Javascript equality triple equals but what about greater than and less than?

No, there's no need for such operators. The type checking done for those relational operators is different than for equality and inequality. (edit — perhaps it's a little strong to say that there's "no need"; that's true only because JavaScript deems it so :-)

Specifically, the > and < and >= and <= operators all operate either on two numeric values, or two strings, preferring numeric values. That is, if one value is a number, then the other is treated as a number. If a non-number can't be cleanly converted to a number (that is, if it ends up as NaN), then the result of the comparison is undefined. (That's a little problematic, because undefined will look like false in the context of an if statement.)

If both values are strings, then a collating-order string comparison is performed instead.

If you think about it, these comparisons don't make any sense for object instances; what does it mean for an object to be "greater than" another? I suppose, perhaps, that this means that if you're finding yourself with values of variant types being compared like this, and that's causing problems, then yes you have to detect the situation yourself. It seems to me that it would be good to work upstream and think about whether there's something fishy about the code that's leading to such a situation.

Javascript triple greater than in PHP

function urshift($n, $s) {
    return ($n >= 0) ? ($n >> $s) :
        (($n & 0x7fffffff) >> $s) | 
            (0x40000000 >> ($s - 1));
}  

Untested, credit goes here.

What is operator in JS?

>>> is a right shift without sign extension

If you use the >> operator on a negative number, the result will also be negative because the original sign bit is copied into all of the new bits. With >>> a zero will be copied in instead.

In this particular case it's just being used as a way to restrict the length field to an unsigned 31 bit integer, or in other words to "cast" Javascript's native IEEE754 "double" number into an integer.

Why doesn't JavaScript have strict greater/less than comparison operators?

I can only guess-

If

a === b is false, then

a !== b is true. always.

But, this implication wouldn't hold for <==

If

x <== 20 is false, we cannot infer the result of
x >== 20 because it might have been false due to type check, or the relation check.

I think that's slightly confusing, although there's plenty of things in the language that are much worse (type coercion in general, to name one).

However, I think a strict < or > would behave consistently.

Why use triple-equal (===) in TypeScript?

Imagine you're designing TypeScript from scratch. Essentially, you're trying to optimize for making safer code easier to write (TypeScript design goal 1) with a few caveats which prevent you from doing everything you'd like.

JavaScript compatibility (TypeScript design goal 7)

JavaScript should be valid Typescript with no changes.

CoffeeScript makes no guarantees regarding this, so it can convert all instances of == to === and simply tell users don't rely on =='s behavior. TypeScript cannot redefine == without breaking all JavaScript code that relies on its behavior (despite this having sad implications for 3).

This also implies that TypeScript cannot change the functionality of === to, for example, check the types of both operands at compile time and reject programs comparing variables of different types.

Further, compatibility is not limited to simply JavaScript programs; breaking compatibility also affects JavaScript programmers by breaking their assumptions about the differences between == and ===. See TypeScript non-goal number 7:

Introduce behaviour that is likely to surprise users. Instead have due consideration for patterns adopted by other commonly-used languages.

JavaScript as the target of compilation (TypeScript design goal 4)

All TypeScript must be representable in JavaScript. Further, it should be idiomatic JavaScript where possible.

Really though, the TypeScript compiler could use methods returning booleans for all comparisons, doing away with == and === entirely. This might even be safer for users: define a type-safe equality method on each TypeScript type (rather like C++ operator==, just without overloading).

So there is a workaround (for users comparing classes). unknown or any variables can have their types narrowed before using the type-safe equality method.

Which to prefer

Use === everywhere you would in JavaScript. This has the advantage of avoiding the pitfalls common to ==, and doesn't require you to maintain an additional method. The output of the TypeScript compiler will be close to idiomatic JavaScript. Using == has very much the same pitfalls as JavaScript, particularly when you have any, [], or {} involved. As an exception, using == null to check for null or undefined may save headaches if library code is inconsistent.

A method for reference equality (behavior like === for classes) could be confused with a deep/value recursive equality check. Furthermore, === is widely used in TypeScript, and making your code fall in line with conventions is usually more important than any small bit of type safety.

In Javascript, what's the point of offset = 0 assignment?

The only purpose for shifting a value zero steps would be to force the conversion to a 32-bit integer and back.

As the statement before that checks that it's a number and that the number has no fractional part, it serves no purpose in that code.

For a negative value it would convert it to the unsigned two's complement of the value, e.g. from -1 to 4294967295. As that is outside the size of the buffer anyway, it would be caught by the check in the next statement.

If you keep the shift, then you don't need the check offset < 0 in the next statement, as that can never happen.

---

Related Topics