È ragionevole supporre che qualsiasi quantità fisica possa essere rappresentata da un numero intero a 64 bit senza overflow o underflow?

L'algoritmo di ricerca binaria originale nel JDK utilizzava numeri interi a 32 bit e presentava un bug di overflow se (low + high) > INT_MAX( http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html ) .

Se riscriviamo lo stesso algoritmo di ricerca binaria utilizzando numeri interi (firmati) a 64 bit, possiamo supporre che low + highnon supererà mai INT64_MAX perché è fisicamente impossibile avere 10 ^ 18 byte di memoria?

Quando si utilizzano numeri interi (firmati) a 64 bit per rappresentare quantità fisiche , è ragionevole supporre che il underflow e l'overflow non possano verificarsi?

La risposta breve è no. Tuttavia, per alcune applicazioni il tuo presupposto potrebbe essere corretto.

Supponendo un int firmato, 2 ^ 63, con virgole aggiunte per maggiore chiarezza, = 9.223.372.036.854.775.808. Quindi sono circa 9 * 10 ^ 18. 10 ^ 18 è un "Exa".

Wikipedia dice "A partire dal 2013, si stima che il World Wide Web abbia raggiunto i 4 zettabyte. [12]", ovvero 4000 Exabyte. Pertanto, il WWW è circa 400 volte più grande di 2 ^ 63 byte.

Pertanto, esiste almeno una quantità fisica che è molto più grande di un numero intero a 64 bit con segno (o senza segno). Supponendo che le tue unità siano byte . Se le tue unità fossero qualcosa di molto più grande, come GigaBytes, allora staresti bene, ma la tua precisione di misurazione sarebbe bassa.

Per un altro esempio, considera le galassie lontane. La galassia di Andromeda è in realtà una delle più vicine ed è distante 2,5 * 10 ^ 6 anni luce. Se le tue unità fossero miglia , sarebbe 14,5 * 10 ^ 18, più di un intero con segno a 64 bit. Ora, ovviamente, dipende dalle unità utilizzate per le misurazioni, ma alcune galassie sono molto più lontane di Andromeda. ( Il più noto è a 13 * 10 ^ 9 LY di distanza. ) A seconda della precisione desiderata per la misurazione, potrebbe traboccare un numero intero a 64 bit.

( Aggiunto ) Sì, le miglia sono un'unità schifosa per la distanza astronomica. Un'unità più normale potrebbe essere un'unità astronomica , circa 93 milioni di miglia. Usando quell'unità di misura, la galassia più lontana conosciuta è all'incirca 10 ^ 15 UA (se la mia matematica è corretta), che si adatterebbe a un int a 64 bit. Tuttavia, se si desidera misurare anche la distanza dalla Luna, ai satelliti in orbita vicini, quell'unità è troppo grande.

Un altro esempio dall'elettronica: il Farad (F), un'unità di capacità . I condensatori di grandi dimensioni vanno fino a 5kF. E questo numero probabilmente aumenterà nel tempo man mano che miglioreranno le auto ibride, le "reti intelligenti", ecc. Una volta è possibile misurare capacità fino a 10 ^ -18 F. Quindi l'intervallo complessivo di capacità "reale" che possiamo misurare oggi è 5 * 10 ^ 21, maggiore di un numero intero a 64 bit.

Non è nemmeno necessario diventare cosmici quando è coinvolta la combinatoria. Ci sono 2 ^ 95 possibili offerte in una partita a bridge e questo è un piccolo aspetto della complessità.

La quantità fisica più rilevante per la tua domanda è la RAM del computer .

Windows Server 2012 supporta fino a 4 TB di memoria fisica. Sono 2 ⁴² byte. Se le capacità della RAM continuano a raddoppiare circa ogni anno, tra soli 17 anni "Windows Server 2032" supporterà 2 ⁶² byte di memoria fisica, a quel punto low + highraggiungerai i 2 ⁶³ - 2 e bacerai il numero intero a 64 bit con segno massimo.

Spero che nessun sistema critico per la sicurezza fallisca, avendo assunto 64 bit sarà sempre sufficiente.

Per un uso leggermente più generale, la quantità fisica più rilevante è lo spazio degli indirizzi di memoria . (È utile avere uno spazio di indirizzi molto più ampio rispetto alla memoria fisica, ad esempio per mettere molti stack in memoria, tutti con spazio per crescere.) Le attuali implementazioni x86-64 supportano indirizzi virtuali a 48 bit, quindi abbiamo solo 14 anni prima che queste CPU raggiungano il limite di spazio indirizzo di 2 ⁶² byte.

