Newsgroup: it.comp.lang.c++
Titolo: Genatore di numeri casuali

Salve,
sapreste dirmi dove trovo o come posso creare una routine per generare 
numeri veramente (o magari "decentemente") casuali?
Grazie
-- 
Luigi
bug windows [5] = {"95", "98", "NT", "Me", "2000"};

 numeri veramente (o magari "decentemente") casuali?
"Inseminando" il generatore di numeri casuali
-che a parita' di seme ha il vizio di generare spesso la stessa sequenza-
con un numero... casuale.
Un numero abbastanza casuale che puoi trovare su un computer
è il numero di millisecondi trascorsi nel secondo corrente,
o il numero di tick del processore dal momento dell'accensione.
Non so pero' se questo è abbastanza per soddisfare il tuo bisogno di
casualita'.

 wrote in message
news:9c8d8j$p2u$1...@serverlinux.frigoveneta.interno...

Ne dubito! Quei valori sono validi numeri casuali se ti serve un unico numero
casuale. Per generatore di numeri casuali si intende un generatore di una
sequenza di numeri (pseudo)casuali.
Per esempio:
int numbers[10000];
for ( int i=0; i<10000; i++ )
    numbers[i]=getRandom();
Immagina che razza di statistiche su numbers ti saltano fuori se getRandom() e'
implementato in uno dei modi che dici tu!
--
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556

 casuale.
Uhm... forse non ci si capisce.
Mi rispiego: ottengo un solo numero
che ritengo sufficientemente casuale,
basandomi su uno dei metodi suesposti.
Con esso _inizializzo_ il motore del generatore di numeri
casuali (la famosa srand di un thread di qualche tempo fa).
Successivamente ottengo la sequenza di numeri casuali chiedendoli,
uno alla volta, al generatore di  numeri casuali (con la funzione rand)
Confido che in questo modo, la sequenza di numeri casuali non
sia la stessa ogni volta che eseguo il programma.
Infatti se faccio:
<pseudocode>
srand(0);    //    0, o qualunque altra costante
int numbers[10000];
for ( int i=0; i<10000; i++ )
    numbers[i]=rand();
</pseudocode>
otterro' che numbers[] viene riempito molto probabilmente
con la stessa sequenza, ad ogni avvio del programma.
ma se faccio:
<pseudocode>
int numeroveramentecasuale=millisecondi_del_secondo_corrente();
srand(numeroveramentecasuale);
int numbers[10000];
for ( int i=0; i<10000; i++ )
    numbers[i]=rand();
</pseudocode>
allora la sequenza non sara' la stessa ogni volta
che lancio il programma:
la sequenza generata dipende dal momento del lancio.
Difficile beccare ogni volta
il millisecondo numero 200 del secondo vigente,
difficile ottenere la stessa sequenza.

 uno alla volta, al generatore di  numeri casuali (con la funzione rand)
Credevo che la domanda iniziale fosse proprio la richiesta di una
implementazione di rand (dato che quella standard e' notoriamente pessima).
So che in internet vi sono molti generatori di numeri casuali disponibili, ma
non ne ho mai avuto bisogno quindi non so dove. In ogni caso un domanda simile
era stata posta circa un mese fa, ergo un news archive dovrebbe avere ancora i
relativi post.


 difficile ottenere la stessa sequenza.
In questo modo otterresti solo una tra mille sequenze di diecimila
numeri, 
con distribuzione (e altre caratteristiche) ben distanti da quella che
dovrebbe
essere una sequenza casuale accettabile.
Ad esempio, se esegui il programma 1001 volte, almeno una sequenza di
10000 numeri 
verra' generata due volte, (probabilmente piu' di una sequenza).
/fabio

 numeri veramente (o magari "decentemente") casuali?
