Чтобы быть в безопасности

var MAX_INT = 4294967295;

Рассуждение

Я подумал, что проявлю ум и найду значение, при котором x + 1 === x с более прагматичным подходом.

Моя машина может считать только 10 миллионов в секунду или около того ... так что я отправлю ответ с окончательным ответом через 28,56 лет.

Если вы не можете ждать так долго, я готов поспорить, что

• Большинство ваших циклов не работают 28,56 лет
• 9007199254740992 === Math.pow(2, 53) + 1 достаточно доказательство
• Вы должны придерживаться 4294967295, что Math.pow(2,32) - 1, чтобы избежать ожидаемых проблем с битовым сдвигом.

Нахождение x + 1 === x:

(function () {
  "use strict";

  var x = 0
    , start = new Date().valueOf()
    ;

  while (x + 1 != x) {
    if (!(x % 10000000)) {
      console.log(x);
    }

    x += 1
  }

  console.log(x, new Date().valueOf() - start);
}());

Краткий ответ: «это зависит от обстоятельств».

Если вы где-то используете побитовые операторы (или если вы имеете в виду длину массива), диапазоны следующие:

Без подписи: 0…(-1>>>0)

Подпись: (-(-1>>>1)-1)…(-1>>>1)

(Так получилось, что побитовые операторы и максимальная длина массива ограничены 32-битными целыми числами.)

Если вы не используете побитовые операторы и не работаете с массивами длины:

Подпись: (-Math.pow(2,53))…(+Math.pow(2,53))

Эти ограничения налагаются внутренним представлением типа «Число», которое обычно соответствует представлению с плавающей запятой двойной точности IEEE 754. (Обратите внимание, что в отличие от типичных целых чисел со знаком, величина отрицательного предела такая же, как величина положительного предела, из-за характеристик внутреннего представления, которое фактически включает отрицательный 0!)

ECMAScript 6:

Number.MAX_SAFE_INTEGER = Math.pow(2, 53)-1;
Number.MIN_SAFE_INTEGER = -Number.MAX_SAFE_INTEGER;

Многие предыдущие ответы показали, что 9007199254740992 === 9007199254740992 + 1 истинно, чтобы проверить, что 9,007,199,254,740,991 является максимальным и безопасным целым числом.

Но что, если мы продолжим накопление:

input: 9007199254740992 + 1  output: 9007199254740992  // expected: 9007199254740993
input: 9007199254740992 + 2  output: 9007199254740994  // expected: 9007199254740994
input: 9007199254740992 + 3  output: 9007199254740996  // expected: 9007199254740995
input: 9007199254740992 + 4  output: 9007199254740996  // expected: 9007199254740996

Мы можем обнаружить, что среди чисел больше 9,007,199,254,740,992 только четные числа представимы.

Это начало объяснения того, как работает 64-битный двоичный формат двойной точности. Давайте посмотрим, как 9,007,199,254,740,992 удерживается (представляется) с помощью этого двоичного формата.

Использование краткой версии для демонстрации этого из 4,503,599,627,370,496:

  1 . 0000 ---- 0000  *  2^52            =>  1  0000 ---- 0000.  
     |-- 52 bits --|    |exponent part|        |-- 52 bits --|

Слева от стрелки у нас есть битовое значение 1 и смежная точка счисления. При использовании экспоненты слева точка системы счисления перемещается на 52 шага вправо. Точка счисления заканчивается в конце, и мы получаем 4503599627370496 в чистом двоичном формате.

Теперь давайте продолжаем увеличивать дробную часть на 1, пока все биты не будут установлены в 1, что равно 9,007,199,254,740,991 в десятичной системе.

  1 . 0000 ---- 0000  *  2^52  =>  1  0000 ---- 0000.  
                       (+1)
  1 . 0000 ---- 0001  *  2^52  =>  1  0000 ---- 0001.  
                       (+1)
  1 . 0000 ---- 0010  *  2^52  =>  1  0000 ---- 0010.  
                       (+1)
                        . 
                        .
                        .
  1 . 1111 ---- 1111  *  2^52  =>  1  1111 ---- 1111. 

