Чи розумно вважати, що будь-яка фізична величина може бути представлена ​​64-бітним цілим числом без переливу чи переливу?

Оригінальний алгоритм бінарного пошуку в JDK використовував 32-бітні цілі числа та мав помилку переповнення, якщо (low + high) > INT_MAX( http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html ) .

Якщо ми переписали той самий бінарний алгоритм пошуку, використовуючи (підписані) 64-бітні цілі числа, чи можемо ми припустити, що low + highвін ніколи не перевищить INT64_MAX, оскільки фізично неможливо мати 10 ^ 18 байт пам'яті?

Використовуючи (підписані) 64-бітні цілі числа для представлення фізичних величин , чи розумно припустити, що переповнення та переповнення не можуть відбутися?

Коротка відповідь - ні. Однак для деяких додатків ваше припущення може бути правильним.

Якщо припустити підписаний int, 2 ^ 63, з деякою чіткістю додані коми, = 9,223,372,036,854,775,808. Так це приблизно 9 * 10 ^ 18. 10 ^ 18 - це «Екса».

У Вікіпедії зазначається, що "Станом на 2013 рік всесвітня павутина досягла 4 зеттабайт. [12]", що становить 4000 екзабайт. Тому WWW приблизно в 400 разів більший, ніж 2 ^ 63 байти.

Тому існує принаймні одна фізична величина, значно більша за підписане (або непідписане) 64-бітове ціле число. Якщо припустити, що ваші одиниці є байтами . Якби ваші одиниці були чимось набагато більшими, як, наприклад, GigaBytes, тоді вам би все в порядку, але точність вимірювання була б низькою.

Для іншого прикладу розглянемо далекі галактики. Галактика Андромеда насправді одна із близьких, і вона знаходиться на відстані 2,5 * 10 ^ 6 світлових років. Якщо ваші одиниці були милями , це було б 14,5 * 10 ^ 18, більше 64-бітового цілого числа. Тепер, очевидно, це залежить від одиниць, які ви використовуєте для своїх вимірювань, але деякі галактики набагато далі, ніж Андромеда. ( Найдальший відомий - 13 * 10 ^ 9 LY. ) Залежно від точності, яку ви хочете зробити для вимірювання, він може переповнювати 64-бітове ціле число.

( Додано ) Так, милі - це паршива одиниця для астрономічної відстані. Більш нормальною одиницею може бути астрономічна одиниця , приблизно 93 мільйони миль. Використовуючи цю одиницю вимірювання, найдальша відома галактика становить приблизно 10 ^ 15 АС (якщо моя математика правильна), що могло б вписатись у 64 бітову точку. Однак якщо ви хотіли також виміряти відстань до Місяця, до супутників навколо орбіти, ця одиниця занадто велика.

Ще один приклад електроніки: Farad (F), одиниця ємності . Великі конденсатори мають діапазон до 5 кФ. І ця кількість, ймовірно, зросте з часом у міру вдосконалення гібридних автомобілів, "розумних сіток" тощо. Один раз можна виміряти ємність на рівні 10 ^ -18 F. Отже, загальний діапазон "реальної" ємності, який ми можемо виміряти сьогодні, становить 5 * 10 ^ 21, більший за 64-бітове ціле число.

Вам навіть не потрібно йти космічно, коли задіяна комбінаторика. Існує 2 ^ 95 можливих угод в грі в міст, і це з невеликої сторони складності.

Найбільш відповідна фізична кількість для вашого питання - це комп'ютерна оперативна пам’ять .

Windows Server 2012 підтримує до 4 ТБ фізичної пам'яті. Це 2 ⁴² байти. Якщо ємність оперативної пам’яті продовжує збільшуватися вдвічі приблизно щороку, то лише через 17 років «Windows Server 2032» підтримуватиме 2 ⁶² байти фізичної пам’яті, за цей час ви low + highдосягнете 2 ⁶³ - 2 і поцілуєте максимально підписане 64-бітове ціле число.

Я сподіваюся, що жодна система, що критикує безпеку, не виходить, якщо припустити, що 64 біта завжди буде достатньо.

Для дещо більш загального використання найбільш релевантною фізичною кількістю є адресний простір пам'яті . (Корисно мати набагато більший адресний простір, ніж фізична пам'ять, наприклад, щоб помістити багато стеків у пам'ять, щоб все зростало.) Поточні реалізації x86-64 підтримують 48-бітові віртуальні адреси, тому перед цим процесором ми маємо лише 14 років. межа 2 ^62- байтного адресного простору.