Per generare numeri la cui casualità è basata sugli spostamenti del mouse o
la pressione dei tasti puoi cercare yarrow nel web, ma io preferisco la
funzione che riporto adatta per winzozz (se usi BCB la puoi usare così
com'è).
Quello che mi sono inventato per i miei loschi scopi è un "incrocio" tra un
generatore multiply with carry e un self-shrinking LFSR. Ha una
distribuzione uniforme, ottime caratteristiche statistiche e buone doti
crittografiche.
Necessita di interi a 64 bits e può essere inizializzato con tre numeri a 32
bits.
Questa versione ritorna un intero a 32 bits ma è possibile estrarre un
numero qualunque di bits.
Noterai che il valore ritornato dal generatore viene accumulato prelevando i
bits dello stato (nc) solo quando il bit precedente è a 1.
Ciò consente di ottenere una velocità di accumulo variabile per cui i sedici
bits meno significativi del timer ad alta risoluzione di winzozz
(c.QuadPart) vengono letti ad intervalli casuali per cui l'uscita del prng è
da ritenersi "ragionevolmente" casuale. Tutto dipende da quello che ne devi
fare.
Il mio consiglio è:
- per applicazioni "serie" o crittografiche (il significato di "serie"
decidilo tu) utilizzalo *solo* per inizializzare un altro generatore di
caratteristiche matematicamente note e dimostrabili;
- per applicazioni senza pretese puoi tranquillamente utilizzarlo come vero
e proprio generatore (tieni presente che è piuttosto lento rispetto a un
"classico" generatore);
- se intendi utilizzarlo per inizializzare l'orripilante rand() sappi che mi
riterrò profondamente offeso :-)
Un'ultima osservazione da fare riguarda i tre valori iniziali (x2,x3,x4).
Anche se fossero inizializzati con valori fissi (es. x2=1,x3=2,x4=3)
l'uscita sarebbe completamente differente (dipendendo da c.QuadPart). Anche
nel caso (altamente improbabile) che c.QuadPart fosse identico al
microsecondo è molto probabile che l'uscita sia differente. Per cui
l'inizializzazione che utilizza time() e GetTickCount() garantisce
un'elevatissima imprevedibilità dell'uscita anche a causa della totale
assenza di correlazione tra i due valori ritornati dalle due funzioni.
ULONG QVC(void)
{
 LARGE_INTEGER c; static ULONG
x2=time(NULL),x3=GetTickCount(),x4=x2^x3,ca=0;
 ULONG R=0,k=0,nc; int flg=0,C;
 TRANSI:
 C=0; QueryPerformanceCounter(&c);
 UI64 x=2111111111ui64*c.QuadPart+1492ui64*x3+1776ui64*x2+5115ui64*x4+ca;
 nc=x; ca=x>>32; x4=x3; x3=x2; x2=nc;
 do {
  if(flg) { R<<=1; R+=nc&1; k++; flg=0; } else if(nc&1) flg=1;
  nc>>=1; if(++C==32) goto TRANSI;
 } while(k<32);
 return R;
}
Ciao
Cristiano

 con la stessa sequenza, ad ogni avvio del programma.
Viene riempito *sicuramente* con la stessa orribile sequenza.
Ciao
Cristiano


Fabio ha ragione! La variabile numeroveramentecasuale (che tutto è tranne
che casuale) conviene inizializzarla con i millisecondi+time() o con
time()^millisecondi (che è ancora meglio).
Se si vuol utilizzare un generatore disastrato già di per sé, converrebbe
almeno inizializzarlo quanto più decentemente possibile! Purtroppo, però,
inizializzare l'abominevole generatore con un numero veramente casuale non
risolve proprio nulla. Conviene, invece, inizializzare un buon generatore
con un numero "abbastanza" casuale.
Ciao
Cristiano

 </pseudocode>
io (e credo molti) inizializzo sempre il generatore di numeri casuali con il 'thick count'...
credevo avevi bisogno di un generatore di num casuali _vero_  ... ;-)
ciao
xaero

 </pseudocode>
