Có hợp lý không khi cho rằng bất kỳ đại lượng vật lý nào cũng có thể được biểu diễn bằng số nguyên 64 bit mà không bị tràn hoặc tràn?

Thuật toán tìm kiếm nhị phân ban đầu trong JDK đã sử dụng số nguyên 32 bit và có lỗi tràn nếu (low + high) > INT_MAX( http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-gầnly.html ) .

Nếu chúng ta viết lại cùng một thuật toán tìm kiếm nhị phân bằng cách sử dụng các số nguyên 64 bit (đã ký), chúng ta có thể cho rằng low + highsẽ không bao giờ vượt quá INT64_MAX vì về mặt vật lý không thể có 10 ^ 18 byte bộ nhớ?

Khi sử dụng số nguyên 64 bit (đã ký) để biểu diễn các đại lượng vật lý , có hợp lý không khi giả sử tràn và tràn không thể xảy ra?

Câu trả lời ngắn gọn là không. Tuy nhiên, đối với một số ứng dụng, giả định của bạn có thể đúng.

Giả sử một int đã ký, 2 ^ 63, với dấu phẩy được thêm vào cho rõ ràng, = 9.223.372.036.854.775.808. Vì vậy, đó là khoảng 9 * 10 ^ 18. 10 ^ 18 là một "Exa".

Wikipedia cho biết "Tính đến năm 2013, World Wide Web ước tính đã đạt tới 4 zettabyte. [12]", tức là 4000 Exabyte. Do đó, WWW lớn hơn khoảng 400 lần so với 2 ^ 63 byte.

Do đó, có ít nhất một đại lượng vật lý lớn hơn nhiều so với số nguyên 64 bit đã ký (hoặc không dấu). Giả sử rằng các đơn vị của bạn là byte . Nếu các đơn vị của bạn là một cái gì đó lớn hơn nhiều, như GigaBytes, thì bạn sẽ ổn, nhưng độ chính xác đo lường của bạn sẽ thấp.

Đối với một ví dụ khác, hãy xem xét các thiên hà ở xa. Thiên hà Andromeda thực sự là một trong những thiên hà gần gũi và cách đó 2,5 * 10 ^ 6 năm ánh sáng. Nếu đơn vị của bạn là dặm , đó sẽ là 14,5 * 10 ^ 18, hơn một số nguyên ký 64 bit. Bây giờ, rõ ràng nó phụ thuộc vào đơn vị bạn sử dụng cho các phép đo của mình, nhưng một số thiên hà còn cách xa hơn Andromeda. ( Cách xa nhất được biết là 13 * 10 ^ 9 LY. ) Tùy thuộc vào độ chính xác bạn muốn cho phép đo của mình, nó có thể vượt quá số nguyên 64 bit.

( Added ) Có, dặm là một đơn vị tệ hại cho khoảng cách thiên văn. Một đơn vị bình thường hơn có thể là một đơn vị thiên văn , khoảng 93 triệu dặm. Sử dụng đơn vị đo lường đó, thiên hà xa nhất được biết đến là khoảng 10 ^ 15 AU (nếu toán của tôi đúng), sẽ phù hợp với int 64 bit. Tuy nhiên, nếu bạn cũng muốn đo khoảng cách tới Mặt trăng, đến các vệ tinh quay quanh quỹ đạo gần đó, đơn vị đó quá lớn.

Thêm một ví dụ từ điện tử: Farad (F), một đơn vị điện dung . Tụ điện lớn lên đến 5kF. Và con số này có thể sẽ tăng theo thời gian khi những chiếc xe hybrid, "lưới điện thông minh", v.v ... được cải thiện. Một lần có thể đo điện dung nhỏ bằng 10 ^ -18 F. Vì vậy, phạm vi tổng thể trong điện dung "thực" mà chúng ta có thể đo ngày nay là 5 * 10 ^ 21, lớn hơn số nguyên 64 bit.

Bạn thậm chí không cần phải đi vũ trụ khi có sự tham gia của tổ hợp. Có 2 ^ 95 giao dịch có thể có trong một trò chơi cầu nối và đó là khía cạnh nhỏ của sự phức tạp.

Số lượng vật lý phù hợp nhất cho câu hỏi của bạn là RAM máy tính .

