Qualcuno ha detto quanto segue:

Chiunque tenti di generare numeri casuali con mezzi deterministici, ovviamente, vive in uno stato di peccato.

Questo significa sempre che non puoi generare veri numeri casuali con un solo computer. E ha detto che quando i computer avevano le dimensioni equivalenti di un singolo microprocessore Intel 8080 (~ 6000 valvole). I computer sono diventati più complessi e credo che l'affermazione di von Von Neumann potrebbe non essere più vera. Considera che un algoritmo solo software implementato è impossibile. Funzionano su hardware fisico. I veri generatori di numeri casuali e le loro fonti di entropia sono anch'essi fatti di hardware.

Questo frammento Java inserito in un ciclo:

      file.writeByte((byte) (System.nanoTime() & 0xff));

posso creare un file di dati che ho rappresentato come immagine:

Puoi vedere la struttura, ma anche con molta casualità. La cosa interessante è che questo file PNG ha una dimensione di 232 KB, ma contiene 250.000 pixel in scala di grigi. Il livello di compressione PNG era massimo. Questo è solo un rapporto di compressione del 7%, vale a dire. abbastanza non comprimibile. La cosa interessante è anche che il file è unico. Ogni generazione di questo file ha uno schema leggermente diverso e ha una comprimibilità del ~ 7% simile. Lo sottolineo poiché è fondamentale per il mio argomento. Entropia di ~ 7 bit / byte. Ciò si ridurrà ovviamente con l'uso di un algoritmo di compressione più forte. Ma non ridurre a nulla vicino a 0 bit / byte. Un'impressione migliore può essere ottenuta prendendo l'immagine sopra e sostituendo la sua mappa dei colori con una casuale:

La maggior parte della struttura (nella metà superiore) scompare in quanto erano solo sequenze di valori simili ma leggermente diversi. È una vera fonte di entropia creata semplicemente eseguendo un programma Java su un sistema operativo multi-acquisizione? Non un generatore di numeri casuali distribuito uniformemente, ma la fonte entropica per uno? Una fonte entropica costruita con software in esecuzione su hardware fisico che sembra essere un PC.

Supplemental

Per confermare che ogni immagine genera una nuova entropia senza uno schema fisso comune a tutti, sono state generate 10 immagini consecutive. Questi sono stati quindi concatenati e compressi con l'archiviatore più potente che riesco a compilare (paq8px). Questo processo eliminerà tutti i dati comuni, inclusa la correlazione automatica, lasciando solo le modifiche / entropia.

Il file concatenato è stato compresso al ~ 66%, il che porta a una velocità di entropia di ~ 5,3 bit / byte o 10,5 Mbit / immagine. Una sorprendente quantità di entropia$\smile$

Supplemento 2

Ci sono stati commenti negativi sul fatto che la mia entropia con la metodologia del test di compressione è difettosa, dando solo una stima libera del limite superiore. Quindi ora ho eseguito il file concatenato attraverso il test di valutazione dell'entropia crittografica ufficiale del NIST, SP800-90B_EntropyAssessment . Questo è buono come si ottiene per la misurazione dell'entropia non IID. Questo è il rapporto (scusate se questa domanda si sta allungando, ma il problema è complesso): -

Running non-IID tests...

Entropic statistic estimates:
Most Common Value Estimate = 7.88411
Collision Test Estimate = 6.44961
Markov Test Estimate = 5.61735
Compression Test Estimate = 6.65691
t-Tuple Test Estimate = 7.40114
Longest Reapeated Substring Test Estimate = 8.00305

Predictor estimates:
Multi Most Common in Window (MultiMCW) Test: 100% complete
    Correct: 3816
    P_avg (global): 0.00397508
    P_run (local): 0.00216675
Multi Most Common in Window (Multi MCW) Test = 7.9748
Lag 

Test: 100% complete
    Correct: 3974
    P_avg (global): 0.00413607
    P_run (local): 0.00216675
Lag Prediction Test = 7.91752
MultiMMC Test: 100% complete
    Correct: 3913
    P_avg (global): 0.00407383
    P_run (local): 0.00216675
Multi Markov Model with Counting (MultiMMC) Prediction Test = 7.9394
LZ78Y Test: 99% complete
    Correct: 3866
    P_avg (global): 0.00402593
    P_run (local): 0.00216675