io (e credo molti) inizializzo sempre il generatore di numeri casuali con il 'thick count'...


con un numero "abbastanza" casuale.
Concetto semplice: i computer sono sistemi deterministici. Un sistema
deterministico non può generare numeri realmente casuali. PUNTO.
Luc.

> Fabio ha ragione! >
lo so...
ma io avevo dato solo il "la" per
far si' che il generatore
di numeri casuali implementato in rand
smettesse di generare sequenze costanti.
ovviamente il tutto e' piu' che perfettibile,
e a seconda dell'esigenza del postulante
-deve simulare eventi statistici veramente casuali
o deve generare un fondo stellato per un videogioco?-
puo' essere migliorato.
vedere il post di Cristiano a questo proposito,
piu' in giu' nel thread.

 deterministico non può generare numeri realmente casuali. PUNTO.
Dipende da cosa intendi per "casuale". Quando un sistema si "muove" in
uno spazio di configurazioni molto vasto tali configurazioni possono
essere considerate praticamente casuali.
EMG

essere considerate praticamente casuali.
Una distribuzione uniforme può non essere realmente definita casuale,
anzi, si sa dall'inizio come va a finire... certo, c'è la legge dei
grandi numeri, però li sforiamo in argomenti troppo
matematici/statistici per me 8)
Luc.

 deterministico non può generare numeri realmente casuali. PUNTO.
Il tuo "PUNTO." a caratteri cubitali era da evitare visto che quello che
dici è sbagliato. Il discorso va continuato dicendo che circuiti come la
scheda audio e microprocessori crittografici (come quelli della serie intel
8xx) permettono al computer di generare numeri casuali.
La differenza tra numero casuale e pseudocasuale è esclusivamente
rappresentata dal modo con cui viene generata la sequenza di bits.
Se la sequenza viene generata usando una o più funzioni matematiche che
manipolano i bits generati in precedenza i bits saranno sicuramente
pseudocasuali, se invece viene generata leggendo lo stato di un particolare
dispositivo elettronico in opportune condizioni di funzionamento i bit
saranno sicuramente casuali.
Un'altra certezza è rappresentata dall'abominevole rand(); non c'è alcun
motivo per usarla perché:
1. RAND_MAX è generalmente un numero a 16 bits (che assurdità!);
2. l'implementazione normalmente viene fatta peggiorando la già critica
situazione invertendo i bits meno significativi con quelli più significativi
(in un lcg i bits meno significativi hanno una casualità molto inferiore
rispetto a quelli più significativi);
3. ha un periodo terribilmente corto;
4. un generatore molto migliore può essere implementato semplicemente
facendo: y(i)=y(i-1)*a+b (a e b devono essere appropriati!) per esempio
ULONG y=1664525L*y+1013904223L (cfr Numerical Recipes c7-1.pdf pag. 284)
5. ottimi e velocissimi generatori vengono implementati con pochissime righe
di codice e pochissime risorse del computer.
Il mio dubbio, invece, riguarda la funzione QVC() che ho presentato ieri. In
quel caso la sequenza è generata matematicamente, però c'è l'influenza di un
timer ad alta risoluzione letto ad intervalli casuali o difficilmente
determinabili: io sono quasi certo che il generatore sia di numeri casuali,
purtroppo la mia matematica non mi consente di poterlo provare. Se qualcuno
fosse in grado di dimostrare che razza di generatore sia QVC() avrebbe la
mia gratitudine!
Cristiano

 Quando un sistema si "muove" in uno spazio di configurazioni molto vasto
tali configurazioni possono essere considerate praticamente casuali.
Immagina un lcg y(i)=y(i-1)*a+b mod n con n=2^1234567890, si "muove" fra
numeri immensamente grandi eppure la sequenza è perfettamente prevedibile e
quindi non casuale.
Ciao
Cristiano

 anzi, si sa dall'inizio come va a finire...