Windows Server 2012 hỗ trợ tới 4 TB bộ nhớ vật lý. Đó là 2 ⁴² byte. Nếu dung lượng RAM tiếp tục tăng gấp đôi sau mỗi năm, thì chỉ sau 17 năm nữa, "Windows Server 2032" sẽ hỗ trợ 2 ⁶² byte bộ nhớ vật lý, tại thời điểm đó, bạn low + highsẽ đạt 2 ⁶³ - 2 và hôn số nguyên 64 bit được ký tối đa.

Tôi hy vọng không có hệ thống quan trọng nào về an toàn thất bại, giả sử 64 bit sẽ luôn là đủ.

Để sử dụng chung hơn một chút, đại lượng vật lý phù hợp nhất là không gian địa chỉ bộ nhớ . (Thật hữu ích khi có không gian địa chỉ lớn hơn nhiều so với bộ nhớ vật lý, ví dụ: đặt nhiều ngăn xếp trong bộ nhớ, tất cả đều có chỗ để phát triển.) Việc triển khai x86-64 hiện tại hỗ trợ địa chỉ ảo 48 bit, vì vậy chúng tôi chỉ còn 14 năm trước khi các CPU này đạt giới hạn không gian địa chỉ 2 ⁶² byte.

Và sau đó có bộ nhớ chia sẻ "nơi mà các bộ nhớ (riêng biệt) có thể được xử lý như một không gian địa chỉ (được chia sẻ hợp lý)".

Có hợp lý không khi cho rằng bất kỳ đại lượng vật lý nào cũng có thể được biểu diễn bằng số nguyên 64 bit mà không bị tràn hoặc tràn?

Không chính xác. Có rất nhiều số lớn hơn và nhỏ hơn số đó, đó là lý do tại sao chúng ta có số dấu phẩy động. Số dấu phẩy động đánh đổi độ chính xác thấp hơn cho phạm vi tốt hơn.

Trong ví dụ cụ thể mà bạn đã trích dẫn, rất khó có khả năng bạn sẽ cần một số lớn hơn số đó. 64 bit tương ứng với khoảng 18 triệu phần tử. Nhưng không bao giờ nói không bao giờ.

Giả định của bạn sẽ không xử lý các đại lượng vật lý chỉ có thể được biểu thị bằng số dấu phẩy động. Và ngay cả khi bạn quyết định chia tỷ lệ tất cả các số, giả sử bằng cách nhân tất cả các số với 10000 (vì vậy các giá trị vẫn là số nguyên nhưng có thể được biểu thị bằng mười phần nghìn), sơ đồ này vẫn thất bại đối với các số rất gần với 0, ví dụ như khối lượng electron (9,1094 * 10⎻³¹ kg).

Đó là một đại lượng vật lý rất thực (và cực kỳ nhỏ) , đây là một số điều nữa bạn sẽ gặp rắc rối. Và nếu bạn cho rằng đó không phải là một đại lượng vật lý thực sự (mặc dù nó tính bằng kg), hãy xem xét:

10 kg (obviously physical quantity)
1 kg (same)
10⎻² kg (1/100 kg, or about 1/3 ounce) (also quite real)

Vì vậy, bạn thấy nơi tôi đang đi với điều này. Điều cuối cùng bạn không thể xử lý.

Tất nhiên, bạn có thể có một trường đặc biệt trong số để chia tỷ lệ một phần nguyên lên hoặc xuống theo cấp số nhân; gee bây giờ bạn chỉ cần phát minh ra điểm nổi.

Đầu tiên tôi sẽ trả lời câu hỏi những giá trị vật lý nào có thể / nên được biểu thị bằng một số nguyên?

Số nguyên là một đại diện của một số tự nhiên (và sự khác biệt giữa chúng) trong một hệ thống máy tính, vì vậy áp dụng nó cho bất cứ điều gì khác là sai. Do đó, việc gọi khoảng cách hoặc các đại lượng khác thuộc về miền liên tục không phải là một đối số. Đối với số lượng như vậy có đại diện số thực. Và bạn luôn có thể chọn một đơn vị cực kỳ lớn và phù hợp với bất kỳ giá trị nào với độ chính xác nhất định.

