Điều này được xác định bởi ngôn ngữ? Có tối đa xác định? Có khác nhau trong các trình duyệt khác nhau?

JavaScript có hai loại số: Numbervà BigInt.

Loại số được sử dụng thường xuyên nhất Number, là số IEEE 754 có dấu phẩy động 64 bit .

Giá trị tích phân chính xác lớn nhất của loại này Number.MAX_SAFE_INTEGERlà:

• 2 ⁵³ -1, hoặc
• +/- 9,007,199,254,740,991 hoặc
• chín triệu một nghìn bảy nghìn một trăm chín mươi chín tỷ hai trăm năm mươi bốn triệu bảy trăm bốn mươi nghìn chín trăm chín mươi mốt

Để đặt điều này trong phối cảnh: một triệu triệu byte là một petabyte (hoặc một nghìn terabyte).

"An toàn" trong ngữ cảnh này đề cập đến khả năng thể hiện chính xác các số nguyên và so sánh chính xác chúng.

Từ thông số kỹ thuật:

Lưu ý rằng tất cả các số nguyên dương và âm có độ lớn không lớn hơn 2 ⁵³ đều có thể biểu diễn trong Numberloại (thực tế, số nguyên 0 có hai biểu diễn, +0 và -0).

Để sử dụng một cách an toàn các số nguyên lớn hơn số này, bạn cần sử dụng BigInt, không có giới hạn trên.

Lưu ý rằng các toán tử bit và toán tử dịch chuyển hoạt động trên các số nguyên 32 bit, do đó, trong trường hợp đó, số nguyên an toàn tối đa là 2 ³¹ -1, hoặc 2.147.483.647.

const log = console.log
var x = 9007199254740992
var y = -x
log(x == x + 1) // true !
log(y == y - 1) // also true !

// Arithmetic operators work, but bitwise/shifts only operate on int32:
log(x / 2)      // 4503599627370496
log(x >> 1)     // 0
log(x | 1)      // 1

Lưu ý kỹ thuật về chủ đề của số 9,007,199,254,740,992: Có một đại diện chính xác của IEEE-754 của giá trị này và bạn có thể gán và đọc giá trị này từ một biến, vì vậy, đối với các ứng dụng được chọn rất cẩn thận trong miền số nguyên nhỏ hơn hoặc bằng giá trị này, bạn có thể coi đây là giá trị tối đa.

Trong trường hợp chung, bạn phải coi giá trị IEEE-754 này là không chính xác, vì không rõ liệu nó có mã hóa giá trị logic 9,007,199,254,740,992 hay 9,007,199,254,740,993.

> = ES6:

Number.MIN_SAFE_INTEGER;
Number.MAX_SAFE_INTEGER;

<= ES5

Từ tài liệu tham khảo :

Number.MAX_VALUE;
Number.MIN_VALUE;

console.log('MIN_VALUE', Number.MIN_VALUE);
console.log('MAX_VALUE', Number.MAX_VALUE);

console.log('MIN_SAFE_INTEGER', Number.MIN_SAFE_INTEGER); //ES6
console.log('MAX_SAFE_INTEGER', Number.MAX_SAFE_INTEGER); //ES6

Đó là 2 ⁵³ == 9 007 199 254 740 992. Điều này là doNumber s được lưu dưới dạng dấu phẩy động trong lớp phủ 52 bit.

Giá trị tối thiểu là -2 ⁵³ .

Điều này làm cho một số điều thú vị xảy ra

Math.pow(2, 53) == Math.pow(2, 53) + 1
>> true

Và cũng có thể nguy hiểm :)

var MAX_INT = Math.pow(2, 53); // 9 007 199 254 740 992
for (var i = MAX_INT; i < MAX_INT + 2; ++i) {
    // infinite loop
}