Se il generatore è di numeri pseudocasuali!
Ciao
Cristiano


Ma funziona con il g++ per Linux?


 quindi non casuale.
E' prevedibile perché ne conosci a priori la regola altrimenti non lo
sarebbe.
EMG

 8xx) permettono al computer di generare numeri casuali.
Non sono d'accordo. In assenza di un evento esterno neppure un circuito
complicatissimo puo' garantire la vera casualità. Quello che puoi ottenere al
massimo e' una sequenza che ha delle proprietà statistiche motlo simili o
identiche a quella che avrebbe la sequenza casuale. Piu' sono complesse le
proprietà statistiche che analizzi piu' e' difficile generare una sequenza che
sembri casuale.
L'utilizzo di valori di scansione video, timer ad altissima risoluzione e cose
simili ti permette di avvicinarti molto alla generazione di una sequenza
apparentemente casuale. Ma senza l'intervento esterno di un evento non
deterministico (ovvero per definizione casuale) la tua sequenza sara' in un modo
o nell'altro senpre solo pseudo-casuale.


 numero ha la stessa identica possibilità di uscire.
Un conto e' dire che una sequenza infinita di eventi casuali ha una distrbuzione
uniforme. Un altro conto e' dire che una sequenza di eventi avente distribuzione
uniforme e' casuale. La prima affermazione e' vera. La seconda e' falsa.


 Ma funziona con il g++ per Linux?
Non lo so. Se riesci a leggere un timer ad alta risoluzione basta che ne
sostituisci il valore a c.QuadPart.
Ciao
Cristiano

 sarebbe.
Certo che lo sarebbe! Se conosci due soli valori y impostando un sistema a
due equazioni lineari e due incognite determini facilmente a e b.
In crittografia un lcg è quanto di più semplice possa essere "craccato",
cioè conoscendo due soli valori posso prevederli tutti!
Cristiano

 nell'altro senpre solo pseudo-casuale.
Ma esistono eventi "non deterministici", quando persino il comportamento
delle particelle elementari può essere previsto, almeno in termini
statistici?
EMG

 o nell'altro senpre solo pseudo-casuale.
Anche in questo caso se fosse vero ciò che dici nessuno si metterebbe a
costruire circuiti per generare numeri casuali! Basterebbe semplicemente
mettere il microfono di una scheda audio fuori dalla finestra e aspettare il
passaggio del motorino a manetta, dell'aereo a bassa quota...
E' chiaro che una banca o un ente militare non può aspettare il passaggio di
un motorino per generare una chiave casuale necessaria per cifrare un
messaggio da trasmettere a chissà chi. Ma è anche vero che non possono
nemmeno rischiare di vedersi "craccato" il generatore pseudocasuale
dall'hacker di turno. Per questo esistono circuiti in grado di generare
numeri casuali senza bisogno di alcuna sorgente esterna di "rumore" (o
meglio di entropia).
Cristiano

 sostituisci il valore a c.QuadPart.
Da alcune prove appena terminate, ai fini della qualità statistica del
generatore sembra valido anche un timer come GetTickCount() che s'incrementa
di una unità ogni 5 ms (sotto winzozz). Quindi se disponi di qualcosa di
simile direi che puoi usarlo tranquillamente. Ovviamente perderai in
casualità e quindi raccomanderei maggiormente di non usarlo per scopi
crittografici.
Cristiano

 wrote in message
news:3AEA9242...@flashnet.it...