E poi c'è la memoria condivisa distribuita "dove le memorie (separate fisicamente) possono essere indirizzate come uno spazio di indirizzi (logicamente condiviso)".

È ragionevole supporre che qualsiasi quantità fisica possa essere rappresentata da un numero intero a 64 bit senza overflow o underflow?

Non esattamente. Ci sono molti numeri che sono sia più grandi che più piccoli di quello, motivo per cui abbiamo numeri in virgola mobile. I numeri in virgola mobile compromettono una precisione minore per una migliore portata.

Nell'esempio specifico che hai citato, è altamente improbabile che tu abbia mai bisogno di un numero più grande di quello. 64 bit corrispondono a circa 18 quintilioni di elementi. Ma mai dire mai.

La tua ipotesi non gestirà quantità fisiche che possono essere rappresentate solo da numeri in virgola mobile. E anche se hai deciso di ridimensionare tutti i numeri, diciamo moltiplicando tutti i numeri per 10000 (quindi i valori sono ancora numeri interi ma possono essere rappresentati in diecimila), questo schema fallisce comunque per i numeri molto vicini allo zero, ad esempio la massa elettronica (9.1094 * 10⎻³¹ kg).

Questa è una quantità fisica molto reale (ed estremamente piccola) , eccone alcune con cui avrai problemi. E se pensi che non sia una vera quantità fisica (anche se è in kg), considera:

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

Quindi vedi dove sto andando con questo. L'ultimo che non puoi gestire neanche.

Ovviamente, potresti avere un campo speciale all'interno del numero per ridimensionare una porzione intera su o giù di un moltiplicatore di variabili; Accidenti ora hai appena inventato il virgola mobile.

Innanzitutto risponderei alla domanda quali valori fisici possono / dovrebbero essere rappresentati da un numero intero?

Integer è una rappresentazione di un numero naturale (e differenze tra loro) in un sistema informatico, quindi applicarlo a qualsiasi altra cosa è sbagliato. Pertanto, invocare distanze o altre quantità che appartengono al dominio continuo non è un argomento. Per tali quantità ci sono rappresentazioni di numeri reali. E puoi sempre scegliere un'unità arbitrariamente grande e adattare qualsiasi valore con una data precisione.

Quindi quali sono i valori fisici che sono numeri naturali e possono traboccare a 64 bit interi?

Mi vengono in mente due. Numero di oggetti fisici (come gli atomi) e livelli di energia in cui può trovarsi un sistema quantistico. Queste sono due cose che sono rigorosamente intere. Ora so che puoi dividere un atomo, ma produce comunque un numero intero e non puoi dividerlo indefinitamente. Entrambi possono facilmente superare l'intervallo a 64 bit dell'intero senza segno . Il numero di atomi è più alto e un atomo può trovarsi in più di uno stato di energia.

Che le informazioni siano fisiche o meno, è molto discutibile. Direi di no. Pertanto, non direi che la quantità di informazioni è una cosa fisica. Quindi non è la quantità di RAM o qualcosa del genere. Se lo permetti, allora il numero di atomi supera facilmente questo numero, perché hai bisogno di più di un atomo per memorizzare un bit con la tecnologia di oggi.

Oltre alla risposta di Jerry101, vorrei offrire questo test molto semplice e pratico per la correttezza:

Supponiamo di allocare un po 'di memoria tramite malloc, in un sistema operativo a 64 bit. Supponiamo che l'allocatore di memoria decida di restituirti un blocco di memoria valido, della dimensione richiesta, ma in cui è impostato il 63 ° bit.

In altre parole, supponiamo che esistano alcuni ambienti di programmazione in cui vi 0xFFFFFFFFxxxxxxxxsono intervalli di memoria legittimi che potrebbero essere restituiti da una chiamata a malloc.

La domanda è: il tuo codice continuerà a funzionare come previsto?

Quando la situazione analoga si verifica con i sistemi operativi a 32 bit, alcuni software non funzionavano correttamente se venivano assegnati indirizzi di memoria "nella metà superiore". Inizialmente, si riteneva che tali indirizzi di memoria fossero disponibili solo per il codice privilegiato (sistemi operativi, driver di dispositivo e hardware periferico), ma a causa della crisi dello spazio degli indirizzi a 32 bit, i fornitori di sistemi operativi hanno deciso di rendere disponibile parte dello spazio riservato a applicazioni che lo richiedono.

