Why not use bit operators in JavaScript?

If your first programming language is not JavaScript, it's C + + or Java, then you probably don't like the number type of JavaScript at first. The number types in JavaScript are not distinguishable from what int,float,double,decimal. Cough, of course, I said in ES6 before the JS, in the new standard of ES6, like Int8array such a new data type. But this is not the focus of this article, we will not talk about it. This article will focus more on the numeric type of JS and its bitwise operators, while more information about the wrapper object number can be seen in the JavaScript design pattern of the red translation

The nature of numeric types

In fact, the nature of the numeric type of JavaScript is a double 64-bit floating-point number based on the IEEE 754 standard . According to the standard, its data structure is shown in this way: the 1-bit sign bit, the 11-bit exponent part and the 52-bit tail part component.

In floating-point numbers, a number is usually represented as:

( -1) ^signxmantissax2^exponent

In order to normalize the mantissa, and to maximize the accuracy, it is necessary to put the mantissa in[1,2)the exact interval, so that the leading 1 can be omitted. Like what:

11.101x2³ = 1.1101x2⁴ 0.1001x2⁵ = 1.001x2< Sup>4</sup>

And the standard specifies that the exponent section uses 0X3FF as an offset, and there is a general formula for the double-precision floating-point number:

( -1) ^signx1.mantissax2^{exponent-0x3ff}

Some examples should help you understand this formula:

3ff0 0000 0000 0000 = 1
c000 0000 0000 0000 = -2
3fd5 5555 5555 5555 ~ 1/3
0000 0000 0000 0000 = 0
8000 0000 0000 0000 = -0
7ff0 0000 0000 0000 = infinity (1/0)
fff0 0000 0000 0000 = negative infinity (1 / -0)
7fef ffff ffff ffff ~ 1.7976931348623157 x 10 ^ 308 (= Number.MAX_VALUE)
433f ffff ffff ffff = 2 ^ 53-1 (= Number.MAX_SAFE_INTEGER)
c33f ffff ffff ffff = -2 ^ 53 + 1 (= Number.MIN_SAFE_INTEGER)
Thanks to the one-digit "1" omitted from the mantissa, the maximum safe integer represented by a double-precision floating-point number is between -2 <sup> 53 </ sup> +1 and 2 <sup> 53 </ sup> -1 , So if you only use the number type in JavaScript for some integer operations, then you can also approximate this number type as a 53-bit integer.

Bit operator that makes people love and hate
Students familiar with C or C ++ must be familiar with bitwise operators. The most important application of bit operators is probably as a flag and a mask. This is a clever way to save storage space. When the size of the memory was calculated in KB, each additional variable is an extra cost. The mask using bit operators alleviates this problem to a great extent:

#define LOG_ERRORS 1 // 0001
#define LOG_WARNINGS 2 // 0010
#define LOG_NOTICES 4 // 0100
#define LOG_INCOMING 8 // 1000

unsigned char flags;

flags = LOG_ERRORS; // 0001
flags = LOG_ERRORS | LOG_WARNINGS | LOG_INCOMING; // 1011
Because the flag bit generally only needs 1 bit to be saved, there is no need to define a variable for each flag bit. So in this way, only one variable is used, but a lot of information can be saved-unsigned char can save 8 flag bits, and unsigned int can mean 32 flag bits at the same time.

It's a pity that bitwise operators behave strangely in JavaScript because JavaScript doesn't have integers in the true sense. Look at the results of the following code:

var a, b;

a = 2e9; // 2000000000
a << 1; // -294967296

// fxck! I just want to pretend to use a left shift to a * 2, but what the hell is the result! ! !

a = parseInt (‘100000000’, 16); // 4294967296
b = parseInt (‘1111’, 2); // 15
a | b; // 15

// Ahhh, for my hair a doesn't work at all, JavaScript is really a monstrous language! ! !
Well, although I said that everyone can approximate that the number type of JS can represent a 53-bit integer. But in fact, bit operators don't think so. In the ECMAScript® Language Specification, bit operators are described as follows:

The production A: A @ B, where @ is one of the bitwise operators in the productions above, is evaluated as follows:

Let lref be the result of evaluating A.
Let lval be GetValue (lref).
Let rref be the result of evaluating B.
Let rval be GetValue (rref).
Let lnum be ToInt32 (lval).
Let rnum be ToInt32 (rval).
Return the result of applying the bitwise operator @ to lnum and rnum. The result is a signed 32 bit integer.
It should be noted that in steps 5 and 6, according to the ES standard, the two values that need to be calculated will be converted to signed 32-bit integers first. Therefore, integers greater than 32 bits will be truncated, and the decimal part will be directly discarded.

And conversely, under what circumstances do we need to use the in place operator? Use left shift instead of multiplication of powers of 2? Naive, when you encounter a problem like the first example, you will be crazy. And whether the left-shift operation on a floating-point number is more efficient than directly multiplying by 2 is also a question that is debatable.

What about flags? First of all, the current memory size is not worth us to reduce the storage space by reducing a few variables; secondly, the use of flags will greatly reduce the readability of the code. Furthermore, there are too few places to use bit operators in JavaScript. If you insist on using bit operators, people who maintain this code in the future are not familiar with the pits of bit operators in JS, which will also cause disadvantages. influences.

So, my advice to everyone is to try not to use bitwise operators in JavaScript.

Why not use bitwise operators in JavaScript?