Vì vậy, các giá trị vật lý là số tự nhiên là gì và chúng có thể vượt quá số nguyên 64 bit không?

Tôi có thể nghĩ về hai. Số lượng vật thể (như nguyên tử) và mức năng lượng mà một hệ lượng tử có thể có. Đó là hai thứ có số nguyên hoàn toàn. Bây giờ, tôi biết bạn có thể tách một nguyên tử, nhưng nó vẫn tạo ra một số nguyên và bạn không thể chia nó vô thời hạn. Cả hai đều có thể dễ dàng vượt qua phạm vi 64 bit của số nguyên không dấu . Số lượng nguyên tử cao hơn và một nguyên tử có thể ở nhiều trạng thái năng lượng.

Cho dù thông tin là vật lý hay không, là rất tranh cãi. Tôi sẽ nói là không. Do đó, tôi sẽ không nói lượng thông tin là một thứ vật chất. Vì vậy, không phải là dung lượng RAM hoặc bất cứ thứ gì như vậy. Nếu bạn cho phép điều này, thì số nguyên tử dễ dàng vượt qua con số này, bởi vì bạn cần nhiều hơn một nguyên tử để lưu trữ một bit với công nghệ ngày nay.

Ngoài câu trả lời của Jerry101, tôi muốn cung cấp bài kiểm tra rất đơn giản và thực tế này cho chính xác:

Giả sử bạn phân bổ một số bộ nhớ thông qua malloc, trong HĐH 64 bit. Giả sử bộ cấp phát bộ nhớ quyết định trả lại cho bạn một khối bộ nhớ hợp lệ, có kích thước bạn yêu cầu, nhưng nơi đặt bit thứ 63.

Nói cách khác, giả sử tồn tại một số môi trường lập trình trong đó 0xFFFFFFFFxxxxxxxxcác phạm vi bộ nhớ hợp pháp có thể được trả về từ một cuộc gọi đến malloc.

Câu hỏi là, mã của bạn sẽ vẫn hoạt động như dự định chứ?

Khi tình huống tương tự xảy ra với các hệ điều hành 32 bit, một số phần mềm không hoạt động chính xác nếu chúng được cung cấp địa chỉ bộ nhớ "ở nửa trên". Ban đầu, các địa chỉ bộ nhớ như vậy được cho là chỉ dành cho mã đặc quyền (hệ điều hành, trình điều khiển thiết bị và phần cứng ngoại vi), nhưng vì sự khủng hoảng không gian địa chỉ 32 bit, các nhà cung cấp hệ điều hành đã quyết định cung cấp một phần không gian dành riêng đó cho các ứng dụng yêu cầu nó.

May mắn thay, tình huống này khá khó xảy ra đối với các chương trình 64 bit trong một thời gian, ít nhất là không trong một thập kỷ.

Khi tình huống đó cuối cùng xảy ra, điều đó có nghĩa là bộ xử lý và hệ điều hành có địa chỉ 128 bit sẽ trở thành xu hướng vào thời điểm đó và họ có thể cung cấp "môi trường mô phỏng 64 bit" để cho phép các "ứng dụng cũ" này hoạt động theo các giả định tương tự như các hệ điều hành 64 bit ngày nay.

Cuối cùng, lưu ý rằng cuộc thảo luận này chỉ tập trung vào các địa chỉ bộ nhớ. Một vấn đề tương tự với dấu thời gian phải được thực hiện với sự đề phòng nhiều hơn, bởi vì các định dạng dấu thời gian nhất định phân bổ rất nhiều bit chính xác cho micro giây, và do đó để lại ít bit hơn để biểu thị thời gian trong tương lai. Những vấn đề này được tóm tắt trong bài viết Wikipedia về vấn đề Năm 2038 .

Đây là một câu hỏi bạn cần hỏi trên cơ sở từng trường hợp. Bạn không nên sử dụng một giả định chung rằng số học 64 bit sẽ không tràn, bởi vì ngay cả khi số lượng chính xác sẽ ở trong phạm vi nhỏ hơn nhiều, một nguồn dữ liệu độc hại cuối cùng có thể cung cấp cho bạn số lượng không hợp lý có thể tràn ra và tốt hơn là nên chuẩn bị cho tình huống này hơn là bị nó tấn công bất ngờ.