_{Đọc thêm: http://blog.vjeux.com/2010/javascript/javascript-max_int-number-limits.html}

Trong JavaScript, có một số được gọi là Infinity.

Ví dụ:

(Infinity>100)
=> true

// Also worth noting
Infinity - 1 == Infinity
=> true

Math.pow(2,1024) === Infinity
=> true

Điều này có thể đủ cho một số câu hỏi liên quan đến chủ đề này.

Câu trả lời của Jimmy thể hiện chính xác phổ số nguyên JavaScript liên tục là -9007199254740992 đến 9007199254740992 (xin lỗi 9007199254740993, bạn có thể nghĩ rằng mình là 9007199254740993, nhưng bạn đã nhầm! Trình diễn bên dưới hoặc trong jsfiddle ).

console.log(9007199254740993);

Tuy nhiên, không có câu trả lời nào tìm thấy / chứng minh điều này theo chương trình (ngoài câu hỏi CoolAJ86 được ám chỉ trong câu trả lời của anh ta sẽ kết thúc sau 28,56 năm;), vì vậy đây là cách hiệu quả hơn một chút (chính xác hơn, nó hiệu quả hơn vào khoảng 28.559999999968312 năm :), cùng với một câu đố thử nghiệm :

/**
 * Checks if adding/subtracting one to/from a number yields the correct result.
 *
 * @param number The number to test
 * @return true if you can add/subtract 1, false otherwise.
 */
var canAddSubtractOneFromNumber = function(number) {
    var numMinusOne = number - 1;
    var numPlusOne = number + 1;
    
    return ((number - numMinusOne) === 1) && ((number - numPlusOne) === -1);
}

//Find the highest number
var highestNumber = 3; //Start with an integer 1 or higher

//Get a number higher than the valid integer range
while (canAddSubtractOneFromNumber(highestNumber)) {
    highestNumber *= 2;
}

//Find the lowest number you can't add/subtract 1 from
var numToSubtract = highestNumber / 4;
while (numToSubtract >= 1) {
    while (!canAddSubtractOneFromNumber(highestNumber - numToSubtract)) {
        highestNumber = highestNumber - numToSubtract;
    }
    
    numToSubtract /= 2;
}        

//And there was much rejoicing.  Yay.    
console.log('HighestNumber = ' + highestNumber);

Để được an toàn

var MAX_INT = 4294967295;

Lý luận

Tôi nghĩ tôi sẽ thông minh và tìm ra giá trị x + 1 === x theo cách tiếp cận thực tế hơn.

Máy của tôi chỉ có thể đếm 10 triệu mỗi giây hoặc lâu hơn ... vì vậy tôi sẽ đăng lại với câu trả lời dứt khoát trong 28,56 năm.

Nếu bạn không thể đợi lâu như vậy, tôi sẵn sàng đặt cược rằng

• Hầu hết các vòng lặp của bạn không chạy trong 28,56 năm
• 9007199254740992 === Math.pow(2, 53) + 1 là đủ bằng chứng
• Bạn nên tuân theo 4294967295đó là Math.pow(2,32) - 1để tránh các vấn đề dự kiến ​​với dịch chuyển bit

Tìm kiếm 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);
}());

Câu trả lời ngắn gọn là tùy nó.

Nếu bạn đang sử dụng toán tử bitwise ở bất cứ đâu (hoặc nếu bạn đang đề cập đến độ dài của Mảng), thì các phạm vi là:

Chưa ký: 0…(-1>>>0)

Đã ký: (-(-1>>>1)-1)…(-1>>>1)

(Điều đó xảy ra khi các toán tử bitwise và độ dài tối đa của một mảng bị giới hạn ở các số nguyên 32 bit.)

Nếu bạn không sử dụng toán tử bitwise hoặc làm việc với độ dài mảng:

Đã ký: (-Math.pow(2,53))…(+Math.pow(2,53))

Những hạn chế này được áp đặt bởi biểu diễn bên trong của loại Số Số, thường tương ứng với biểu diễn dấu phẩy động có độ chính xác kép của IEEE 754. (Lưu ý rằng không giống như các số nguyên được ký điển hình, độ lớn của giới hạn âm giống như độ lớn của giới hạn dương, do các đặc điểm của biểu diễn bên trong, thực sự bao gồm 0 âm !)

Bản thảo 6:

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

Nhiều câu trả lời từ thời gian trước đã cho thấy kết quả truecủa 9007199254740992 === 9007199254740992 + 1việc xác minh rằng 9 007 199 254 740 991 là số nguyên tối đa và an toàn.

Điều gì xảy ra nếu chúng ta tiếp tục tích lũy:

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

Chúng ta có thể tìm ra rằng trong số các số lớn hơn 9 007 199 254 740 992 , chỉ các số chẵn là có thể biểu diễn .