A parte che una previsione statistica non e' una previsione deterministica,
qualunque evento che sia esterno al sistema in esame puo' essere visto dal
sistema come non deterministico. Naturalmente se prendi in esame un sistema
allargato potresti anche trovarti a risolvere il determinismo. Ma ci sono casiin
cui la tua capacità non e' tale.
Se per esempio consideri il tuo PC come sistema, potresti dire che il tempo che
intercorre fra la ricezione di due pacchetti IP e' non deterministico.
Ma se allarghi il sistema e noti che il cavo e' perfetto e non da luogo a retry
e che la rete comprende solo due PC non altrimenti networked e conosci in che
modo l'altro PC ti spedisce i dati, ecco che ritorni ad un valore deterministico
(almeno in teoria).
Comunque in un PC che non sia "unsupervised" c'e' un ottimo modo per avere un
valore non deterministico: il valore dei bit meno significativi del timer ad
alta risoluzione nel momento in cui viene premuto un tasto sulla tastiera. Ovvio
che questo ti fornisce un solo valore, non una sequenza. Il non determinismo
deriva dal fatto che nel sistema allargato rientra un fattore umano il quale non
e' in grado di generare una azione deterministica (in senso temporale) con una
precisione superiore a tot.
Il fatto che poi per ottenere una sequenza casuale di parecchie migliaia di
valori non puoi chiedere all'operatore di trascrivere l'enciclopedia britannica
e' un'altro discorso. Ergo i generatori pseudo casuali. Che come sappiamo non e'
necessario inizializzare con un valore veramente casuale ma piuttosto con un
valore abbastanza casuale (salvo poi avere un ottimo generatore!).


 wrote in message
news:9ce2hn$i9a$1...@news.mclink.it...


 dall'hacker di turno.
Non stai parlando di sequenze casuali, stai parlando di crittazione. La solidità
del messaggio crittografato dipende abbastanza poco dal livello di casualità del
generatore usato per le chiavi. Dipende molto invece dalla lunghezza delle
chiavi e dall'algoritmo di crittazione usato.


 chiavi e dall'algoritmo di crittazione usato.
Una cosa che mi era sfuggita. Nota che molti algoritmi crittografici fanno uso
di un generatore pseudocasuale anche nell'algoritmo stesso, non solo quindi per
generare le chiavi ma anche nella sequenza di codifica per-se.
Ma questo generatore, pur dovendo avere una ottima risposta statistica per
evitare che in caso di attacco si possa decodificare tutto il messaggio dopo
averne decodificato solo una parte, deve anche essere per definizione
pseudo-casuale, dato che la stessa sequenza generata dal crittatore deve essere
rigenerabile dal decrittatore. In altre parole per questo scopo una sequenza
veramente casuale ... e' inutile in quanto per definizione irripetibile.


 sostituisci il valore a c.QuadPart.
Ovviamente anche la chiamata all'API di windows per il timer ad alta risoluzione
... devi sostituirla con qualunque cosa ci sia di corrispondente (se c'e') nel
tuo OS.
--
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556
"Andrea Ferro" <And...@UrkaDVD.it> wrote in message
news:9ceola$4uu$1...@serv1.iunet.it...

 cioč conoscendo due soli valori posso prevederli tutti!
Si, ma č solo un caso particolare. In generale non č cosě facile.
EMG

 se molte sequenze casuali possono avere qualità statistiche pessime.
Come ho già detto, il mio dubbio è che esistano effettivamente fenomeni
in grado di generare eventi veramente casuali e cioè che non seguano
alcuna regola, per quanto complessa e magari non ancora scoperta.
EMG

 wrote in message
news:3AEABE16...@flashnet.it...

Se la metti sul piano assoluto!
Se il tuo sistema e' finito, tutto cio' che avviene al suo esterno e che lo
influenza in una maniera da esso non prevedibile e' casuale.
Ovvio che se il tuo sistema e' l'universo definito come il tutto ... l'esterno
e' solo cio' che ancora di esso non conosci, ovvero cio' che non riesci a
prevedere per incapacità, non per imprevedibilità.
Sempre che non si riesca a dimostrare che la fisica quantistica e, in
particolare, il principio di non determinazione, non sono solo "il meglio che
abbiamo per ora" ma sono effettivamente "la legge universale fondamentale".