LZ78Y Prediction Test = 7.95646
Min Entropy: 5.61735

Il risultato è che NIST ritiene di aver generato 5,6 bit / byte di entropia. La mia stima della compressione fai-da-te lo mette a 5,3 bit / byte, leggermente più conservativo.

-> Le prove sembrano supportare l'idea che un computer che esegue software può generare vera entropia. E che von Neumann aveva torto (ma forse corretto per il suo tempo).

Offro i seguenti riferimenti che potrebbero supportare la mia richiesta:

Esistono modelli stocastici di non determinismo nel tasso di esecuzione del programma?

Analisi WCET di sistemi probabilistici duri in tempo reale

Esiste un algoritmo software in grado di generare un modello di caos non deterministico? e la rilevanza degli effetti caotici.

Parallelamente al principio di incertezza entropica quantistica

Il blog di Aleksey Shipilёv sul comportamento caotico di nanoTime (). La sua trama sparsa non è diversa dalla mia.

Solo perché non riesci a vedere uno schema non significa che non esiste uno schema. Solo perché un algoritmo di compressione non riesce a trovare un pattern non significa che non esiste alcun pattern. Gli algoritmi di compressione non sono proiettili d'argento che possono magicamente misurare la vera entropia di una fonte; tutto ciò che ti danno è un limite superiore alla quantità di entropia. (Allo stesso modo, il test NIST ti dà anche solo un limite superiore.) Il caos non è casualità.

Ci vuole un'analisi e un esame più dettagliati per iniziare ad avere una certa fiducia nella qualità della casualità ottenuta in questo modo.

Ci sono ragioni per pensare che probabilmente possiamo ottenere una certa casualità sfruttando il jitter del clock e la deriva tra due clock hardware , ma è delicato e complicato, quindi devi stare attento. Non consiglierei di provare a implementare il tuo. Invece, suggerirei di utilizzare una fonte di entropia di alta qualità (di solito implementata nella maggior parte dei sistemi operativi moderni). Per maggiori dettagli, vedi anche Wikipedia , hasged e /crypto//q/48302/351 (di cui sembra che tu sia già a conoscenza).

Infine, un commento sul tuo apri:

"Chiunque tenti di generare numeri casuali con mezzi deterministici, ovviamente, vive in uno stato di peccato".

Questo significa sempre che non puoi generare veri numeri casuali con un solo computer.

No, non è così che di solito viene preso, e non è quello che sta dicendo. Sta dicendo che non puoi generare veri numeri casuali con mezzi deterministici . La possibilità di farlo su un computer dipende dal fatto che il computer sia deterministico o meno. Se il computer è deterministico o il tuo programma utilizza solo operazioni deterministiche, non puoi. Tuttavia, molti computer contengono elementi non deterministici e, se il programma li utilizza, è necessaria un'analisi più dettagliata prima di poter decidere se possono essere utilizzati per generare numeri casuali. Nel tuo caso nanoTime()non è deterministico.

Se stai usando una fonte hardware di entropia / casualità, non stai "tentando di generare casualità con mezzi deterministici " (la mia enfasi). Se non stai usando alcuna fonte hardware di entropia / casualità, un computer più potente significa solo che puoi commettere più peccati al secondo.

Ho sempre capito che la citazione significa che un algoritmo deterministico ha una quantità fissa di entropia e sebbene l'output possa apparire "casuale" non può contenere più entropia di quanto gli input forniscano. Da questo punto di vista, vediamo che il tuo algoritmo contrabbanda nell'entropia attraverso System.nanoTime()- la maggior parte delle definizioni di un algoritmo "deterministico" non consentirebbe di chiamare questa funzione.

La citazione - mentre pithy - è essenzialmente una tautologia. Non c'è nulla da confutare e non è possibile alcuna evoluzione dell'hardware che possa renderlo non più vero. Non si tratta di hardware, si tratta della definizione di un algoritmo deterministico. Sta semplicemente osservando che determinismo e casualità sono incompatibili. Per qualsiasi algoritmo deterministico, il suo intero comportamento è previsto dalle sue condizioni iniziali. Se pensi di aver trovato un'eccezione, stai fraintendendo cosa significa essere deterministici.