Có một số trường hợp có ý nghĩa khi viết mã phụ thuộc vào việc không tràn các số 64 bit. Lớp ví dụ chính mà tôi biết là các bộ đếm, trong đó bộ đếm được tăng lên mỗi khi nó được sử dụng. Ngay cả với tốc độ một lần tăng trên mỗi nano giây (không thực tế), sẽ mất hơn một thế kỷ để tràn.

Lưu ý rằng trong khi nó ở có vẻ đầu tiên "luôn luôn sai về nguyên tắc" phải dựa vào "thời gian cho đến khi thất bại" về tính chính xác của một hệ thống, chúng tôi làm điều này tất cả các thời gian với xác thực / đăng nhập. Cho đủ thời gian (đối với cưỡng bức), bất kỳ hệ thống nào như vậy (cho dù dựa trên mật khẩu, khóa riêng, mã thông báo phiên, v.v.) đều bị hỏng.

Có phải POSSIBLE cho một đại lượng vật lý không vừa với 64 bit không? Tất nhiên. Những người khác đã chỉ ra việc đếm số lượng nguyên tử trong mặt trời hoặc số milimet cho thiên hà tiếp theo. Việc các trường hợp như vậy có liên quan đến ứng dụng của bạn hay không phụ thuộc vào ứng dụng của bạn là gì. Nếu bạn đang đếm số lượng vật phẩm trong bất kỳ thùng nào trong kho của mình, 16 bit có thể là đủ. Nếu bạn đang tổng hợp số liệu thống kê về số lượng người trên thế giới đáp ứng các điều kiện khác nhau, bạn cần có khả năng ghi lại hàng tỷ, vì vậy bạn sẽ cần nhiều hơn 32 bit, tại thời điểm đó, có lẽ bạn sẽ đến 64 (ít máy tính có hỗ trợ tích hợp cho số 37 bit, v.v.). Nếu đây là một ứng dụng hóa học đếm số mol nguyên tử, thì 64 bit sẽ không đủ.

Về mặt kỹ thuật, chỉ vì ngày nay không có máy tính nào có 2 ^ 64 byte bộ nhớ không nhất thiết có nghĩa là một chỉ số mảng không bao giờ có thể nhiều hơn 2 ^ 64. Có một khái niệm gọi là "mảng thưa thớt" trong đó nhiều phần tử của mảng không được lưu trữ ở bất kỳ đâu và các giá trị không được bảo vệ như vậy được giả sử có một số giá trị mặc định như null hoặc zero. Nhưng tôi cho rằng nếu bạn đang viết một hàm để tìm kiếm một mảng hoặc danh sách một loại nào đó, và kích thước của trường bạn đang sử dụng để giữ chỉ mục vào mảng lớn hơn gấp đôi địa chỉ lớn nhất có thể, sau đó kiểm tra xem có tràn không thêm hai chỉ mục sẽ không thực sự cần thiết.

Thật vô lý khi giả sử một số nguyên 64 bit có thể chứa tất cả các số. Nhiều lý do:

1. Số nguyên 64 bit tối đa và tối thiểu là số hữu hạn. Đối với mỗi số hữu hạn, một số hữu hạn lớn hơn và nhỏ hơn tồn tại.

2. Tính toán với số 128 bit và 256 bit hiện đang được sử dụng ở nhiều nơi. Nhiều bộ xử lý có các hướng dẫn cụ thể hoạt động trên số nguyên 128 bit.

3. 20 năm trước, đĩa 1 GB được coi là "lớn". Ngày nay, đĩa 1 TB được coi là nhỏ. 20 năm trước máy tính để bàn trung bình có khoảng 16 MB RAM. Máy tính để bàn hiện tại của tôi có hơn 16 GB RAM. Không gian ổ cứng và RAM đã tăng theo cấp số nhân trong quá khứ và được dự đoán sẽ tăng theo cấp số nhân trong tương lai. Trừ khi ai đó có thể đưa ra một lý do rất chính đáng tại sao nó nên ngừng phát triển, không có nghĩa gì khi cho rằng nó sẽ dừng lại.