Certo, io stesso ho detto che il piů semplice. Ma *tutti* i generatori non
crittograficamente sicuri sono craccabili per quanto complessi siano.
Cristiano

 Dipende molto invece dalla lunghezza delle chiavi e dall'algoritmo di
crittazione usato.
E' rigorosamente vero solo per gli algoritmi a chiave asimmetrica (o
pubblica) per quelli a chiave simmetrica non è proprio così. Ma qui andiamo
molto fuori dal seminato... :-)
Cristiano

 a 64 bit, qualunque cosa questo sia nel tuo compilatore, ammesso che ci
sia.
Va bene, ma è importante precisare che sia qualcosa che varia da solo e
abbastanza frequentemente.
Cristiano


Non te lo so dire. Andrea ti ha comunque dato delle valide risposte in
merito.
Per quello che riguarda i generatori di numeri casuali l'importante è che
non ci sia alcun algoritmo in grado di provare che una sequenza non è
casuale in un tempo calcolabile tramite un polinomio. Cioè tutti gli attuali
algoritmi per testare la bontà di un generatore vengono eseguiti in un tempo
proporzionale alla lunghezza della sequenza da controllare e il tempo può
essere calcolato tramite un polinomio.
Se qualcuno dicesse, per esempio, di aver trovato un test in grado di
"certificare" una sequenza come non casuale ma il tempo di esecuzione fosse
infinito non potrebbe mai dimostrare ciò che dice. Ovvio!
In definitiva, per i nostri scopi, non è necessaria l'assoluta certezza che
una sequenza sia casuale, è necessario che non esistano algoritmi in grado
di dimostrarlo in un tempo polinomiale.
Cristiano

 numeri pseudocasuali per i quali basta un generatore deterministico.
L'importante comunque e' che il periodo sia molto piu' lungo della sequenza che
devi usare. Nota che anche tu distingui i generatori deterministici (quelli
generabili da un PC senza HW specifico) da quelli di numeri casuali.


 generatori per classificarli in buoni e cattivi.
Come dicevo sopra i generatori cattivi non li ho mai visti (tranne uno...)
eccetto quelli che m'invento prima di metterli a punto.
Se tu m'indicassi un test in grado di giudicare cattivo anche uno solo dei
generatori in circolazione mi faresti cosa immensamente gradita.

(?) C'è stata un'interferenza? Non riseco a legare la tua risposta con
quello che c'è più sopra. Comunque sono totalmente d'accordo con quello che
dici.
Forse volevi dire che un generatore di numeri casuali non è necessario che
superi i test statistici?

Certo che li distinguo, sono due cose totalmente diverse!
Invece, leggendo la tua risposta all'inizio di questo messaggio, sembra che
tu non faccia troppa distinzione tra i due tipi.
Cristiano

 Grazie
 
Sotto Unix/linux puoi usare gettimeofday() che ti riempie una struct
timeval contenente, in due interi da 32 bit, il numero di 
secondi e di microsecondi a partire dal 01/01/1970 e quindi 
cambia abbastanza frequentemente (un milione di volte al 
secondo).
/fabio


tanti modi!
Certo, con hardware dedicato (e quasi sempre ancora pseudo-casuale)...
Luc.

 tu non faccia troppa distinzione tra i due tipi.
Cerco di riassumerti la mia posizione attuale perche' credo che in fondo la
pensiamo nello stesso modo. E comunque sono anni che non mi occupo di generatori
di numeri casuali/pseudocasuali e di crittografia:
1) per qualunque uso pratico, un generatore adatto e' quello che supera i test
che tu stesso scrivi in base all'uso che ne vuoi fare. Per alcuni scopi puo'
persino andare bene il generatore della libreria C.
2) per una definizione piu' astratta di casuale/pseudocasuale, qualunque
generatore algoritmico e' pseudocasuale ed in grado di generare sequenze
ripetibili, generatori non algoritmici possono essere considerati casuali se noi
non siamo in grado di predire l'output (ovviamente intendo predirlo
statisticamente, salvo che come limite su sequenze lunghe). Il che in un certo
senso ci riporta al punto 1
3) definire se in un sistema allargato (cioe' l'universo) esiste o meno la
casualità in senso assoluto e' una questione aperta e probabilmente piu'
filosofica che fisica: nota che persino il principio di indeterminazione non e'
sufficiente a dimostrare l'esistenza della casualita. Indica solo
l'impossibilità di determinare due "misurabili" contemporaneamente (salvo
"misure" statistiche). E non e' comunque un problema di "informatica".


 secondo).