È vero che un processo in esecuzione su un computer condiviso con una serie complessa di cache e che riceve vari input di rete e hardware ha accesso a molta più entropia rispetto a uno in esecuzione su hardware semplice, isolato e dedicato. Ma se quel processo accede a quell'entropia non è più deterministico e quindi la citazione non si applica.

Chiunque tenti di generare numeri casuali con mezzi deterministici, ovviamente, vive in uno stato di peccato.

Quando interpreti "vivere in uno stato di peccato" come "fare una sciocchezza", allora è perfettamente giusto.

Quello che hai fatto è stato usare un metodo piuttosto lento System.nanoTime()per generare casualità piuttosto deboli. Ne hai misurato un po '

... tasso di entropia di ~ 5,3 bit / byte ...

ma questo è solo il limite superiore. Tutto quello che puoi mai ottenere è un limite superiore. La vera entropia può essere ordini di grandezza più piccoli.

Prova invece a riempire l'array usando un hash crittografico come MD5. Calcola una sequenza come md5(0), md5(1), ...(da ogni valore preso uno o più byte, questo non ha importanza). Non otterrai alcuna compressione (sì, MD5 è rotto, ma comunque abbastanza buono da produrre dati incomprimibili).

Possiamo dire che non c'è affatto entropia, eppure misurereste 8 bit / byte.

Quando hai davvero bisogno di qualcosa di casuale, non solo devi usare una fonte HW, ma devi anche conoscere un limite sicuramente inferiore a quanta entropia produce davvero. Mentre molto probabilmente c'è una certa casualità nanoTime(), non sono a conoscenza di alcun limite inferiore non banale.

Quando hai bisogno di casualità per la crittografia, devi davvero ricorrere a qualcosa fornito dal tuo sistema operativo, dalla tua lingua o da una buona libreria. Tali fornitori raccolgono entropia da più fonti e / o HW dedicati e un bel po 'di lavoro è stato dedicato a tali stime entropiche.

Nota che di solito non hai bisogno di entropia. Un buon PRNG (deterministico) inizializzato con pochi byte casuali è utilizzabile per la crittografia, e quindi anche per tutto il resto.

Ho pensato di entrare nel significato di "casuale". La maggior parte delle risposte qui parla dell'output di processi casuali , rispetto all'output di processi deterministici. Questo è un significato perfettamente buono di "casuale", ma non è l'unico.

Un problema con l'output di processi casuali è che sono difficili da distinguere dagli output di processi deterministici: non contengono un "record" di quanto casuale sia stata la loro fonte. Un esempio estremo di questo è un famoso fumetto XKCD in cui ritorna sempre un generatore di numeri casuali 4, con un commento in codice che afferma che è casuale perché proviene da un tiro di dado.

Un approccio alternativo alla definizione di "casualità", chiamato complessità di Kolmogorov , si basa sui dati stessi, indipendentemente da come sono stati generati. La complessità di Kolmogorov di alcuni dati (ad esempio una sequenza di numeri) è la lunghezza del programma per computer più breve che emette tali dati: i dati sono "più casuali" se hanno una complessità di Kolmogorov più alta.

L'uso di algoritmi di compressione come PNG e il confronto della lunghezza prima e dopo la compressione è simile all'idea della complessità di Kolmogorov. Tuttavia, la complessità di Kolmogorov consente di codificare i dati come programma in qualsiasi linguaggio di programmazione completo di Turing, piuttosto che in un formato limitato come PNG; "decomprimere" tali codifiche (programmi) viene eseguita eseguendole, il che può richiedere una quantità arbitraria di tempo e memoria (ad es. più di quanto sia disponibile nel nostro universo impertinente).

Il teorema di Rice ci dice che non possiamo, in generale, distinguere tra programmi che si ripetono per sempre e programmi che producono i nostri dati. Quindi è molto difficile trovare la complessità di Kolmogorov di alcuni dati: se scriviamo un programma che genera tali dati, potrebbe effettivamente esserci un programma più breve (cioè una complessità inferiore), ma non lo individuiamo perché non potremmo distinguilo da un ciclo infinito. La complessità di Kolmogorov è quindi incontestabile, sebbene se conoscessimo i numeri di Busy-Beaver potremmo calcolarli usando quelli per limitare il tempo che controlliamo ogni programma.