Fortunatamente, è improbabile che questa situazione si verifichi per programmi a 64 bit per un po ', almeno non tra un decennio.

Quando finalmente si verificherà tale situazione, significa che i processori e i sistemi operativi indirizzabili a 128 bit sarebbero diventati ormai mainstream e che sarebbero in grado di fornire un "ambiente di emulazione a 64 bit" per consentire a quelle "applicazioni legacy" di funzionare sotto ipotesi simili ai sistemi operativi a 64 bit di oggi.

Infine, nota che questa discussione si concentra solo sugli indirizzi di memoria. Un problema simile con i timestamp deve essere preso con più precauzioni, perché alcuni formati di timestamp assegnano molta precisione ai microsecondi e quindi lasciano meno bit disponibili per rappresentare il tempo in futuro. Questi problemi sono riassunti nell'articolo di Wikipedia sul problema dell'anno 2038 .

Questa è una domanda che devi porre caso per caso. Non dovresti usare un'ipotesi generale che l'aritmetica a 64 bit non trabocchi, perché anche quando le quantità corrette saranno in un intervallo molto più piccolo, un'origine dati dannosa potrebbe finire per darti quantità irragionevoli che potrebbero traboccare, ed è meglio essere preparato per questa situazione piuttosto che colpirla inaspettatamente.

Ci sono alcuni casi in cui ha senso scrivere codice che dipende dal non overflow di numeri a 64 bit. La principale classe di esempio che conosco sono i contatori, in cui il contatore viene incrementato ogni volta che viene utilizzato. Anche al ritmo di un incremento per nanosecondo (non pratico) ci vorrebbe più di un secolo per traboccare.

Si noti che sebbene all'inizio possa sembrare "sempre errato in linea di principio" basarsi sul "tempo fino al fallimento" per la correttezza di un sistema, lo facciamo sempre con autenticazione / accesso. Dato un tempo sufficiente (per la forza bruta), tale sistema (basato su password, chiavi private, token di sessione, ecc.) Viene interrotto.

È POSSIBILE che una quantità fisica non si adatti a 64 bit? Ovviamente. Altri hanno sottolineato contando il numero di atomi nel sole o il numero di millimetri nella galassia successiva. Se tali casi sono rilevanti per la tua applicazione dipende da quale sia la tua domanda. Se stai contando il numero di articoli in un dato cestino del tuo magazzino, probabilmente 16 bit sarebbero sufficienti. Se stai compilando statistiche sul numero di persone nel mondo che soddisfano varie condizioni, devi essere in grado di registrare miliardi, quindi avrai bisogno di più di 32 bit, a quel punto presumibilmente andresti a 64 (come pochi computer supporto integrato per numeri a 37 bit, ecc.). Se questa è un'applicazione chimica che conta moli di atomi, 64 bit non saranno sufficienti.

Tecnicamente, solo perché oggi nessun computer ha 2 ^ 64 byte di memoria non significa necessariamente che un indice di array non possa mai essere più di 2 ^ 64. Esiste un concetto chiamato "array sparse" in cui molti degli elementi dell'array non vengono archiviati fisicamente da nessuna parte e si presume che tali valori non memorizzati abbiano un valore predefinito come null o zero. Ma suppongo che se stai scrivendo una funzione per cercare un array o un elenco di qualche tipo, e la dimensione del campo che stai usando per contenere l'indice nell'array è più del doppio dell'indirizzo più grande possibile, quindi controlla l'overflow quando l'aggiunta di due indici non sarebbe strettamente necessaria.

È irragionevole supporre che un numero intero a 64 bit possa contenere tutti i numeri. Motivi multipli:

1. Il numero intero massimo e minimo a 64 bit sono numeri finiti. Per ogni numero finito esiste un numero finito sempre più grande.

2. I calcoli con numeri a 128 bit e 256 bit sono attualmente utilizzati in vari punti. Molti processori hanno istruzioni specifiche che funzionano su numeri interi a 128 bit.

3. 20 anni fa, un disco da 1 GB era considerato "grande". Oggi un disco da 1 TB è considerato piccolo. 20 anni fa i desktop medi avevano circa 16 MB di RAM. Il mio desktop attuale ha più di 16 GB di RAM. Lo spazio su disco rigido e la RAM sono cresciuti esponenzialmente in passato e si prevede che cresceranno esponenzialmente in futuro. A meno che qualcuno non riesca a trovare una buona ragione per cui dovrebbe smettere di crescere, non ha senso supporre che si fermerà.