Đây là một lối vào để giải thích cách thức định dạng nhị phân 64 bit chính xác kép hoạt động trên này. Hãy xem 9 007 199 254 740 992 được tổ chức (đại diện) bằng cách sử dụng định dạng nhị phân này.

Sử dụng một phiên bản ngắn gọn để trình diễn nó từ 4 503 599 627 370 496 :

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

Ở bên trái của mũi tên, chúng ta có giá trị bit 1 và một điểm cơ số liền kề , sau đó bằng cách nhân 2^52, chúng ta phải di chuyển điểm cơ số 52 bước và đi đến cuối. Bây giờ chúng tôi nhận được 4503599627370496 trong nhị phân.

Bây giờ chúng ta bắt đầu tích lũy 1 đến giá trị này cho đến khi tất cả các bit được đặt thành 1, bằng 9 007 199 254 740 991 theo số thập phân.

  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. 

Bây giờ, vì ở định dạng nhị phân 64 bit có độ chính xác kép , nó hoàn toàn phân bổ 52 bit cho phân số, không còn bit nào để mang thêm 1, vì vậy, điều chúng ta có thể làm là đặt tất cả các bit về 0 và Thao tác phần số mũ:

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

                          (+1)
                                     (radix point has no way to go)
  1 . 0000 ---- 0000  *  2^52 * 2  =>  1  0000 ---- 0000. * 2  
     |-- 52 bits --|                     |-- 52 bits --|

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

Bây giờ chúng ta nhận được 9 007 199 254 740 992 và với số lượng lớn hơn nó, định dạng có thể giữ bằng 2 lần phân số , có nghĩa là bây giờ cứ 1 phần bổ sung trên phần phân số thực sự bằng 2 phần bổ sung, đó là lý do tại sao tăng gấp đôi -định dạng định dạng nhị phân 64 bit không thể giữ các số lẻ khi số lớn hơn 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 --|

Vì vậy, khi số lượng lớn hơn 9 007 199 254 740 992 * 2 = 18 014 398 509 481 984, chỉ có thể giữ 4 lần phân số :

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