Nel caso dei tuoi dati di esempio, per trovare la sua complessità di Kolmogorov (cioè "casualità intrinseca") avremmo bisogno di trovare il programma deterministico più breve che emetta la stessa sequenza di byte e prendere la sua lunghezza.

Ora possiamo rispondere alla tua domanda dal punto di vista della complessità di Kolmogorov e scopriamo che la citazione è corretta: non possiamo generare numeri casuali (elevata complessità di Kolmogorov) con mezzi deterministici.

Perchè no? Immaginiamo di scrivere un piccolo programma per computer e di usarlo per generare una sequenza di numeri casuali. È necessario applicare una delle seguenti situazioni:

• Generiamo una grande quantità di output. Tuttavia, poiché sappiamo che questo output è generato da un piccolo programma, l'output (per definizione) ha una bassa complessità di Kolmogorov, e quindi non è "casuale" in questo senso.
• Generiamo così pochi numeri che scrivere tutti li richiederebbe più o meno gli stessi bit che scrivere il nostro programma di generazione breve. In questo caso, i numeri sono relativamente incomprimibili, il che indica che sono abbastanza casuali nel senso di Kolmogorov. Tuttavia, poiché la quantità di output è paragonabile a ciò che abbiamo inserito (il codice sorgente per il programma), è giusto dire che il programma non ha "generato" la casualità, lo abbiamo fatto scegliendo quel programma. Dopotutto, in questo caso il nostro programma di generazione potrebbe anche essere stato un elenco di questi numeri esatti (ad es print([...]).).

In entrambi i casi, non stiamo "generando" una casualità maggiore di quella che inseriamo (la "casualità" del codice sorgente del nostro programma di generazione). Potremmo provare a aggirare questo problema usando un programma di generazione più lungo, per evitare che l'output abbia un generatore corto, ma ci sono solo due modi per farlo:

• "Gonfia" sistematicamente il codice in qualche modo. Tuttavia, alla complessità di Kolmogorov non interessa il particolare programma che abbiamo usato per generare i dati: si preoccupa solo di qualsiasi programma di generazione sia il più piccolo. Il gonfiore sistematico non aggiunge complessità di Kolmogorov, poiché tali schemi nel codice possono essere generati da soli con una quantità molto piccola di codice. Ad esempio, se prendiamo run(shortGenerator)e aggiungiamo un intero carico di gonfiamento sistematico da ottenere run(bloatedGenerator), esiste ancora un breve generatore del modulo run(addBloat(shortGenerator)).
• Aggiungi bloat in modo non sistematico , cioè senza alcun pattern, in modo che una addBloatfunzione debba finire per essere gonfiata come il codice stesso. Tuttavia, essere così privo di schemi è esattamente ciò che rende qualcosa di casuale (elevata complessità di Kolmogorov). Quindi gonfiore del programma di generazione in questo modo non aumentare la casualità (Kolmogorov complessità) dell'uscita, ma anche aumenta la quantità di casualità (Kolmogorov complessità) che dobbiamo fornire sotto forma di codice sorgente. Quindi siamo ancora noi a fornire la "casualità" e non il programma. Nell'esempio sopra di solo scrivere print([...]), aggiungere un bloat non sistematico equivale a scrivere più numeri "casuali" in quell'elenco hardcoded.

La compressione non è un test accurato di casualità, né guarda un'immagine e dice "sembra casuale".

La casualità è testata con metodi empirici . Esistono infatti suite di software / algoritmi appositamente progettati per testare la casualità, ad esempio TestU01 e i test Diehard .

Inoltre, la tua immagine è in realtà una stringa 1D di numero mappata su uno spazio, e quindi non è una buona rappresentazione di alcuni schemi che possono apparire.

Se dovessi esaminare l'immagine pixel per pixel, molto probabilmente troverai molti brevi schemi di valore crescente prima di un calo improvviso. Se dovessi creare un grafico con il valore x come numero di campione e il valore y come valore ottenuto dalla funzione 'random', molto probabilmente scopriresti che i tuoi dati sembrano effettivamente un'onda a dente di sega:

Questo è il modello creato da valori che aumentano sotto l'aritmetica modulare (di cui il tuo calcolo è un esempio di: tempo che aumenta a un ritmo quasi costante e & 0xFFazione come mod 256).