Il fatto che l'unità di misura sia in microsecondi non significa che la
risoluzione sia anch'essa in microsecondi.


 risoluzione sia anch'essa in microsecondi.
 
Ovviamente...
Un limite superiore e' dato dalla frequenza del processore ;-)
Comunque intendevo dire che puo' essere considerato un sostituto
adeguato per la GetTickCount() di Windows.
/fabio

 adeguato per la GetTickCount() di Windows.
Questo credo proprio di si. Unità di misura in millisecondi o microsecondi ma
risoluzione efficace dell'ordine del decimo.


 pensiamo nello stesso modo. [...].
In tutti e tre i punti sono d'accordo praticamente su tutto, perfino su
rand() (!) (non credo sia il caso di puntualizzare oltre...).
E' stata una piacevole conversazione, speriamo che abbia interessato anche
altri.
Ciao
Cristiano

 Certo, con hardware dedicato (e quasi sempre ancora pseudo-casuale)...
La scheda audio non mi sento di chiamarla "hardware dedicato".
Cristiano

 quello del bus).
Su molti pc che ho provato la frequenza del timer ad alta risoluzione è
1193180 Hz.
Cristiano

La scheda audio non mi sento di chiamarla "hardware dedicato".
Non puoi supporre che tutti l'abbiano installata... Non è mica una sk
video... 8/
Luc.

 video... 8/
Non ho supposto proprio nulla.
Tu hai detto che un computer non può generare numeri casuali;
io ho detto che può generarli in tanti modi;
tu hai detto con hw dedicato;
io ho detto che la scheda audio non è un hw dedicato alla generazione di
numeri casuali, se poi non tutti ce l'hanno non capisco cosa c'entra con
quello che stiamo dicendo!
Credo sia meglio interrompere questa specie di battibecco; finora è andato
tutto liscio...
Cristiano

video... 8/
Ho seguito questa discussione fin dall'inizio ed ho deciso di provare
a costruire un generatore HW di numeri casuali e trasferire i dati al
computer tramite la parallela. Domani (ho già chiesto al mio prof di
elettronica) in laboratorio ci provo.
Se salta fuori qualcosa di decente vi faccio sapere magari posterò, a
chi vorrà il progetto, tanto per vedere se l'idea è buona o da
scartare.
Domani pomeriggio (se riesco a finire in tempo il circuito) vi faccio
sapere.
Il mio prof di informatica oppure quello di matematica hanno qualche
buona idea per creare un generatore di numeri casuali, chiedo (come
progetto da sviluppare non è male). 
Ciao
Diego the dolphin
-- 
Parafrasando Cartesio, "Digito, ergo sum." (D. Zanga)

 scartare.
Anche se saltasse fuori qualcosa d'indecente :-) facci sapere lo stesso;
sarebbe interessante ugualmente ragionarci sopra.
Buon lavoro
Cristiano


Grazie, 
spero di poterlo fare.


 a frequenze molto alte per noi ad esempio 500KHz.
Esattamente il problema che incontrai io tanti anni fa. E alzare la
frequenza di campionamento non lo risolverebbe di certo. Chissà se
esiste una soluzione...
EMG

 del tipo di luminosità o meglio di temperatura.