Làm thế nào về số giữa [ 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  --|

Giá trị bit 1 sau điểm cơ số chính xác là 2 ^ -1. (= 1/2, = 0,5) Vì vậy, khi số nhỏ hơn 4 503 599 627 370 496 (2 ^ 52), có một bit có sẵn để biểu thị 1/2 lần của số nguyên :

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

Ít hơn 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

// If the digits exceed 17, JavaScript round it to print it.
//, but the value is 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"

Và phạm vi có sẵn của phần số mũ là gì? định dạng phân bổ 11 bit cho nó. Định dạng hoàn chỉnh từ Wiki : (Để biết thêm chi tiết xin vui lòng đến đó)

Vì vậy, để làm cho phần số mũ là 2 ^ 52, chúng ta chính xác cần đặt e = 1075.

Những người khác có thể đã đưa ra câu trả lời chung chung, nhưng tôi nghĩ rằng đó là một ý tưởng tốt để đưa ra một cách nhanh chóng để xác định nó:

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

Cung cấp cho tôi 9007199254740992 trong vòng chưa đến một phần nghìn giây trong Chrome 30.

Nó sẽ kiểm tra sức mạnh của 2 để tìm ra cái nào, khi 'thêm' 1, bằng chính mình.

Bất cứ điều gì bạn muốn sử dụng cho các hoạt động bitwise phải nằm trong khoảng 0x80000000 (-2147483648 hoặc -2 ^ 31) và 0x7fffffff (2147483647 hoặc 2 ^ 31 - 1).

Bảng điều khiển sẽ cho bạn biết rằng 0x80000000 bằng +2147483648, nhưng 0x80000000 & 0x80000000 bằng -2147483648.

Thử:

maxInt = -1 >>> 1

Trong Firefox 3.6, đó là 2 ^ 31 - 1.

Tại thời điểm viết bài, JavaScript đang nhận một loại dữ liệu mới : BigInt. Đó là một đề xuất TC39 ở giai đoạn 4 được đưa vào EcmaScript 2020 . BigIntcó sẵn trong Chrome 67+, FireFox 68+, Opera 54 và Node 10.4.0. Nó đang được tiến hành trong Safari, et al ... Nó giới thiệu các chữ số có hậu tố "n" và cho phép độ chính xác tùy ý:

var a = 123456789012345678901012345678901n;

Tất nhiên, độ chính xác vẫn sẽ bị mất, khi một số như vậy (có thể vô tình) bị ép buộc thành một kiểu dữ liệu số.

Và rõ ràng, sẽ luôn có những giới hạn chính xác do bộ nhớ hữu hạn và chi phí về thời gian để phân bổ bộ nhớ cần thiết và thực hiện số học trên những số lượng lớn như vậy.

Chẳng hạn, việc tạo một số có một trăm nghìn chữ số thập phân, sẽ có độ trễ đáng chú ý trước khi hoàn thành:

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

...nhưng nó đã có tác dụng.

Tôi đã thực hiện một thử nghiệm đơn giản với công thức, X- (X + 1) = - 1 và giá trị lớn nhất của XI có thể hoạt động trên Safari, Opera và Firefox (thử nghiệm trên OS X) là 9e15. Đây là mã tôi đã sử dụng để thử nghiệm:

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

Tôi viết nó như thế này:

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

Tương tự cho int32

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

Hãy đi đến các nguồn

Sự miêu tả

Các MAX_SAFE_INTEGERhằng số có giá trị 9007199254740991(9,007,199,254,740,991 hoặc ~ 9 nghìn triệu triệu). Lý do đằng sau con số đó là JavaScript sử dụng các số định dạng dấu phẩy động có độ chính xác kép như được chỉ định trong IEEE 754 và chỉ có thể biểu thị một cách an toàn các số giữa -(2^53 - 1)và2^53 - 1 .

An toàn trong ngữ cảnh này đề cập đến khả năng thể hiện chính xác các số nguyên và so sánh chính xác chúng. Ví dụ, Number.MAX_SAFE_INTEGER + 1 === Number.MAX_SAFE_INTEGER + 2sẽ đánh giá là đúng, về mặt toán học không chính xác. Xem Number.isSafeInteger () để biết thêm thông tin.

Bởi vì MAX_SAFE_INTEGERlà một thuộc tính tĩnh của Số , bạn luôn sử dụng nó như Number.MAX_SAFE_INTEGERlà một thuộc tính của đối tượng Số mà bạn đã tạo.

Tính tương thích của trình duyệt web

Trong javascript tích hợp Google Chrome, bạn có thể truy cập khoảng 2 ^ 1024 trước khi số được gọi là vô cùng.

Trong JavaScript biểu diễn số là 2^53 - 1.

Tuy nhiên , Bitwise operationđược tính trên 32 bits ( 4 bytes ), nghĩa là nếu bạn vượt quá 32 bit, bạn sẽ bắt đầu mất bit.

Scato wrote:

bất cứ điều gì bạn muốn sử dụng cho các hoạt động bitwise phải nằm trong khoảng 0x80000000 (-2147483648 hoặc -2 ^ 31) và 0x7fffffff (2147483647 hoặc 2 ^ 31 - 1).

Bảng điều khiển sẽ cho bạn biết rằng 0x80000000 bằng +2147483648, nhưng 0x80000000 & 0x80000000 bằng -2147483648

Hex-Decimals là các giá trị dương không dấu, vì vậy 0x80000000 = 2147483648 - đó là chính xác về mặt toán học. Nếu bạn muốn biến nó thành một giá trị đã ký, bạn phải chuyển sang phải: 0x80000000 >> 0 = -2147483648. Bạn cũng có thể viết 1 << 31.

Firefox 3 dường như không có vấn đề gì với số lượng khổng lồ.

1e + 200 * 1e + 100 sẽ tính tiền phạt thành 1e + 300.

Safari dường như không có vấn đề với nó là tốt. (Đối với bản ghi, đây là trên máy Mac nếu có ai khác quyết định kiểm tra điều này.)

Trừ khi tôi bị mất não vào thời điểm này trong ngày, đây là cách lớn hơn số nguyên 64 bit.

Cả Node.js và Google Chrome dường như đều đang sử dụng các giá trị dấu phẩy động 1024 bit, vì vậy:

Number.MAX_VALUE = 1.7976931348623157e+308