Stai confondendo il concetto di numeri casuali da "numeri che sembrano essere casuali".

Per capire la citazione di von Neumann, dobbiamo capire cosa significa "generare numeri casuali". La risposta di Warbo collega un eccellente XKCD a questo scopo:

Quando parliamo di numeri casuali, non stiamo parlando dei valori stessi. Ovviamente un 4 non è più casuale di un 3. Stiamo parlando della capacità di una terza parte di prevedere questo valore meglio di una casualità. Un numero casuale è uno che non è prevedibile. A volte aggiungeremo condizioni a questo. Un generatore di numeri pseudo-casuali sicuro (CSPRNG) crittograficamente sicuro genera numeri che non possono essere previsti bettr che probabilità casuali se un attaccante non conosce il seme / chiave, ma se stiamo parlando di numeri veramente casuali (non pseudo-casuali), di solito è definito come un numero che non è prevedibile, anche con una conoscenza completa del sistema, comprese eventuali chiavi.

Ora, il tuo esempio, come molti hanno sottolineato, non è deterministico. Il programma non specifica da quale valore esce System.nanoTime(). Quindi non è nella stessa classe dell'utilizzo di un CSPRNG per generare numeri pseudo casuali. Il primo può essere non deterministico mentre il secondo è deterministico se il valore della chiave è deterministico. Il primo contiene operazioni che non sono definite per avere valori deterministici.

Tuttavia, noterai che ho detto che potrebbe non essere deterministico. Tenere presente che System.nanoTime()non è progettato per fornire valori a questo scopo. Può essere o non essere sufficientemente non deterministico. Un'applicazione potrebbe regolare l'orologio di sistema in modo tale che tutte le chiamate si System.nanoTime()verifichino su multipli di 256 nanosecondi (o chiusura). Oppure potresti lavorare in Javascript, dove i recenti exploit di Spectre hanno portato i principali browser a ridurre intenzionalmente la risoluzione dei loro timer. In questi casi, i tuoi "numeri casuali" possono diventare altamente prevedibili in ambienti che non avevi pianificato.

• Quindi generare numeri casuali con processi deterministici ... peccato.
• Generazione di numeri casuali con hardware casuale dedicato ... non peccato.
• Generare numeri casuali con aspetti non deterministici dei computer ... forse peccato.

Tutto dipende da ciò che intendi. Se stai crittografando le tue lettere d'amore a Sponge Bob in modo che tua sorella non possa leggerle, le richieste poste sui tuoi cosiddetti numeri casuali sono piuttosto basse. System.nanoTime()usato come hai fatto è probabilmente abbastanza buono. Se stai proteggendo i segreti nucleari da uno stato straniero avanzato che li sta attivamente cercando, potresti prendere in considerazione l'uso di hardware progettato per essere all'altezza della sfida.

Non credo che tu abbia capito l'affermazione. Il punto è che se esiste una procedura deterministica per generare una serie di numeri "casuali" (o qualcosa del genere), trovare il modello è semplicemente il compito di trovare questa procedura!

Quindi, esiste sempre un metodo deterministico per prevedere il numero intero successivo. Questo è esattamente ciò che non ci aspettiamo che accada se assumiamo casualità!

Qualsiasi determinismo sufficientemente complesso è indistinguibile dalla stocastica.

- Dalla pagina utente di Wrzlprmft

Quindi, anche se qualcosa sembra casuale, perché mai dovremmo modellarlo come 'casuale' se avessimo una procedura deterministica per generarlo?

Questo, penso, è il problema chiave. Hai mostrato solo una qualche forma di indistinguibilità del PRNG e "vera casualità".

Tuttavia, il fatto che questi concetti siano uguali non segue. In particolare, la casualità è un concetto matematico e teorico . Abbiamo già dimostrato sopra, che in teoria, considerare il PRNG come "vera casualità" porta a una contraddizione. Quindi, non possono essere uguali.

Penso che altri lo abbiano già sottolineato, ma non era questo che sottolinea, quindi vorrei aggiungere anche alla discussione.

Come altri hanno già sottolineato, c'è il problema di misurare l'entropia. Gli algoritmi di compressione possono dirti qualcosa, ma sono indipendenti dalla fonte. Dato che sai di più su come sono stati generati i dati, probabilmente potresti costruire un algoritmo molto migliore per comprimerlo, e ciò significa che l'entropia reale è molto più bassa.