І тоді розподіляється спільна пам'ять, "де (фізично окремі) пам'яті можна розглядати як один (логічно спільний) адресний простір".

Чи розумно вважати, що будь-яка фізична величина може бути представлена ​​64-бітним цілим числом без переливу чи переливу?

Не зовсім. Існує безліч чисел, які є більшими і меншими за це, тому ми маємо числа з плаваючою комою. Номери з плаваючою комою торгують меншою точністю для кращого дальності.

У конкретному прикладі, який ви наводили, малоймовірно, що вам коли-небудь знадобиться число, яке перевищує це. 64 біта відповідає приблизно 18 квінтиліонним елементам. Але ніколи не кажи ніколи.

Ваше припущення не обробляє фізичні величини, які можуть бути представлені лише числами з плаваючою комою. І навіть якщо ви вирішили масштабувати всі числа, скажімо, помноживши всі числа на 10000 (тому значення все ще є цілими числами, але їх можна представити в десятитисячних), ця схема все одно не справляється з числами, дуже близькими до нуля, наприклад, електронна маса (9.1094 * 10⎻³¹ кг).

Це дуже реальна (і надзвичайно мала) фізична кількість , ось ще кілька, з якими у вас виникнуть проблеми. І якщо ви стверджуєте, що це не реальна фізична кількість (навіть якщо вона є в кг), врахуйте:

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

Тож ви бачите, куди я з цим іду. Останній, з яким ви не можете впоратися.

Звичайно, у вас може бути спеціальне поле в межах числа для масштабування цілої частини вгору або вниз змінним множником; гей тепер ви щойно вигадали плаваючу крапку.

Спершу я відповів би на питання, які фізичні значення можуть / повинні бути представлені цілим числом?

Integer - це представлення натуральної кількості (та різниці між ними) в комп'ютерній системі, тому застосовувати її до чого-небудь іншого неправильно. Таким чином, виклик відстаней чи інших величин, що належать до безперервного домену, не є аргументом. Для таких величин існує реальне уявлення про число. І ви завжди можете вибрати довільно велику одиницю і підібрати будь-яке значення з заданою точністю.

Отже, що таке фізичні значення, які є натуральними числами, і чи можуть вони переповнювати 64-бітове ціле число?

Я можу придумати два. Кількість фізичних об'єктів (наприклад, атомів) та енергетичні рівні, в яких може бути квантова система. Це дві речі, які є цілими цілими числами. Тепер я знаю, що ви можете розділити атом, але він все одно видає цілу кількість, і ви не можете розділити його на невизначений час. Обидва вони можуть легко перевершити 64-бітовий діапазон непідписаного цілого числа . Кількість атомів більше, і один атом може перебувати в більшій кількості енергетичного стану.

Будь-яка інформація є фізичною чи ні, дуже дискусійною. Я б сказав, що це не так. Тому я б не сказав, що кількість інформації - це фізична річ. Так це не об'єм оперативної пам’яті чи щось подібне. Якщо ви дозволите це, то кількість атомів легко перевищує це число, тому що вам потрібно більше одного атома, щоб зберігати один біт за сьогоднішньою технологією.

Окрім відповіді Jerry101, я хотів би запропонувати цей дуже простий та практичний тест на правильність:

Припустимо, ви виділяєте деяку пам’ять через malloc64-бітну ОС. Припустимо, розподільник пам'яті вирішить повернути вам дійсний блок пам'яті розміру, який ви вимагали, але там, де встановлено 63-й біт.

Іншими словами, припустимо, що існують деякі програми програмування, де 0xFFFFFFFFxxxxxxxxє законні діапазони пам'яті, які можуть бути повернуті з виклику в malloc.

Питання полягає в тому, чи все-таки ваш код працюватиме за призначенням?

Коли аналогічна ситуація трапляється з 32-бітними операційними системами, деякі програми не працюють належним чином, якщо їм надано адреси пам'яті "у верхній половині". Спочатку такі адреси пам’яті вважалися доступними лише для привілейованого коду (операційні системи, драйвери пристроїв та периферійне обладнання), але через стиснення 32-бітного адресного простору постачальники ОС вирішили зробити частину цього зарезервованого простору доступною для програми, які вимагають цього.

