Non riesco a capirlo, che è più casuale?

rand()

OPPURE :

rand() * rand()

Lo trovo un vero rompicapo, potresti aiutarmi?

MODIFICARE:

Intuitivamente so che la risposta matematica sarà che sono ugualmente casuali, ma non posso fare a meno di pensare che se "esegui l'algoritmo numerico casuale" due volte quando moltiplichi i due insieme creerai qualcosa di più casuale che semplicemente una volta.

Solo un chiarimento

Sebbene le risposte precedenti siano giuste ogni volta che provi a individuare la casualità di una variabile pseudo-casuale o la sua moltiplicazione, dovresti essere consapevole che mentre Random () è generalmente distribuito uniformemente, Random () * Random () non lo è.

Esempio

Questo è un campione uniforme di distribuzione casuale simulato attraverso una variabile pseudo-casuale:

        BarChart[BinCounts[RandomReal[{0, 1}, 50000], 0.01]]

Mentre questa è la distribuzione che ottieni dopo aver moltiplicato due variabili casuali:

        BarChart[BinCounts[Table[RandomReal[{0, 1}, 50000] * 
                                 RandomReal[{0, 1}, 50000], {50000}], 0.01]]

Quindi, entrambi sono "casuali", ma la loro distribuzione è molto diversa.

Un altro esempio

Mentre 2 * Random () è distribuito uniformemente:

        BarChart[BinCounts[2 * RandomReal[{0, 1}, 50000], 0.01]]

Casuale () + Casuale () no!

        BarChart[BinCounts[Table[RandomReal[{0, 1}, 50000] + 
                                 RandomReal[{0, 1}, 50000], {50000}], 0.01]]

Il teorema del limite centrale

Il Teorema del limite centrale afferma che la somma di Casuale () tende a una distribuzione normale con l'aumentare dei termini.

Con solo quattro termini ottieni:

BarChart[BinCounts[Table[RandomReal[{0, 1}, 50000] + RandomReal[{0, 1}, 50000] +
                   Table[RandomReal[{0, 1}, 50000] + RandomReal[{0, 1}, 50000],
                   {50000}],
         0.01]]  

E qui puoi vedere la strada da un'uniforme a una distribuzione normale sommando 1, 2, 4, 6, 10 e 20 variabili casuali distribuite uniformemente:

modificare

Alcuni crediti

Grazie a Thomas Ahle per aver sottolineato nei commenti che le distribuzioni di probabilità mostrate nelle ultime due immagini sono note come distribuzione Irwin-Hall

Grazie a Heike per la sua meravigliosa funzione strappata []

Immagino che entrambi i metodi siano casuali anche se il mio gutfeel direbbe che rand() * rand()è meno casuale perché seminerebbe più zero. Non appena uno rand()è 0, il totale diventa0

Né è "più casuale".

rand()genera un insieme prevedibile di numeri basato su un seme psuedo-casuale (di solito basato sull'ora corrente, che cambia sempre). Moltiplicare due numeri consecutivi nella sequenza genera una sequenza di numeri diversa, ma ugualmente prevedibile.

Affrontando se ciò ridurrà le collisioni, la risposta è no. In realtà aumenterà le collisioni a causa dell'effetto della moltiplicazione di due numeri dove 0 < n < 1. Il risultato sarà una frazione più piccola, causando una distorsione nel risultato verso l'estremità inferiore dello spettro.

Alcune ulteriori spiegazioni. Di seguito, "imprevedibile" e "casuale" si riferiscono alla capacità di qualcuno di indovinare quale sarà il prossimo numero in base ai numeri precedenti, ad es. un oracolo.

Dato seed xche genera il seguente elenco di valori:

0.3, 0.6, 0.2, 0.4, 0.8, 0.1, 0.7, 0.3, ...

rand()genererà l'elenco sopra e rand() * rand()genererà:

0.18, 0.08, 0.08, 0.21, ...

Entrambi i metodi produrranno sempre lo stesso elenco di numeri per lo stesso seme, e quindi sono ugualmente prevedibili da un oracolo. Ma se guardi i risultati per moltiplicare le due chiamate, vedrai che sono tutti sotto 0.3nonostante una discreta distribuzione nella sequenza originale. I numeri sono distorti a causa dell'effetto della moltiplicazione di due frazioni. Il numero risultante è sempre più piccolo, quindi è molto più probabile che sia una collisione nonostante sia ancora imprevedibile.

Semplificazione eccessiva per illustrare un punto.

Supponiamo che la tua funzione casuale produca solo output 0o 1.

random()è uno dei (0,1), ma random()*random()è uno dei(0,0,0,1)

Puoi vedere chiaramente che le possibilità di ottenere un 0nel secondo caso non sono in alcun modo uguali a quelle di ottenere un 1.

Quando ho pubblicato per la prima volta questa risposta, volevo renderla il più breve possibile in modo che una persona che la leggesse capisse a prima vista la differenza tra random()e random()*random(), ma non riesco a trattenermi dal rispondere alla domanda originale su litteram:

Qual è più casuale?

Essendo che random(), random()*random(), random()+random(), (random()+1)/2o qualsiasi altra combinazione che non porta ad un risultato fisso hanno la stessa fonte di entropia (o lo stesso stato iniziale in caso di generatori pseudocasuali), la risposta sarebbe che essi sono ugualmente casuale (La differenza è nella loro distribuzione). Un esempio perfetto che possiamo vedere è il gioco di Craps. Il numero che otterresti sarebbe random(1,6)+random(1,6)e sappiamo tutti che ottenere 7 ha le maggiori possibilità, ma ciò non significa che il risultato del lancio di due dadi sia più o meno casuale del risultato del lancio di uno.

Ecco una risposta semplice. Prendi in considerazione il monopolio. Lanciate due dadi a sei facce (o 2d6 per quelli di voi che preferiscono la notazione di gioco) e prendete la loro somma. Il risultato più comune è 7 perché ci sono 6 modi possibili per ottenere un 7 (1,6 2,5 3,4 4,3 5,2 e 6,1). Considerando che un 2 può essere lanciato solo su 1,1. È facile vedere che rotolare 2d6 è diverso dal rotolare 1d12, anche se l'intervallo è lo stesso (ignorando che è possibile ottenere un 1 su 1d12, il punto rimane lo stesso). Moltiplicare i risultati invece di aggiungerli li inclinerà in modo simile, con la maggior parte dei risultati che arrivano al centro dell'intervallo. Se stai cercando di ridurre gli outlier, questo è un buon metodo, ma non aiuterà a fare una distribuzione uniforme.

(E stranamente aumenterà anche i tiri bassi. Supponendo che la casualità inizi da 0, vedrai un picco a 0 perché trasformerà qualsiasi altro tiro in uno 0. Considera due numeri casuali tra 0 e 1 (incluso ) e moltiplicando. Se uno dei due risultati è uno 0, l'intera cosa diventa uno 0 indipendentemente dall'altro risultato. L'unico modo per ottenere un 1 da esso è che entrambi i lanci siano uno 1. In pratica, probabilmente questo non importerebbe ma crea un grafico strano.)

Il xkcd obbligatorio ...

Potrebbe aiutare a pensarci in numeri più discreti. Considera di voler generare numeri casuali tra 1 e 36, quindi decidi che il modo più semplice è lanciare due dadi giusti a 6 facce. Ottieni questo:

     1    2    3    4    5    6
  -----------------------------
1|   1    2    3    4    5    6
2|   2    4    6    8   10   12
3|   3    6    9   12   15   18
4|   4    8   12   16   20   24   
5|   5   10   15   20   25   30
6|   6   12   18   24   30   36

Quindi abbiamo 36 numeri, ma non tutti sono abbastanza rappresentati e alcuni non si verificano affatto. I numeri vicino alla diagonale centrale (dall'angolo in basso a sinistra all'angolo in alto a destra) verranno visualizzati con la frequenza più alta.

Gli stessi principi che descrivono la distribuzione ingiusta tra i dadi si applicano ugualmente ai numeri in virgola mobile compresi tra 0,0 e 1,0.

Alcune cose sulla "casualità" sono controintuitive.

Supponendo che la distribuzione sia piatta rand(), le seguenti otterranno distribuzioni non piatte:

• parzialità elevata: sqrt(rand(range^2))
• bias al picco nel mezzo: (rand(range) + rand(range))/2
• basso: polarizzazione: range - sqrt(rand(range^2))

Esistono molti altri modi per creare curve di polarizzazione specifiche. Ho fatto un rapido test rand() * rand()e ti procura una distribuzione molto non lineare.

La maggior parte delle implementazioni di rand () ha un certo periodo. Cioè dopo un numero enorme di chiamate la sequenza si ripete. La sequenza di output di rand() * rand()ripetizioni in metà tempo, quindi è "meno casuale" in questo senso.

Inoltre, senza un'attenta costruzione, l'esecuzione dell'aritmetica su valori casuali tende a causare meno casualità. Un poster sopra citato " rand()+ rand()+ rand()..." (k volte, diciamo) che in effetti tenderà a k volte il valore medio dell'intervallo di valori rand()ritorna. (È una camminata casuale con passaggi simmetrici su quella media.)

Supponiamo per concretezza che la funzione rand () restituisca un numero reale casuale distribuito uniformemente nell'intervallo [0,1). (Sì, questo esempio consente una precisione infinita. Questo non cambierà il risultato.) Non hai scelto una lingua particolare e lingue diverse potrebbero fare cose diverse, ma la seguente analisi vale con modifiche per qualsiasi implementazione non perversa di rand ( ). Anche il prodotto rand() * rand()è compreso nell'intervallo [0,1) ma non è più uniformemente distribuito. In effetti, è probabile che il prodotto sia nell'intervallo [0,1 / 4) come nell'intervallo [1 / 4,1). Una maggiore moltiplicazione inclinerà ulteriormente il risultato verso lo zero. Questo rende il risultato più prevedibile. A grandi linee, più prevedibile == meno casuale.

Praticamente qualsiasi sequenza di operazioni su input uniformemente casuali sarà non uniformemente casuale, portando ad una maggiore prevedibilità. Con cura, si può superare questa proprietà, ma sarebbe stato più semplice generare un numero casuale uniformemente distribuito nell'intervallo desiderato, piuttosto che perdere tempo con l'aritmetica.

"random" vs. "more random" è un po 'come chiedere quale Zero è più zero.

In questo caso, randè un PRNG, quindi non del tutto casuale. (in effetti, abbastanza prevedibile se il seme è noto). Moltiplicarlo per un altro valore non lo rende più o meno casuale.

Un vero RNG di tipo crittografico sarà effettivamente casuale. E l'esecuzione di valori attraverso qualsiasi tipo di funzione non può aggiungere più entropia ad esso, e molto probabilmente può rimuovere l'entropia, rendendola non più casuale.

Il concetto che stai cercando è "entropia", il "grado" di disordine di una serie di bit. L'idea è più facile da comprendere in termini di "massima entropia".

Una definizione approssimativa di una stringa di bit con la massima entropia è che non può essere espressa esattamente in termini di una stringa di bit più corta (ovvero utilizzando un algoritmo per espandere la stringa più piccola alla stringa originale).

La rilevanza della massima entropia per la casualità deriva dal fatto che se scegli un numero "a caso", quasi sicuramente sceglierai un numero la cui stringa di bit è vicina ad avere la massima entropia, cioè non può essere compressa. Questa è la nostra migliore comprensione di ciò che caratterizza un numero "casuale".

Quindi, se si desidera creare un numero casuale da due campioni casuali che è "due volte" casuale, lo si farebbe concatenerebbero le due stringhe di bit insieme. In pratica, riempiresti semplicemente i campioni nelle metà alta e bassa di una parola di doppia lunghezza.

Su una nota più pratica, se ti trovi sellato con un rand schifoso (), a volte può aiutare a xor un paio di campioni insieme --- sebbene, se è veramente rotto anche quella procedura non aiuterà.

La risposta accettata è piuttosto bella, ma c'è un altro modo di rispondere alla tua domanda. La risposta di PachydermPuncher adotta già questo approccio alternativo e lo espanderò un po '.

Il modo più semplice di pensare alla teoria dell'informazione è in termini della più piccola unità di informazione, un singolo bit.

Nella libreria standard C, rand()restituisce un numero intero compreso tra 0 RAND_MAXe un limite che può essere definito in modo diverso a seconda della piattaforma. Supponiamo RAND_MAXche sia definito come 2^n - 1dov'è nun numero intero (questo accade nell'implementazione di Microsoft, dove nè 15). Quindi diremmo che una buona implementazione restituirebbe nframmenti di informazioni.

Immagina che rand()costruisca numeri casuali lanciando una moneta per trovare il valore di un bit e quindi ripetendo fino a quando non ha un batch di 15 bit. Quindi i bit sono indipendenti (il valore di uno qualsiasi dei bit non influenza la probabilità che altri bit nello stesso batch abbiano un certo valore). Quindi ogni bit considerato in modo indipendente è come un numero casuale compreso tra 0 e 1 compreso, ed è "uniformemente distribuito" su quell'intervallo (probabilmente come 0 come 1).

L'indipendenza dei bit garantisce che anche i numeri rappresentati da lotti di bit vengano distribuiti uniformemente nel loro intervallo. Ciò è intuitivamente ovvio: se ci sono 15 bit, l'intervallo consentito è da zero a 2^15 - 1= 32767. Ogni numero in quell'intervallo è un modello univoco di bit, come ad esempio:

010110101110010

e se i bit sono indipendenti, allora non è più probabile che si verifichi un pattern rispetto a qualsiasi altro pattern. Quindi tutti i possibili numeri nell'intervallo sono ugualmente probabili. E così è vero il contrario: se rand()produce numeri interi distribuiti uniformemente, quei numeri sono fatti di bit indipendenti.

Pensa quindi rand()a una linea di produzione per creare pezzi, che per caso li serve in lotti di dimensioni arbitrarie. Se non ti piacciono le dimensioni, suddividi i lotti in singoli bit e poi rimettili insieme in qualsiasi quantità desideri (anche se hai bisogno di un intervallo particolare che non sia una potenza di 2, devi ridurre i numeri e di gran lunga il modo più semplice per farlo è convertire in virgola mobile).

Tornando al tuo suggerimento originale, supponi di voler passare da lotti di 15 a lotti di 30, chiedi rand()il primo numero, spostalo in bit di 15 posti, quindi aggiungine un altro rand(). Questo è un modo per combinare due chiamate rand()senza disturbare una distribuzione uniforme. Funziona semplicemente perché non ci sono sovrapposizioni tra le posizioni in cui si posizionano le informazioni.

Questo è molto diverso da "allungare" l'intervallo rand()moltiplicando per una costante. Ad esempio, se volessi raddoppiare l'intervallo di rand()te, potresti moltiplicarlo per due, ma ora otterrai solo numeri pari e mai numeri dispari! Questa non è esattamente una distribuzione regolare e potrebbe essere un problema serio a seconda dell'applicazione, ad esempio un gioco simile alla roulette che presumibilmente consente scommesse dispari / pari. (Pensando in termini di bit, eviteresti quell'errore in modo intuitivo, perché ti renderesti conto che moltiplicare per due equivale a spostare i bit a sinistra (maggiore significato) di un posto e riempire lo spazio con zero. Quindi, ovviamente, la quantità di informazioni è la stessa: si è spostata leggermente.)

Tali lacune negli intervalli di numeri non possono essere colmate in applicazioni numeriche in virgola mobile, poiché gli intervalli di virgola mobile hanno intrinsecamente lacune in esse che semplicemente non possono essere rappresentate affatto: un numero infinito di numeri reali mancanti esiste nello spazio tra ogni due variabili mobili rappresentabili numeri di punti! Quindi non ci resta che imparare a convivere con i vuoti.

Come altri hanno avvertito, l'intuizione è rischiosa in quest'area, soprattutto perché i matematici non possono resistere al fascino dei numeri reali, che stanno orribilmente confondendo cose piene di infiniti nodosi e apparenti paradossi.

Ma almeno se la pensi in termini di bit, la tua intuizione potrebbe portarti un po 'oltre. I bit sono davvero facili: anche i computer possono capirli.

Come altri hanno già detto, la risposta semplice è: No, non è più casuale, ma cambia la distribuzione.

Supponiamo che stavi giocando a dadi. Hai dei dadi completamente equi e casuali. I tiri di dado sarebbero "più casuali" se prima di ogni tiro di dado mettessi prima due dadi in una ciotola, lo scuotessi, prendessi uno dei dadi a caso e poi tirassi quello? Chiaramente non farebbe differenza. Se entrambi i dadi danno numeri casuali, la scelta casuale di uno dei due dadi non farà alcuna differenza. Ad ogni modo otterrai un numero casuale compreso tra 1 e 6 con distribuzione uniforme su un numero sufficiente di tiri.

Suppongo che nella vita reale tale procedura potrebbe essere utile se sospettavi che i dadi NON potessero essere equi. Se, diciamo, i dadi sono leggermente sbilanciati, quindi uno tende a dare 1 più spesso di 1/6 del tempo, e un altro tende a dare 6 insolitamente spesso, quindi scegliere casualmente tra i due tenderebbe a oscurare il pregiudizio. (Anche se in questo caso, 1 e 6 emergerebbero comunque più di 2, 3, 4 e 5. Beh, immagino che dipenda dalla natura dello squilibrio.)

Esistono molte definizioni di casualità. Una definizione di una serie casuale è che si tratta di una serie di numeri prodotti da un processo casuale. Con questa definizione, se lancio un dado giusto 5 volte e ottengo i numeri 2, 4, 3, 2, 5, questa è una serie casuale. Se poi lancio lo stesso dado giusto altre 5 volte e ottengo 1, 1, 1, 1, 1, allora anche questa è una serie casuale.

Diversi poster hanno sottolineato che le funzioni casuali su un computer non sono realmente casuali ma piuttosto pseudo-casuali e che se si conosce l'algoritmo e il seme sono completamente prevedibili. Questo è vero, ma il più delle volte completamente irrilevante. Se mescolo un mazzo di carte e poi le rigiro una alla volta, questa dovrebbe essere una serie casuale. Se qualcuno sbircia le carte, il risultato sarà completamente prevedibile, ma per la maggior parte delle definizioni di casualità questo non lo renderà meno casuale. Se la serie supera i test statistici di casualità, il fatto che ho dato una sbirciatina alle carte non cambierà questo fatto. In pratica, se stiamo scommettendo ingenti somme di denaro sulla tua capacità di indovinare la carta successiva, allora il fatto che hai dato una sbirciatina alle carte è molto rilevante. Se stiamo utilizzando la serie per simulare le scelte di menu dei visitatori del nostro sito Web al fine di testare le prestazioni del sistema, il fatto che tu abbia dato una sbirciatina non farà alcuna differenza. (Fintanto che non si modifica il programma per sfruttare questa conoscenza.)

MODIFICARE

Non credo di poter inserire la mia risposta al problema di Monty Hall in un commento, quindi aggiornerò la mia risposta.

Per coloro che non hanno letto il link di Belisarius, l'essenza di questo è: un concorrente di un game show può scegliere tra 3 porte. Dietro uno c'è un premio prezioso, dietro agli altri qualcosa di inutile. Prende la porta n. 1. Prima di rivelare se è un vincitore o un perdente, l'host apre la porta n. 3 per rivelare che è un perdente. Dà quindi al concorrente l'opportunità di passare alla porta # 2. Il concorrente dovrebbe farlo o no?

La risposta, che offende l'intuizione di molte persone, è che dovrebbe cambiare. La probabilità che la sua scelta originale fosse il vincitore è 1/3, che l'altra porta è il vincitore è 2/3. La mia intuizione iniziale, insieme a quella di molte altre persone, è che non ci sarebbe alcun guadagno nel cambiare, che le probabilità sono state appena cambiate in 50:50.

Dopotutto, supponiamo che qualcuno abbia acceso la TV subito dopo che l'ospite ha aperto la porta perdente. Quella persona vedrebbe due porte chiuse rimanenti. Supponendo che conosca la natura del gioco, direbbe che ci sono 1/2 possibilità che ogni porta nasconda il premio. Come possono le probabilità per lo spettatore essere 1/2: 1/2 mentre le probabilità per il concorrente sono 1/3: 2/3?

Ho dovuto davvero pensarci per rimettere in forma il mio intuito. Per farcela, capisci che quando parliamo di probabilità in un problema come questo, intendiamo la probabilità che assegni date le informazioni disponibili. Per un membro dell'equipaggio che ha messo il premio dietro, diciamo, porta n. 1, la probabilità che il premio sia dietro la porta n. 1 è del 100% e la probabilità che sia dietro una delle altre due porte è zero.

Le probabilità del membro dell'equipaggio sono diverse da quelle del concorrente perché sa qualcosa che il concorrente non sa, vale a dire, quale porta ha lasciato il premio. Allo stesso modo, le probabilità del concorrente sono diverse da quelle dello spettatore perché sa qualcosa che lo spettatore non conosce, vale a dire, quale porta ha inizialmente scelto. Questo non è irrilevante, perché la scelta dell'host di quale porta aprire non è casuale. Non aprirà la porta scelta dal concorrente e non aprirà la porta che nasconde il premio. Se queste sono la stessa porta, questo gli lascia due scelte. Se sono porte diverse, ne rimane solo una.

Quindi, come possiamo trovare 1/3 e 2/3? Quando il concorrente aveva originariamente scelto una porta, aveva 1/3 di possibilità di scegliere il vincitore. Penso che molto sia ovvio. Ciò significa che c'era una probabilità 2/3 che una delle altre porte fosse il vincitore. Se il giocatore ospite gli offre l'opportunità di passare senza fornire ulteriori informazioni, non ci sarebbe alcun guadagno. Ancora una volta, questo dovrebbe essere ovvio. Ma un modo per vederlo è quello di dire che c'è una probabilità di 2/3 di vincere vincendo. Ma ha 2 alternative. Quindi ognuno ha solo 2/3 diviso per 2 = 1/3 possibilità di essere il vincitore, il che non è migliore della sua scelta originale. Ovviamente conoscevamo già il risultato finale, questo lo calcola in modo diverso.

Ma ora l'host rivela che una di queste due scelte non è il vincitore. Quindi, per la 2/3 possibilità che una porta che non ha scelto sia il vincitore, ora sa che 1 delle 2 alternative non è vero. L'altro potrebbe o non potrebbe essere. Quindi non ha più i 2/3 divisi per 2. Ha zero per la porta aperta e 2/3 per la porta chiusa.

Considera di avere un semplice problema di lancio delle monete in cui anche è considerata testa e dispari è considerata croce. L'implementazione logica è:

rand() mod 2

Su una distribuzione abbastanza grande, il numero di numeri pari dovrebbe essere uguale al numero di numeri dispari.

Ora considera un leggero ritocco:

rand() * rand() mod 2

Se uno dei risultati è pari, l'intero risultato dovrebbe essere pari. Considera i 4 possibili risultati (pari * pari = pari, pari * dispari = pari, dispari * pari = pari, dispari * dispari = dispari). Ora, su una distribuzione abbastanza ampia, la risposta dovrebbe essere anche il 75% delle volte.

Scommetterei teste se fossi in te.

Questo commento è più una spiegazione del perché non dovresti implementare una funzione casuale personalizzata basata sul tuo metodo che una discussione sulle proprietà matematiche della casualità.

In caso di dubbi su cosa accadrà alle combinazioni dei tuoi numeri casuali, puoi utilizzare le lezioni apprese nella teoria statistica.

Nella situazione di OP vuole sapere qual è il risultato di X * X = X ^ 2 dove X è una variabile casuale distribuita lungo Uniform [0,1]. Useremo la tecnica CDF poiché è solo una mappatura uno a uno.

Poiché X ~ Uniforme [0,1] è cdf è: f _X (x) = 1 Vogliamo la trasformazione Y <- X ^ 2 quindi y = x ^ 2 Trova l'inverso x (y): sqrt (y) = x questo ci dà x in funzione di y. Quindi, trova la derivata dx / dy: d / dy (sqrt (y)) = 1 / (2 sqrt (y))

La distribuzione di Y è data come: f _Y (y) = f _X (x (y)) | dx / dy | = 1 / (2 sqrt (y))

Non abbiamo ancora finito, dobbiamo ottenere il dominio di Y. poiché 0 <= x <1, 0 <= x ^ 2 <1, quindi Y è compreso nell'intervallo [0, 1). Se vuoi verificare se il pdf di Y è davvero un pdf, integralo nel dominio: integra 1 / (2 sqrt (y)) da 0 a 1 e, in effetti, appare come 1. Inoltre, nota la forma del detta funzione assomiglia a ciò che è stato postato in modo stupendo.

Per quanto riguarda cose come X ₁ + X ₂ + ... + X _n , (dove X _i ~ Uniform [0,1]) possiamo semplicemente appellarci al Teorema del limite centrale che funziona per qualsiasi distribuzione i cui momenti esistono. Questo è il motivo per cui il test Z esiste effettivamente.

Altre tecniche per determinare il pdf risultante includono la trasformazione giacobina (che è la versione generalizzata della tecnica cdf) e la tecnica MGF.

EDIT: come chiarimento, nota che sto parlando della distribuzione della trasformazione risultante e non della sua casualità . Questo è in realtà per una discussione separata. Anche quello che ho effettivamente derivato era per (rand ()) ^ 2. Per rand () * rand () è molto più complicato, il che, in ogni caso, non si tradurrà in una distribuzione uniforme di alcun tipo.

Non è esattamente ovvio, ma in rand()genere è più casuale di rand()*rand(). La cosa importante è che questo non è in realtà molto importante per la maggior parte degli usi.

Ma in primo luogo, producono distribuzioni diverse. Questo non è un problema se è quello che vuoi, ma è importante. Se hai bisogno di una particolare distribuzione, ignora l'intera domanda "che è più casuale". Quindi perché è rand()più casuale?

Il nocciolo del perché rand()è più casuale (supponendo che stia producendo numeri casuali in virgola mobile con l'intervallo [0..1], che è molto comune) è che quando moltiplichi due numeri FP insieme a molte informazioni nella mantissa, ottieni una certa perdita di informazioni alla fine; non c'è abbastanza bit in un float a doppia precisione IEEE per contenere tutte le informazioni che erano in due float a doppia precisione IEEE uniformemente selezionati casualmente da [0..1], e quei bit extra di informazioni vengono persi. Naturalmente, non importa molto dal momento che (probabilmente) non avresti usato quelle informazioni, ma la perdita è reale. Inoltre, non importa quale distribuzione produciate (ovvero, quale operazione usate per fare la combinazione). Ognuno di quei numeri casuali ha (nella migliore delle ipotesi) 52 bit di informazioni casuali - che "

La maggior parte degli usi di numeri casuali non è nemmeno vicina a quanta casualità sia effettivamente disponibile nella fonte casuale. Ottieni un buon PRNG e non preoccuparti troppo. (Il livello di "bontà" dipende da cosa ci stai facendo; devi fare attenzione quando esegui la simulazione o la crittografia Monte Carlo, ma altrimenti puoi probabilmente usare il PRNG standard poiché di solito è molto più veloce.)

I random fluttuanti si basano, in generale, su un algoritmo che produce un numero intero compreso tra zero e un certo intervallo. Come tale, usando rand () * rand (), stai essenzialmente dicendo int_rand () * int_rand () / rand_max ^ 2 - nel senso che stai escludendo qualsiasi numero primo / rand_max ^ 2.

Ciò modifica in modo significativo la distribuzione randomizzata.

rand () è distribuito uniformemente sulla maggior parte dei sistemi e difficile da prevedere se correttamente seminato. Usalo a meno che tu non abbia un motivo particolare per fare matematica su di esso (ad esempio, modellare la distribuzione su una curva necessaria).

Moltiplicare i numeri finirebbe in una gamma di soluzioni più piccola a seconda dell'architettura del computer.

Se il display del tuo computer mostra 16 cifre rand()dire 0,1234567890123 moltiplicato per un secondo rand(), 0,1234567890123, darebbe 0,0152415 qualcosa che troverai sicuramente meno soluzioni se ripetessi l'esperimento 10 ^ 14 volte.

La maggior parte di queste distribuzioni avviene perché devi limitare o normalizzare il numero casuale.

Lo normalizziamo per essere tutto positivo, rientrare in un intervallo e persino per rientrare nei vincoli della dimensione della memoria per il tipo di variabile assegnato.

In altre parole, poiché dobbiamo limitare la chiamata casuale tra 0 e X (X è il limite di dimensione della nostra variabile) avremo un gruppo di numeri "casuali" tra 0 e X.

Ora quando aggiungi il numero casuale a un altro numero casuale la somma sarà compresa tra 0 e 2X ... questo distorce i valori dai punti del bordo (la probabilità di aggiungere due piccoli numeri insieme e due grandi numeri insieme è molto piccola quando hai due numeri casuali su un ampio intervallo).

Pensa al caso in cui avevi un numero vicino allo zero e lo aggiungi con un altro numero casuale che diventerà sicuramente più grande e lontano da 0 (questo sarà vero per i numeri grandi così come è improbabile che abbia due numeri grandi (numeri vicini a X) restituiti due volte dalla funzione Casuale.

Ora, se dovessi impostare il metodo casuale con numeri negativi e numeri positivi (che si estendono equamente sull'asse zero), questo non sarebbe più il caso.

Diciamo ad esempio RandomReal({-x, x}, 50000, .01)che otterresti una distribuzione uniforme dei numeri sul lato negativo un lato positivo e se dovessi sommare i numeri casuali manterrebbero la loro "casualità".

Ora non sono sicuro di cosa succederebbe con Random() * Random()un intervallo da negativo a positivo ... sarebbe un grafico interessante da vedere ... ma ora devo tornare a scrivere il codice. :-P

1. Non esiste qualcosa di più casuale. È casuale o no. Casuale significa "difficile da prevedere". Non significa non deterministico. Sia random () che random () * random () sono ugualmente casuali se random () è casuale. La distribuzione è irrilevante per quanto riguarda la casualità. Se si verifica una distribuzione non uniforme, significa solo che alcuni valori sono più probabili di altri; sono ancora imprevedibili.

2. Poiché è coinvolta la pseudo-casualità, i numeri sono molto deterministici. Tuttavia, la pseudo-casualità è spesso sufficiente nei modelli di probabilità e nelle simulazioni. È abbastanza noto che rendere complicato un generatore di numeri pseudo-casuale rende difficile l'analisi. È improbabile migliorare la casualità; spesso fa fallire i test statistici.

3. Le proprietà desiderate dei numeri casuali sono importanti: ripetibilità e riproducibilità, casualità statistica, (di solito) uniformemente distribuita e un ampio periodo sono pochi.

4. Per quanto riguarda le trasformazioni su numeri casuali: come qualcuno ha detto, la somma di due o più distribuzioni uniformemente si traduce in una distribuzione normale. Questo è il teorema del limite centrale additivo . Si applica indipendentemente dalla distribuzione di origine purché tutte le distribuzioni siano indipendenti e identiche. Il moltiplicativoil teorema del limite centrale afferma che il prodotto di due o più variabili casuali indipendenti e distribuite indenticamente è lognormale. Il grafico creato da qualcun altro sembra esponenziale, ma è davvero lognormale. Quindi random () * random () è distribuito in modo lognormale (anche se potrebbe non essere indipendente poiché i numeri sono estratti dallo stesso flusso). Questo può essere desiderabile in alcune applicazioni. Tuttavia, di solito è meglio generare un numero casuale e trasformarlo in un numero distribuito in modo lognormale. Casuale () * casuale () può essere difficile da analizzare.

Per ulteriori informazioni, consultare il mio libro su www.performorama.org. Il libro è in costruzione, ma il materiale pertinente è lì. Notare che i numeri di capitolo e sezione possono cambiare nel tempo. Capitolo 8 (teoria della probabilità) - sezioni 8.3.1 e 8.3.3, capitolo 10 (numeri casuali).

Possiamo confrontare due matrici di numeri riguardanti la casualità usando la complessità di Kolmogorov Se la sequenza di numeri non può essere compressa, allora è la più casuale che possiamo raggiungere a questa lunghezza ... So che questo tipo di misurazione è più teorico opzione...

In realtà, quando ci pensi rand() * rand()è meno casuale di rand(). Ecco perché.

In sostanza, esiste lo stesso numero di numeri dispari dei numeri pari. E dicendo che 0.04325 è dispari e come 0.388 è pari e 0.4 è pari e 0.15 è dispari,

Ciò significa che rand()ha le stesse possibilità di essere un decimale pari o dispari .

D'altra parte, rand() * rand()ha le sue probabilità accatastate in modo leggermente diverso. Diciamo:

double a = rand();
double b = rand();
double c = a * b;

aed bentrambi hanno una probabilità del 50% di essere pari o dispari. Sapendo ciò

• pari * pari = pari
• pari * dispari = pari
• dispari * dispari = dispari
• dispari * pari = pari

significa che c'è una probabilità del 75% che cè pari, mentre solo una probabilità del 25% è dispari, rendendo il valore di rand() * rand()più prevedibile di rand(), quindi meno casuale.

Utilizzare un registro a spostamento lineare di feedback (LFSR) che implementa un polinomio primitivo.

Il risultato sarà una sequenza di 2 ^ n numeri pseudo-casuali, cioè nessuno che si ripete nella sequenza in cui n è il numero di bit nell'LFSR .... risultante in una distribuzione uniforme.

http://en.wikipedia.org/wiki/Linear_feedback_shift_register http://www.xilinx.com/support/documentation/application_notes/xapp052.pdf

Usa un seme "casuale" basato su microsecs dell'orologio del tuo computer o forse un sottoinsieme del risultato md5 su alcuni dati che cambiano continuamente nel tuo file system.

Ad esempio, un LFSR a 32 bit genererà 2 ^ 32 numeri univoci in sequenza (non 2 uguali) a partire da un determinato seme. La sequenza sarà sempre nello stesso ordine, ma il punto di partenza sarà diverso (ovviamente) per un seme diverso. Quindi, se una sequenza che si ripete tra semenze non è un problema, questa potrebbe essere una buona scelta.

Ho usato LFSR a 128 bit per generare test casuali nei simulatori hardware utilizzando un seed che è i risultati md5 su dati di sistema in continua evoluzione.

Supponendo che rand()restituisca un numero tra di [0, 1)esso è ovvio che rand() * rand()sarà distorto verso 0. Ciò è dovuto al fatto che la moltiplicazione xper un numero tra [0, 1)comporterà un numero minore di x. Ecco la distribuzione di altri 10000 numeri casuali:

google.charts.load("current", { packages: ["corechart"] });
google.charts.setOnLoadCallback(drawChart);

function drawChart() {
  var i;
  var randomNumbers = [];
  for (i = 0; i < 10000; i++) {
    randomNumbers.push(Math.random() * Math.random());
  }
  var chart = new google.visualization.Histogram(document.getElementById("chart-1"));
  var data = new google.visualization.DataTable();
  data.addColumn("number", "Value");
  randomNumbers.forEach(function(randomNumber) {
    data.addRow([randomNumber]);
  });
  chart.draw(data, {
    title: randomNumbers.length + " rand() * rand() values between [0, 1)",
    legend: { position: "none" }
  });
}

<script src="https://www.gstatic.com/charts/loader.js"></script>

<div id="chart-1" style="height: 500px">Generating chart...</div>

Se rand()restituisce un numero intero compreso, [x, y]allora hai la seguente distribuzione. Si noti il ​​numero di valori dispari vs pari:

google.charts.load("current", { packages: ["corechart"] });
google.charts.setOnLoadCallback(drawChart);
document.querySelector("#draw-chart").addEventListener("click", drawChart);

function randomInt(min, max) {
  return Math.floor(Math.random() * (max - min + 1)) + min;
}

function drawChart() {
  var min = Number(document.querySelector("#rand-min").value);
  var max = Number(document.querySelector("#rand-max").value);
  if (min >= max) {
    return;
  }
  var i;
  var randomNumbers = [];
  for (i = 0; i < 10000; i++) {
    randomNumbers.push(randomInt(min, max) * randomInt(min, max));
  }
  var chart = new google.visualization.Histogram(document.getElementById("chart-1"));
  var data = new google.visualization.DataTable();
  data.addColumn("number", "Value");
  randomNumbers.forEach(function(randomNumber) {
    data.addRow([randomNumber]);
  });
  chart.draw(data, {
    title: randomNumbers.length + " rand() * rand() values between [" + min + ", " + max + "]",
    legend: { position: "none" },
    histogram: { bucketSize: 1 }
  });
}

<script src="https://www.gstatic.com/charts/loader.js"></script>

<input type="number" id="rand-min" value="0" min="0" max="10">
<input type="number" id="rand-max" value="9" min="0" max="10">
<input type="button" id="draw-chart" value="Apply">

<div id="chart-1" style="height: 500px">Generating chart...</div>

OK, quindi proverò ad aggiungere un valore per integrare le altre risposte dicendo che stai creando e usando un generatore di numeri casuali.

I generatori di numeri casuali sono dispositivi (in senso molto generale) che hanno molteplici caratteristiche che possono essere modificate per adattarsi a uno scopo. Alcuni di loro (da me) sono:

• Entropia: come in Shannon Entropy
• Distribuzione: distribuzione statistica (poisson, normale, ecc.)
• Tipo: qual è la fonte dei numeri (algoritmo, evento naturale, combinazione di, ecc.) E algoritmo applicato.
• Efficienza: rapidità o complessità di esecuzione.
• Pattern: periodicità, sequenze, run, ecc.
• e probabilmente di più ...

Nella maggior parte delle risposte qui, la distribuzione è il principale punto di interesse, ma mescolando e abbinando funzioni e parametri, si creano nuovi modi di generare numeri casuali che avranno caratteristiche diverse per alcuni dei quali la valutazione potrebbe non essere ovvia a prima vista.

È facile dimostrare che la somma dei due numeri casuali non è necessariamente casuale. Immagina di avere un dado e un tiro a 6 facce. Ogni numero ha una probabilità 1/6 di apparire. Ora supponi di avere 2 dadi e di aver sommato il risultato. La distribuzione di tali somme non è 1/12. Perché? Perché alcuni numeri appaiono più di altri. Esistono più partizioni . Ad esempio il numero 2 è solo la somma di 1 + 1 ma 7 può essere formato da 3 + 4 o 4 + 3 o 5 + 2 ecc ... quindi ha una maggiore possibilità di risalire.

Pertanto, l'applicazione di una trasformazione, in questo caso l'aggiunta di una funzione casuale non la rende più casuale o necessariamente preserva la casualità. Nel caso dei dadi sopra, la distribuzione è inclinata a 7 e quindi meno casuale.

Come altri hanno già sottolineato, è difficile rispondere a questa domanda poiché ognuno di noi ha la propria immagine di casualità nella sua testa.

Ecco perché, ti consiglio vivamente di prenderti un po 'di tempo e leggere questo sito per avere un'idea migliore della casualità:

• http://www.random.org/

Per tornare alla vera domanda. Non c'è più o meno casuale in questo termine:

entrambi sembrano casuali !

In entrambi i casi - solo rand () o rand () * rand () - la situazione è la stessa: dopo alcuni miliardi di numeri la sequenza si ripeterà (!) . Essa appare casuale per l'osservatore, perché non conosce l'intera sequenza, ma il computer non ha alcuna vera fonte casuale - in modo che non può produrre casualità sia.

es: il tempo è casuale? Non abbiamo abbastanza sensori o conoscenze per determinare se il tempo è casuale o no.

La risposta sarebbe che dipende, si spera che rand () * rand () sia più casuale di rand (), ma come:

• entrambe le risposte dipendono dalla dimensione in bit del tuo valore
• che nella maggior parte dei casi si genera a seconda di un algoritmo pseudo-casuale (che è principalmente un generatore di numeri che dipende dall'orologio del computer e non molto casuale).
• rendere il tuo codice più leggibile (e non invocare qualche dio voodoo casuale di casuale con questo tipo di mantra).

Bene, se controlli uno di questi sopra ti suggerisco di scegliere il semplice "rand ()". Perché il tuo codice sarebbe più leggibile (non ti chiederesti perché l'hai scritto, per ... beh ... più di 2 secondi), facile da mantenere (se vuoi sostituire la tua funzione rand con un super_rand).

Se vuoi un casuale migliore, ti consiglio di trasmetterlo in streaming da qualsiasi fonte che fornisca abbastanza rumore ( radio statico ), e quindi un semplice rand()dovrebbe essere sufficiente.