Inoltre, stai in qualche modo confondendo i significati delle frasi "sul computer" e "deterministico". È certamente possibile eseguire operazioni non deterministiche sul computer.

Inoltre, in effetti, l' hai appena fatto , ma non è così evidente a prima vista.

Un tipico algoritmo deterministico per una generazione di numeri casuali è cioè. PRNG come generatore congruenziale lineare. Sono di stato. Lo stato interno significa meno entropia poiché lo stato successivo è determinato dal precedente. Non approfondirò questo, probabilmente è ovvio per te. Il punto importante è che l'algoritmo completamente deterministico dipende solo dallo stato precedente, qualunque esso sia.

Ora guarda il tuo algoritmo. Su cosa si basa? Quanto stato hai? È deterministico?

  file.writeByte((byte) (System.nanoTime() & 0xff));

Ignoriamo file.writee qualsiasi problema di svuotamento dei buffer, in attesa di I / O (hai provato ad aggiungere un forte rumore sui cavi del disco rigido per un momento? No? Ehi, potresti farlo. Ehi, non è deterministico allora! :)) e concentriamoci sulla fonte, è più importante.

Il tempo è una specie di stato. Varia, ma la maggior parte è la stessa. Ecco perché hai tentato di aggirarlo e hai impiegato & 0xFF per eliminare la maggior parte dello stato. Ma non hai lasciato cadere tutto, alcuni stati della lettura precedente potrebbero passare a quello successivo, quindi non è certamente del tutto non deterministico *)

Ma non ci interessa. Per "provare" che la citazione è sbagliata:

Chiunque tenti di generare numeri casuali con mezzi deterministici, ovviamente, vive in uno stato di peccato.

Devi dimostrarlo con mezzi deterministici.
Ciò che ci interessa è: il tuo algo è sicuramente del tutto deterministico ?

..e è ovvio che non lo è.

  System.nanoTime() & 0xff

Questa è una misurazione del tempo. Tempo e misurazione . La parte di misurazione può renderla deterministica, se il valore viene memorizzato nella cache. Suppongo che non lo sia, altrimenti questa funzione non avrebbe senso. Quindi, se viene letto al volo dalla fonte, abbiamo un valore basato sul tempo. Dato che ( suppongo di nuovo ) non l'hai eseguito su un hardware dedicato a singola attività, a volte potresti avere il kick-switch di cambio di contesto. Anche se si disponesse di un hardware dedicato a singola attività, la misurazione del tempo potrebbe non essere deterministica, a causa delle variazioni di temperatura / umidità nella sorgente del tempo, dei tempi di clock del bus, ecc.

Sono totalmente d'accordo che sto esagerando qui. Le derive non saranno così grandi da avere un grande impatto (anche se per davvero nanotimepotrebbero essere). Ancora più importante, nanotimeè pensato per essere veloce. Non legge dalla fonte in tempo reale. Si basa sul conteggio interno delle istruzioni / del ciclo del processore. Questo è in realtà deterministico, se non si garantisce alcun cambio di contesto.

Il mio punto è che in realtà potrebbe essere molto difficile eseguire un algoritmo deterministico veramente al 100% se lo si basa sul tempo e non si ha il diritto di confutare quella citazione a meno che non si disponga di mezzi completamente deterministici.

*) È interessante notare che probabilmente potresti aumentare la casualità effettiva se vai nel modo più duro. Esegui & 0x01, bit per bit, e attendi il thread un tempo evidente, prima di leggere ogni bit. La generazione di dati in questo modo sarebbe ridicolmente lunga, ma in realtà direi che potrebbe essere considerata quasi casuale, IIF che stai eseguendo su non-RTOS e anche IFF in ogni "tempo evidente" è abbastanza alto da garantire che Il sistema operativo è andato in sospensione o è passato al contesto in un'altra attività.

Penso che la risposta di cui hai bisogno inizi con questo commento che tu stesso hai fatto in risposta a un'altra risposta:

Il modello è il risultato dell'interazione di Java, JVM, sistema operativo, CPU + cache, disco rigido, musica Trance che stavo trasmettendo in streaming che consuma cicli CPU / RAM e tutto il resto. Il modello deriva semplicemente dall'unica riga del codice Java all'interno di un ciclo for / next. Una parte significativa dell'entropia viene dai circuiti hardware sottostanti.