Поскольку 64-битный формат с двойной точностью строго выделяет 52 бита для дробной части, больше не будет доступных битов, если мы добавим еще 1, поэтому мы можем установить все биты обратно в 0 и манипулировать экспонентной частью:

  ┏━━▶ This bit is implicit and persistent.
  ┃        
  1 . 1111 ---- 1111  *  2^52      =>  1  1111 ---- 1111. 
     |-- 52 bits --|                     |-- 52 bits --|

                          (+1)

  1 . 0000 ---- 0000  *  2^52 * 2  =>  1  0000 ---- 0000. * 2  
     |-- 52 bits --|                     |-- 52 bits --|
                                      (By consuming the 2^52, radix
                                       point has no way to go, but
                                       there is still one 2 left in
                                       exponent part)
  =>  1 . 0000 ---- 0000  *  2^53 
         |-- 52 bits --| 

Теперь мы получаем 9,007,199,254,740,992, и для числа, большего, чем это, формат может обрабатывать только приращения 2, потому что каждое приращение 1 в дробной части в конечном итоге умножается на левая 2 в показательной части. Вот почему 64-битный двоичный формат двойной точности не может содержать нечетные числа, если число больше 9,007,199,254,740,992:

                            (consume 2^52 to move radix point to the end)
  1 . 0000 ---- 0001  *  2^53  =>  1  0000 ---- 0001.  *  2
     |-- 52 bits --|                 |-- 52 bits --|

Следуя этой схеме, когда число становится больше 9,007,199,254,740,992 * 2 = 18,014,398,509,481,984, может быть удержана только 4-кратная дробь:

input: 18014398509481984 + 1  output: 18014398509481984  // expected: 18014398509481985
input: 18014398509481984 + 2  output: 18014398509481984  // expected: 18014398509481986
input: 18014398509481984 + 3  output: 18014398509481984  // expected: 18014398509481987
input: 18014398509481984 + 4  output: 18014398509481988  // expected: 18014398509481988

Как насчет чисел между [2 251 799 813 685 248, 4 503 599 627 370 496)?

 1 . 0000 ---- 0001  *  2^51  =>  1 0000 ---- 000.1
     |-- 52 bits --|                |-- 52 bits  --|

Значение 0,1 в двоичном формате равно 2 ^ -1 (= 1/2) (= 0,5). Поэтому, когда число меньше 4,503,599,627,370,496 (2 ^ 52), доступен один бит для представления 1/2 целого числа:

input: 4503599627370495.5   output: 4503599627370495.5  
input: 4503599627370495.75  output: 4503599627370495.5  
            

Менее 2,251,799,813,685,248 (2 ^ 51)

input: 2251799813685246.75   output: 2251799813685246.8  // expected: 2251799813685246.75 
input: 2251799813685246.25   output: 2251799813685246.2  // expected: 2251799813685246.25 
input: 2251799813685246.5    output: 2251799813685246.5
/**
   Please note that if you try this yourself and, say, log 
   these numbers to the console, they will get rounded. JavaScript
   rounds if the number of digits exceed 17. The value 
   is internally held correctly:
*/
            
input: 2251799813685246.25.toString(2) 
output: "111111111111111111111111111111111111111111111111110.01"
input: 2251799813685246.75.toString(2) 
output: "111111111111111111111111111111111111111111111111110.11"
input: 2251799813685246.78.toString(2)   
output: "111111111111111111111111111111111111111111111111110.11"

И каков диапазон доступных экспонент? Форматом на него отведено 11 бит.

Из Википедии (подробнее см. Здесь)

Другой, возможно, уже дал общий ответ, но я подумал, что было бы неплохо дать быстрый способ его определения:

for (var x = 2; x + 1 !== x; x *= 2);
console.log(x);

Это дает мне 9007199254740992 менее чем за миллисекунду в Chrome 30.

Он проверит степень двойки, чтобы определить, какая из них при «добавлении» 1 равна ему.

Все, что вы хотите использовать для побитовых операций, должно находиться в диапазоне от 0x80000000 (-2147483648 или -2 ^ 31) до 0x7fffffff (2147483647 или 2 ^ 31-1).