Una tecnica usata è misurare la variazione di frequenza di un oscillatore
libero senza il bisogno di sensori esterni che potrebbero pregiudicare la
casualità se la sorgente non fosse casuale.
Se riesci nell'intento, se riesci ad accumulare qualche milione di bit e se
vuoi, potresti inviarmeli in modo che io possa sottoporre la sequenza di
bits ad alcuni test statistici.
Cristiano

 esiste una soluzione...
forse considerando l'intervallo di tempo tra picchi, invece che il 
valore dei picchi stessi, magari in cicli di processore o comunque xon 
una buona granularita', dovrebbe dare buoni risultati, no?

"Enrico Maria Giordano" ha scritto:

Se avevi questo problema significa che la sorgente non era casuale. Anche tu
usavi lo stesso principio di Diego?
Cristiano

bits ad alcuni test statistici.
Se riesco ad avere il tempo (siamo a Maggio, sinonimo di verifiche e
interrogazioni a tutto andare) lo faccio sabato con il prof. sperando
di riuscire a leggere dalla parallela (attualmente tutti i tentativi
fatti dal prof. con i PC della scuola hanno fallito miseramente).
Se riesco a raccimulare qualcosina ti faccio sapere (magari faccio
qualche domanda mirata al prof. di calcolo statistico sugli eventi
casuali).
Domani sento il prof. di mate, chissà forse ha qualche idea.
Se salta fuori una buona idea chiederò al prof. di info di assegnari
come programma di maggio/giugno la funzione di gestione e di analisi.


 altro.
Chiariscimi allora questo punto: se la banda delle tensioni prodotte da
un qualunque segnale casuale va uniformemente da v1 a v2, a me sembra ci
sia un problema di taratura nel posizionare esattamente i due estremi in
corrispondenza dei valori digitali minimo e massimo desiderati.
EMG


Forse. Però così il generatore di numeri casuali non sarebbe altrettanto
veloce.
EMG

 sviluppi sugli algoritmi, no???
Hai ragione. Se vogliamo proseguire questo blocco (magari anche con EMG che
è ferrato in questo settore) spostiamoci (vogliamo proseguire?).
Cristiano

"Enrico Maria Giordano" ha scritto

Probabilmente sì o comunque sarebbe abbastanza complicato azzeccare con
esattezza v1 e v2. La cosa migliore da fare con i generatori casuali,
secondo me, è accumulare una sequenza di bits anziché convertire un segnale
analogico in digitale; per esempio nel caso del rumore termico forse
converrebbe in ogni caso convertire il rumore in un numero senza
preoccuparsi troppo di "beccare" v1 e v2 e concatenare i numeri fino ad
ottenere la sequenza della lunghezza voluta.
A quanto ne so, l'unico motivo valido per avere una sequenza di bit casuale
scaturisce solo per esigenze crittografiche, in ogni altro settore che mi
viene in mente non è necessaria tanto la casualità quanto le buone qualità
statistiche della sequenza. Per cui l'esigenza di generare casualmente dei
numeri entro due limiti precisi non dovrebbe essere avvertita (almeno credo
:-)).
(Vogliamo seguire il consiglio di Diego e spostarci su
it.hobby.elettronica?)
Cristiano

 usavi lo stesso principio di Diego?
Da quello che ho capito, si.
EMG

 è ferrato in questo settore) spostiamoci (vogliamo proseguire?).
No, non sono affatto ferrato. Me ne sono occupato solo di sfuggita e
superficialmente. Quindi lasciamo pure cadere il discorso.
EMG

superficialmente. Quindi lasciamo pure cadere il discorso.
Non ho capito, lasciamo perdere????


 Non ho capito, lasciamo perdere????
Si, da parte mia si.
EMG

 Non ho capito, lasciamo perdere????
Se non hai altro da dire sì, se hai altro da dire no :-)
In ogni caso se hai qualche novità in merito al generatore che tenti di
costruire mi piacerebbe se mi scrivessi in privato.
Ciao
Cristiano