На щастя, така ситуація навряд чи станеться для 64-бітних програм протягом деякого часу, принаймні, не через десятиліття.

Коли ця ситуація нарешті станеться, це означає, що до цього часу 128-розрядні процесори та операційні системи стали б мейнстрімом, і вони змогли б забезпечити "64-бітове середовище емуляції", щоб ті "застарілі програми" могли працювати за припущеннями, подібними до сьогоднішніх 64-бітних операційних систем.

Нарешті, зауважте, що ця дискусія зосереджена лише на адресах пам'яті. Аналогічну проблему із часовими позначками слід сприймати з більшою обережністю, оскільки певні формати міток часу виділяють багато біт точності на мікросекунди, і тому залишається менше бітів, щоб представити час у майбутньому. Ці питання узагальнені у статті Вікіпедії щодо проблеми 2038 року .

Це питання, яке вам потрібно задати в кожному конкретному випадку. Не слід використовувати загальне припущення, що 64-розрядна арифметика не переповниться, тому що навіть коли правильні кількості будуть в набагато меншому діапазоні, шкідливе джерело даних може в кінцевому підсумку дати вам необгрунтовані кількості, які можуть переповнюватись, і краще бути підготовлені до цієї ситуації, ніж несподівано її вдарити.

Є деякі випадки, коли є сенс писати код, який залежить від непереповнення 64-бітових чисел. Основний клас прикладу, який я знаю, - це лічильники, де лічильник збільшується щоразу, коли він використовується. Навіть зі швидкістю одного приросту на наносекунд (не практично) знадобиться більше століття.

Зауважте, що, хоча спочатку може здатися "завжди неправильним в принципі" покладатися на "час до відмови" для правильності системи, ми робимо це весь час з аутентифікацією / входом. Враховуючи достатньо часу (для грубого форсування), будь-яка така система (чи то на основі паролів, приватних ключів, маркерів сеансу тощо) порушена.

Чи МОЖЛИВО, щоб фізична величина не вміщувалася в 64 біти? Звичайно. Інші вказали на підрахунок кількості атомів на сонці або кількість міліметрів до наступної галактики. Чи такі випадки стосуються вашої заявки, залежить від вашої заявки. Якщо ви рахуєте кількість предметів у будь-якому контейнері на вашому складі, 16 біт, ймовірно, буде достатньо. Якщо ви збираєте статистику щодо кількості людей у ​​світі, які відповідають різним умовам, вам потрібно мати можливість записувати мільярди, тож вам знадобиться більше 32 біт, і тоді, ймовірно, вам слід перейти на 64 (як небагато комп'ютерів мають вбудовану підтримку для 37-бітових чисел тощо). Якщо це додаток до хімії, який підраховує молі, які мають значення атомів, 64 біта буде недостатньо.

Технічно, тому, що жоден комп’ютер сьогодні не має 2 ^ 64 байт пам'яті, не обов'язково означає, що індекс масиву ніколи не може бути більше 2 ^ 64. Існує концепція, що називається "розріджений масив", де багато елементів масиву фізично ніде не зберігаються, і такі непотрібні значення мають деяке значення за замовчуванням, як null або zero. Але я припускаю, що якщо ви пишете функцію пошуку масиву чи списку якогось виду, а розмір поля, яке ви використовуєте для утримування індексу в масиві, більше ніж удвічі найбільший можливий адрес, то перевірка на переповнення, коли додавання двох індексів не було б вкрай необхідним.

Нерозумно вважати, що 64-бітове ціле число може містити всі числа. Кілька причин:

1. Максимальне і мінімальне 64-бітове ціле число - кінцеві числа. Для кожного кінцевого числа існує більша і менша кінцева кількість.

2. Розрахунки із 128-бітовими та 256-бітовими числами наразі використовуються в різних місцях. Багато процесорів мають конкретні інструкції, які працюють на 128 бітових цілих числах.

3. 20 років тому диск 1 Гб вважався "великим". Сьогодні диск на 1 ТБ вважається невеликим. 20 років тому середні настільні комп'ютери мали близько 16 Мб оперативної пам’яті. Мій поточний робочий стіл має більше 16 Гб оперативної пам’яті. Простір жорсткого диска та оперативна пам’ять зростали експоненціально в минулому, і прогнозується, що вони будуть експоненціально зростати в майбутньому. Якщо хтось може придумати дуже вагому причину, чому він повинен перестати рости, не має сенсу вважати, що він припиниться.