Консоль сообщит вам, что 0x80000000 равно +2147483648, а 0x80000000 и 0x80000000 равно -2147483648.

Пытаться:

maxInt = -1 >>> 1

В Firefox 3.6 это 2 ^ 31-1.

На момент написания JavaScript получает новый тип данных: BigInt. Это предложение TC39 на этапе 4, которое должно быть включено в EcmaScript 2020. BigInt доступен в Chrome 67+, FireFox 68+, Opera 54 и Node 10.4.0. Он реализуется в Safari и др ... Он вводит числовые литералы с суффиксом «n» и допускает произвольную точность:

var a = 123456789012345678901012345678901n;

Конечно, точность все равно будет потеряна, когда такое число (возможно, непреднамеренно) приведено к числовому типу данных.

И, очевидно, всегда будут ограничения точности из-за ограниченного объема памяти и затрат времени на выделение необходимой памяти и выполнение арифметических действий с такими большими числами.

Например, генерация числа из ста тысяч десятичных цифр займет заметную задержку до завершения:

console.log(BigInt("1".padEnd(100000,"0")) + 1n)

... но это работает.

Я провел простой тест с формулой X- (X + 1) = - 1, и наибольшее значение X, которое я могу получить для работы в Safari, Opera и Firefox (проверено на OS X), составляет 9e15. Вот код, который я использовал для тестирования:

javascript: alert(9e15-(9e15+1));

Я пишу это так:

var max_int = 0x20000000000000;
var min_int = -0x20000000000000;
(max_int + 1) === 0x20000000000000;  //true
(max_int - 1) < 0x20000000000000;    //true

То же самое для int32

var max_int32 =  0x80000000;
var min_int32 = -0x80000000;

Перейдем к источникам

Описание

Константа MAX_SAFE_INTEGER имеет значение 9007199254740991 (9,007,199,254,740,991 или ~ 9 квадриллионов). Причина этого числа заключается в том, что JavaScript использует числа в формате с плавающей запятой двойной точности как указано в IEEE 754 и может безопасно представлять только числа от -(2^53 - 1) до 2^53 - 1.

Под безопасностью в этом контексте понимается способность точно представлять целые числа и правильно их сравнивать. Например, Number.MAX_SAFE_INTEGER + 1 === Number.MAX_SAFE_INTEGER + 2 будет оцениваться как истина, что математически неверно. См. Number.isSafeInteger () для дополнительной информации.

Поскольку MAX_SAFE_INTEGER является статическим свойством Number , вы всегда используете его как Number.MAX_SAFE_INTEGER, а не как свойство Номер созданного вами объекта.

Совместимость с браузером

В JavaScript числа представлены как 2^53 - 1.

Однако вычисляются Bitwise operation на 32 bits ( 4 bytes ), что означает, что если вы превысите 32-битную смену, вы начнете терять биты.

Во встроенном javascript Google Chrome вы можете перейти примерно к 2 ^ 1024, прежде чем число будет называться бесконечным.

Скато пишет:

все, что вы хотите использовать для побитовых операций, должно находиться в диапазоне от 0x80000000 (-2147483648 или -2 ^ 31) до 0x7fffffff (2147483647 или 2 ^ 31-1).

консоль сообщит вам, что 0x80000000 равно +2147483648, но 0x80000000 и 0x80000000 равно -2147483648

Шестнадцатеричные десятичные числа - это положительные значения без знака, поэтому 0x80000000 = 2147483648 - это математически правильно. Если вы хотите сделать это значение со знаком, вам нужно сдвинуть вправо: 0x80000000 >> 0 = -2147483648. Вы также можете написать 1 ‹---------------- 31.

Firefox 3, похоже, не имеет проблем с огромными числами.

1e + 200 * 1e + 100 рассчитывается как 1e + 300.

У Safari, похоже, тоже нет проблем с этим. (Для записи, это на Mac, если кто-то еще решит это проверить.)

Если только я не потерял мозг в это время суток, это намного больше, чем 64-битное целое число.

Node.js и Google Chrome, похоже, используют 1024-битные значения с плавающей запятой, поэтому:

Number.MAX_VALUE = 1.7976931348623157e+308