Lo capisci già, penso: non hai usato mezzi deterministici per creare il modello.

Hai usato un computer, una parte non trascurabile di cui è deterministica, ma l'entropia proveniva da fonti esterne non deterministiche (o almeno non deterministiche per tutti gli scopi pratici al momento): tu o il mondo esterno che interagite con il computer (e, in misura minore, eventuali imperfezioni fisiche nell'hardware del computer che potrebbero influire sui tempi delle cose).

Questo, tra l'altro, è una grande parte di come i moderni sistemi operativi seminano i loro generatori di numeri casuali disponibili per i programmi: sfruttando l'entropia nelle interazioni con il suo hardware e l'utente che speriamo non siano prevedibili per un attaccante.

A proposito, l'entropia del mondo esterno è in realtà un problema che deve essere affrontato fino ad oggi nella crittografia altrimenti ben codificata: computer che hanno comportamenti prevedibiliall'avvio e durante il loro runtime, come quelli con memoria di sola lettura o che si avviano dalla rete e che hanno un ambiente di rete prevedibile (o non collegato a una rete o il carico di lavoro sulla rete è abbastanza basso da consegnare tutto all'interno un periodo di tempo affidabile) e che eseguono lo stesso insieme limitato di software con un comportamento approssimativamente coerente, potrebbero sovrastimare gravemente l'entropia che stanno ottenendo da questi componenti considerati imprevedibili e finire per generare numeri molto più prevedibili di quanto ti aspetteresti su una tipica postazione di lavoro che sta facendo ogni sorta di altre cose per te (streaming di musica, sincronizzazione con dropbox, qualunque cosa) in background.

Penso che la maggior parte delle risposte si stiano concentrando sul fatto che controllare gli ultimi otto bit di misurazioni del tempo in nanosecondi prese in un ciclo sia un buon modo per raccogliere quell'entropia. Questa è una domanda molto importante a cui rispondere correttamente prima di usare il metodo nel tuo esempio come uno schema di generazione di numeri casuali in pratica , ma è una domanda separata da ciò che penso tu stia chiedendo.

Per aggiungere alle risposte precedenti, ecco un modo semplice di pensare a questa domanda.

Riguarda la differenza tra casuale e deterministico . Verremo da Von Neumann e da quello che stava dicendo in seguito.

Numeri casuali

Un vero generatore di numeri casuali non avrebbe alcun modello, nemmeno nascosto nello sfondo, che potremmo usare per prevedere il numero successivo data la sequenza finora. In un mondo ideale, potresti sapere tutto quello che c'è da sapere nell'universo fisico e sul sistema, nanosecondo per nanosecondo, e sarebbe comunque inutile provare a prevedere il prossimo numero prodotto.

Questo è un caso ideale: in termini pratici ci arriviamo mescolando insieme molte fonti che sono "approssimazioni non cattive" a casuali, o che sono veramente casuali, o che mescolano matematicamente le cose abbastanza da poter dimostrare matematicamente che si avvicinano molto a imprevedibili e mancanza di parzialità verso numeri o schemi specifici.

• Le fonti "buone" sono cose simili all'attesa di un processo di decadimento radioattivo o di altro processo quantico intrinsecamente imprevedibile. Uscita da un semiconduttore sensibile al calore. Rumore casuale in un diodo o altro materiale elettrico. Contando i fotoni dal sole.

• Mescolato in questo, possiamo anche aggiungere alcuni che consideriamo "non male" che aiutano in quanto non hanno alcuna connessione a questi: in attesa del prossimo clic del mouse o pacchetto di rete. Ultimo bit di microtime sulla scrittura del file successivo. Uscita di una funzione di generatore di numeri pseudocasuali "nota ma matematicamente piuttosto casuale". Entropia precedente da precedenti usi di numeri casuali.

Lo scopo qui è quello di ottenere un numero che non è ancora possibile prevedere , qualunque cosa nell'universo che conosci , ed è statisticamente più probabile che sia questo come quello, senza schemi, pregiudizi o prevedibilità matematicamente rilevabili e nessuna correlazione con un evento che potrebbe essere monitorato e utilizzato per la previsione. (O se correlato a un evento, viene eseguito in modo da rendere la connessione incredibilmente tenue, come "la cifra dei nanosecondi del tempo dell'ultimo clic del mouse")

Numeri deterministici

I matematici possono provare cose su formule e funzioni. Quindi è possibile dimostrare che una funzione, quando viene chiamata ripetutamente, non dà alcun bias o preferenza a nessun modello, oltre al modello semplice "questi sono gli output di quella funzione se chiamati ripetutamente".

Quindi, per esempio, se scegli un numero tra 1 e 10 milioni, scrivilo in binario e "hash" ripetutamente, otterrai una sequenza di cifre dall'aspetto piuttosto casuale. È quasi casuale, ma in realtà non è affatto casuale. Puoi prevedere dato l'algoritmo e qualsiasi stato, quale sarà il prossimo numero.

Lo chiamiamo "pseudocasuale" perché sembra e sembra essere principalmente casuale, anche se non lo è.

Ecco un buon esempio. Pensa a questa sequenza di "numeri casuali" a 3 cifre: 983, 367, 336, 244, 065, 664, 308, 602, 139, 494, 639, 522, 473, 719, 070, 217. Diciamo che ti dico Posso generare un milione di numeri allo stesso modo. Puoi quindi passare a uno statistico che confermerà (diciamo) che sono distribuiti equamente o qualunque cosa sia. Non esiste un modello prevedibile ovvio. Sembrano piuttosto casuali, giusto? Ma ora ti dico che lo sono davvero

la 500a + cifra di Pi, raggruppata in 3 secondi.

Improvvisamente, per quanto casuale il

cifre di Pi

può essere, puoi immediatamente prevedere che i prossimi 2 numeri saranno 986 e 094.

Per essere chiari, non so esattamente quanto sia casuale

cifre di Pi

siamo. Sarà stato studiato e la risposta ben nota. Ma il punto è questo: in linea di principio, la stessa conclusione è vera per qualsiasi fonte prodotta seguendo un processo deterministico .

Nel mezzo

Tra i due, ci sono tutta una serie di "cose ​​che sembrano casuali e sono spesso casuali in una certa misura". Maggiore è la casualità e quasi la casualità che si possono mescolare, minore è la tendenza all'output di poter rilevare matematicamente qualsiasi modello o qualsiasi output previsto.

Torna a von Neumann e alla tua domanda

Come puoi vedere, gli output deterministici potrebbero apparire casuali, ma potrebbero anche, statisticamente, essere distribuiti casualmente. Potrebbero persino utilizzare dati "segreti" o in rapida evoluzione che non abbiamo realistiche speranze di conoscere. Ma finché è deterministico, i numeri non possono mai essere veramente casuali . Possono solo essere "abbastanza vicini al caso che siamo felici di dimenticare la differenza".

Questo è il significato della citazione che hai dato. Un processo deterministico non può dare numeri casuali. Può solo dare numeri che sembrano essere e si comportano come numeri casuali.

Ora possiamo riformulare la tua domanda in questo modo: "L'output del mio computer (o di qualsiasi altro moderno) può apparire e comportarsi in modo totalmente casuale, significa che la citazione di von Neumann è ormai superata e errata?"

Il problema è ancora questo: anche se l'output del tuo computer potrebbe apparire e comportarsi in modo casuale, potrebbe non essere realmente casuale . Se viene calcolato solo in modo deterministico, ciò significa che non c'è nulla che non sia stato causa-effetto prevedibile per ottenere il numero successivo (questo è ciò che significa "deterministico" in questo senso). Iniziamo con alcuni dati esistenti (noti), applichiamo un processo noto (complesso o disordinato o altro) e otteniamo quello che sembra un nuovo "numero casuale". Ma non è casuale, perché il processo è stato deterministico.

Se dici che il tuo metodo includerà un vero generatore casuale hardware, per risolverlo (come un numero casuale generato dal decadimento radioattivo o dal rumore in un semiconduttore), la tua risposta potrebbe ora essere casuale - ma il tuo metodo per definizione non è più deterministico , proprio perché non è più possibile prevedere gli output (o gli effetti) dati gli input / i dati iniziali (cause) .

Von Neumann vince in entrambi i modi, quasi per definizione!