Newsgroup: it.comp.lang.c++
Titolo: Grafica e Random

Ciao a tutti.
Utilizzo il compilatore "Bloodshed Dev-C++ 4"
scaricato dalla rete e cercando di utilizzare nei miei
programmi anche della grafica mi sono accorto che
mancano gli header relativi. Stessa cosa cercando di
utilizzare la funzione random per la generazione dei
numeri casuali. Chi e' a conoscenza di questi problemi
potrebbe darmi dei consigli? Su quale compilatore mi
conviene scaricare o se si puo' fare qualcosa usando
il dev-c++ stesso?
PS
forse mi sbaglio ma sembra che questi stessi problemi
si presentano pure su linux. Vi risulta?
ciao.
______________________________________________________________________
Do You Yahoo!?
Il tuo indirizzo gratis e per sempre @
yahoo.it
 su 
http://mail.yahoo.it
-- 
Posted from 
web12302.mail.yahoo.com
 [216.136.173.100] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 potrebbe darmi dei consigli? [...]
E' una vera fortuna che tu non possa utilizzare srand() e rand() con il tuo
compilatore!
Al posto di queste due orribili funzioni io ti consiglio di utilizzare
"almeno" la seguente, che *sicuramente* dà risultati di gran lunga migliori:
unsigned long BCPL(void)
{
 static unsigned long y=SEME;
 y=1664525L*y+1013904223L; // Numerical Recipes c7-1.pdf pag. 284
 return y;
}
al posto di SEME devi usare un unsigned long quanto più variabile possibile:
di solito va bene timer(NULL), GetTickCount() o qualunque altra cosa vari
sufficientemente per i tuoi scopi.
Cristiano

 "almeno" la seguente, che *sicuramente* dà risultati di gran lunga migliori:
Sei sicuro che dia risultati di gran lunga migliori?
Di sicuro non da risultati migliori della rand() del mio compilatore.
E' ora di finirla di sparare cazzate sulle funzioni della
libreria standard solo perche' una volta si e' trovata una brutta
implementazione in un compilatore vecchio e non conforme.
Con il tuo ragionamento tutte le funzioni della libreria standard 
(e anche di altre librerie) fanno schifo e sono completamente
inutili.  Per esempio atof sbaglia i conti, getline() richiede
di premere 2 volte Enter, iostream e' 70 volte piu' lento di printf
(ma anche 70 volte piu' lento di iostream di tutti gli altri 
compilatori), ...
A fare schifo non sono le funzioni ma l'implementazione di alcune
librerie (o magari e' sempre la stessa?)
rand() e' un discreto generatore che va bene nella maggior parte
dei casi (non tutti stanno scrivendo programmi di simulazione
particolarmente critici).  Quando poi uno ha esigenze particolari
ci sono altri generatori con caratteristiche specifiche (es.
http://www.boost.org/libs/random/index.html
).
	Mauro

 (es. 
http://www.boost.org/libs/random/index.html
).
Bene! Lì ci sono due generatori che vale la pena utilizzare: il Mersenne
Twister e il lagged Fibonacci (detto tra noi il codice originale è molto più
leggibile e funzionale).
Ma, ovviamente, ce ne sono moltissimi altri e ognuno di questi è
*sicuramente* migliore di rand() anche solo per il fatto che normalmente
rand() non si sa come viene implementata.
Cristiano

 > > migliori:
e' semplicemente falsa.
La tua funzione non da *sicuramente* risultati di gran lunga migliori,
e non ci trovo nessuna fortuna ad avare una libreria senza rand().
La tua funzione puo' dare risultati migliori di quella standard
su alcuni compilatori (che e' un po' diverso da "sicuramente da
risultati di gran lunga milgiori"), ma questo non e' un motivo
sufficiente per dire a tutti di evitare come la peste quelle
"orribili funzioni".
Per qualsiasi funzione della libreria standard esiste almeno un
compilatore con un implementazione pessima della funzione, seguendo
lo stesso ragionamento bisognerebbe evitare tutte le funzioni e 
riscrivesi tutto a mano ogni volta.
Ovviamente esistono programmi che non possono fare affidamento
su rand() e hanno bisogno di generatori migliori (algoritmo noto,
garanzie sulla sequanza generata, ...), ma questi programmi sono
in minoranza.
	Mauro

 in minoranza.
Mah! Ho dei dubbi! Se io uso atof() *voglio* che sia *sempre* affidabile e
che funzioni sempre in modo prevedibile indipendentemente dal programma che
scrivo; ma questo vale per qualunque funzione tra cui rand().
Cristiano

 cui rand().
tanto per chiarire:
The ANSI C standard suggests three possible implementations of the 
rand() function. The simplest implementation outlined in the standard 
returns values where the low order bits are not random. The simplest 
implementation is also the fastest and smallest.
poi gcc usa questa tecnica: 
(man 3 rand)
       The  versions of rand() and srand() in the Linux C Library
       use the same random number generator as random() and sran­
       dom(),  so the lower-order bits should be as random as the
       higher-order bits.  However, on older  rand()  implementa­
       tions,  the lower-order bits are much less random than the
       higher-order bits.
       In Numerical Recipes in C: The Art of Scientific Computing
       (William  H.  Press, Brian P. Flannery, Saul A. Teukolsky,
       William T.  Vetterling;  New  York:  Cambridge  University
       Press, 1992 (2nd ed., p. 277)), the following comments are
       made:
              "If you want to generate a random integer between 1
              and 10, you should always do it by using high-order
              bits, as in
                     j=1+(int) (10.0*rand()/(RAND_MAX+1.0));
              and never by anything resembling
                     j=1+(rand() % 10);
              (which uses lower-order bits)."
       Random-number generation is a complex topic.  The  Numeri­
       cal  Recipes  in  C book (see reference above) provides an
       excellent discussion of practical random-number generation
       issues in Chapter 7 (Random Numbers).
       For  a  more theoretical discussion which also covers many
       practical issues in depth, please see  Chapter  3  (Random
       Numbers) in Donald E. Knuth's The Art of Computer Program­
       ming, volume 2 (Seminumerical Algorithms), 2nd ed.;  Read­
       ing,  Massachusetts:  Addison-Wesley  Publishing  Company,
       1981.
a dispetto di quanto indicato, lo stesso risultato si ha dando man 3 
rand su un port win32. 
la conclusione mi sembra ovvia: se ti sta tanto a cuore rand(), passa 
al gcc, e userai sempre la versione "allo stato sell'arte" di rand() e 
di molto altro.

 passa al gcc, e userai sempre la versione "allo stato sell'arte" di rand()
e di molto altro.
Non esagerare! Io uso il gcc per programmare su amiga e so quanto sia
valido, ma lo stato dell'arte di rand() non verrà mai implementato in alcuna
libreria standard.
Io penso che il classico lcg sia stato implementato per ottenere la massima
velocità (e pessimi risultati) quando i computer erano piuttosto lenti
rispetto ad oggi, ma ormai non è più tollerabile un tale generatore. Sarebbe
sufficiente definire nello standard un buon generatore a scorrimento (non è
certo una lumaca!) che sia sempre quello per tutti i compilatori senza dover
andare incontro a problemi di portabilità, di bit meno significativi "poco
casuali" e quant'altro. Ci si riuscirà un giorno?
Cristiano

 (dove è scritto quello che hai riportato?).
man 3 rand, l'ho scritto in alto. poi non puoi paragonare l'amiga (OS 
splendido, tra l'altro) al mondo unix (professionale per definizione)
se invece ti piacciono i RNG, e vuoi una funzione talmente sicura che 
ti pagano 100$ se dimostri che non e' casuale, Numerical recipes in C, 
2nd edition,  capitolo 7, pag 281.

 2nd edition,  capitolo 7, pag 281.
rettifico: 1000$, mi era sfuggito uno 0

 2nd edition,  capitolo 7, pag 281.
Hai fatto un po' di confusione; l'autore del libro non dice che il suo
generatore è sicuro (perché non lo è assolutamente) lui dice che offre 1000$
a chi scrive un test statistico che ran2 fallisce escludendo le limitazioni
dovute ai tipi float. E' come se io offrissi 1000$ a chi mi vincesse in una
partita a bridge escludendo le limitazioni dovute al fatto che non ci so
giocare! :-)
Scherzi a parte, quel tipo di generatore è ampiamente superato e
sconsigliabile in quanto esistono generatori molto migliori scritti in modo
molto più comprensibile e supportati da solide basi matematiche; solo per
fare un esempio: ran2 ha un periodo di circa 2*10^18, MWC1029 oltrepassa
10^9824, MT19937 circa 10^6000; ran2 usa solo 24 bits dei float, mentre la
maggior parte dei generatori danno 32 bit; si potrebbe continuare... ma
credo che questo basti. :-)
Cristiano

 potrebbe continuare... ma credo che questo basti. :-)
basta, si per concludere il discorso, ma resta il fatto che per gli 
scopi di livello medio-basso (gen pacchetti TCP, crittaggio on the fly, 
etc...) rand del gcc 2.95 e superiori e' piu' che adeguata. per altre 
implementazioni, per livelli medio alti, basta ran3 (cit, pag 283) o 
per la migliore inmplentazione possibile, la suddetta ran4. indipercui, 
mi sembra inutile, superfluo e ridicolo riscriversi da soli le funzioni 
rand per applicazioni giocattolo o  che comunque non richiedano 
"paranoia", e assurdo cercare un'implementazione migliore di ran4 
quando non ti pagano per farlo, e hai tempi di consegna stringenti.
poi se vuoi argomentare il perche' tu pensi il contrario, fallo e 
vediamo se sbaglio io, tu o entrambi ;)

 vediamo se sbaglio io, tu o entrambi ;)
Perché penso il contrario te l'ho detto, se vuoi che ti dica che tu hai
ragione, io te lo dico: hai ragione! :-)
Cristiano

 chiedo a te, puoi dirmelo?
Dal manuale (pero' non sono sicuro che sia aggiornato):
   The random() function uses a non-linear additive  feedback
   random  number generator employing a default table of size
   31 long integers to return successive  pseudo-random  num­
   bers  in the range from 0 to RAND_MAX.  The period of this
   random  number  generator  is  very  large,  approximately
   16*((2**31)-1).
	Mauro

"Mauro Casini" ha scritto:

AH! AH! AH!
Non sto ridendo di te (anzi ti ringrazio per avermelo fatto sapere), ma del
generatore. Mi sembrava impossibile che un generatore "di serie" potesse
essere una cosa ben fatta!
Si legge "Il periodo è molto grande" (3,4*10^10): ROTFL.
Un'ultima risata ce la potremmo fare se tu mi postassi anche il valore di
RAND_MAX (tiro a indovinare: 2^31-1 o peggio?).
Questi generatori hanno ottime proprietà statistiche (non questa
implementazione, ovviamente!) ma un'inizializzazione critica, cioè se il
vettore iniziale (in questo caso solo 31 long) non viene inizializzato a
dovere, il risultato è pessimo: i numeri risulteranno fortemente correlati
(peggio che in un lcg). Per questo motivo si legge che il generatore ha una
tabella già inizializzata e quindi viene a mancare il grosso vantaggio di
poter usare come seme iniziale ben 31*31 bit.
E' doveroso precisare che (come ci si poteva aspettare) questo generatore è
sicuramente migliore di quelli normalmente implementati sotto winzozz (che a
quanto ne so sono tutti lcg peggiori del normale).
Grazie al tuo messaggio bisogna convincersi ancor di più che per
applicazioni
che non siano il compito in classe d'informatica non deve mai essere
utilizzata l'abominevole rand(). E' molto più semplice e sicuro copiare uno
dei tanti ottimi generatori in circolazione e linkarlo in tutti i programmi
in cui corriamo il rischio di usare rand().
Cristiano

 che scrivo; ma questo vale per qualunque funzione tra cui rand().
certo che pretendere un comportamento prevedibile da rand() :-)))
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

 serie" potesse essere una cosa ben fatta!
su linux e su ogni unix serio, esistono /dev/rand /dev/urand, che viene 
usato alla bisogna: inizializza il random seed con valori che sono i 
timings delle pressioni dei caratteri, delle letture da disco, 
variamente rimescolati, come puoi vedere dai sorgenti di linux. 
prima di ridere, accertati di come funzionino le cose.

 certo che pretendere un comportamento prevedibile da rand() :-)))
Non so se ho capito il senso della tua frase: tu vuoi dire che rand() č
imprevedibile?
Se č cosě devi sapere che rand() č un generatore perfettamente prevedibile
(essendo una semplice ricorrenza matematica).
Cristiano

 prima di ridere, accertati di come funzionino le cose.
/dev/rand è ritenuto un buon generatore d'entropia, cioè di bit veramente
casuali (se fossimo in un altro contesto ci sarebbe da dire qualcosa in
merito). Ma se questi preziosi bit vengono usati per inizializzare
l'abominevole generatore... Quello che vado dicendo da mesi e mesi è che
l'implementazione di rand() è un aborto; puoi inizializzarla come ti pare,
ma tale resta.
Gli utenti di unix hanno un motivo in più per utilizzare un generatore che
usa molti bit come seme (MT19937, TT800, R250, gli lfsr): lo possono
inizializzare con bit veramente casuali.
Cristiano

 utilizzata l'abominevole rand().
Quali sono le applicazioni che hanno bisogno di un generatore
migliore? Sei sicuro che siano la maggioranza?
	Mauro

 Sei sicuro che siano la maggioranza?
Sì.
Cristiano

 winzozz.
fai cosi': visto che sei un esperto del campo, vai sul sito della gnu 
(
www.gnu.org
), cerchi il CVS della stdlib, ti leggi il sorgente di 
rand, e ce lo commenti. ma dopo, pero'. prima leggitelo

"zio pioppo" ha scritto nel messaggio:

Tu, invece, fa così: visto che mi stai dando degli ordini, vai sul sito
della gnu, cerchi il CVS della stdlib, posti il sorgente di rand (se si
può), e se qualcuno del ng ha voglia te lo commenta.
Prima, però, impara un po' di buona creanza!
Io sto soltanto mettendo in guardia i programmatori seri circa i problemi
che possono insorgere utilizzando rand() (mentre tu e tuoi due amici non
state dicendo niente di concreto).
Se hai qualche domanda o osservazione seria la puoi fare senza problemi; se
ti sembra che io stia dicendo delle fesserie puoi senz'altro ribatterle con
argomentazioni concrete.
Cristiano

 (essendo una semplice ricorrenza matematica).
guarda che c'era una faccina :-), era evidentemente una battuta.
Cmq tu parlavi di prevedibilità tra un'implementazione e l'altra: anche 
ipotizzando che tu conosca il seme con cui viene inizializzato non puoi 
comunque prevederne il comportamento.
Anto


 senz'altro ribatterle con argomentazioni concrete.
a me sembra invece che tu parta in malafede, contro i compilatori e le 
librerie, guarda un po'.
cmq, visto che non hai nemmeno la voglia di verificare se le tue 
ipotesi aprioristiche corrispondono a realta', non mi sembra che tu 
abbia molta serieta' scientifica...
ti do' comunque i link al codice, visto che sono curioso di sapere come 
lo giudicherai. 
nota: il codice che segue e' sotto licenza GPL.
questo e' il codice in rand.c
/* Return a random integer between 0 and RAND_MAX.  */
int
rand ()
{
  return (int) __random ();
}
come ti e' gia' stato detto da SuPeR, e' implementata tramite random, 
il cui codice e' troppo lungo per essere riportato, quindi sotto trovi  
il link. una cosa: la conversione a int e' richiesta dal C99. se vuoi 
un long, usi direttamente __random. comunque su molte macchine a 32 bit 
long e int sono uguali come lunghezza.
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/stdlib/random.c?rev=1.16&content-type=text/x-cvsweb-markup&cvsroot=glibc

 comunque prevederne il comportamento.
Il contesto forse era un altro: Mauro diceva che i programmi che necessitano
di una rand() affidabile sono la minoranza. Io, invece, sostengo che tutti i
programmi che usano rand() necessitano di un generatore affidabile (anche
solo per il semplice motivo che la devono usare).
In questo contesto io ho portato l'esempio che volendo usare atof() questa
deve essere sempre affidabile e prevedibile; non ci deve essere
un'implementazione di atof() adatta per i programmi "giocattolo" e un'altra
implementazione per i programmi "seri". E la stessa cosa deve valere per
rand().
Non so di preciso cosa intendi dire con "non puoi comunque prevederne il
comportamento", se significa che non puoi prevedere quali numeri usciranno,
non sono d'accordo, perché qualunque generatore non crittografico è
prevedibile conoscendo un sufficiente numero di bit generati fino ad un
certo momento.
Cristiano

 il link. una cosa: la conversione a int e' richiesta dal C99.
Altro buon motivo per non usare rand()!
Una curiosità: avevo chiesto se fosse possibile postare il valore di
RAND_MAX ma non ho avuto riscontro. Puoi postarlo?
Cristiano

 RAND_MAX ma non ho avuto riscontro. Puoi postarlo?
e' nel codice. guardalo. o non sai farlo?

 e' nel codice. guardalo. o non sai farlo?
Stai ancora dicendo idiozie: nel codice del link RAND_MAX non appare! O non
sai leggere?
Cristiano

 O non sai leggere?
va bene, ho capito, te lo spiego,
di default, rand inizializza a 128 valori long la tabella, ma se vui, 
puoi arrivare a 256, come si legge subito sotto gli include.
" By default, the package runs with 128 bytes of state information" 
mi sembra piu' che adeguato per applicazioni anche diverse dal 
compitino di gettare un dado casualmente. piu' sotto, subito prima 
della funzione __random(), leggiamo 
" Returns a 31-bit random number" . cioe' 
2147483647
. se ne vuoi una 
conferma, basta guardare limits.h
se poi seguissi l'albero del cvs fino a random_r.c, vedresti che scarta 
anche il bit meno casuale eseguendo uno shift a destra.
attendo con ansia un giudizio ponderato e motivato, seriamente, anche 
con calcoli e formule, perche' secondo te sarebbe cosi' "prevedibile"
ti riporto stralcio della funzione di init, prevenendo la tua replica 
"usera' valori predefiniti arbitrari"
  "initializes state[] based on the given "seed" via a linear
   congruential generator.  Then, the pointers are set to known 
   locations that are exactly rand_sep places apart. Lastly, it
   cycles the state information a given number of times to get rid of 
   any initial dependencies introduced by the L.C.R.N.G. "
vado un po' OT: se tu usassi nmap, un portscanner opensource che tra le 
mille opzioni e' in grado abche di rilevare anche che tipo di 
generatore casuale viene usato per gli ID dei pacchetti, sapresti che 
la rand() della glibc e' molto buona.
tutto il codice delle funzioni che ho nominato lo trovi qui
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/stdlib/?cvsroot=glibc
 
se ancora non sei convinto che sia adeguata, e che io sono un idiota, 
non so che dirti...

non so che dirti...
Mai discutere animatamente con un imbecille... la gente potrebbe
non comprendere la differenza.
Io ho lasciato perdere il povero Cristiano molto tempo fa...
credo che da piccolo abbia avuto qualche trauma grave collegato
alla funzione rand() ... boh ... ora secondo me il poveretto e'
solo buono come terreno di studio per gli psichiatri (sono
ricapitato per caso in questo thread leggendo quanto diceva
Mauro Casini -- che personalmente trovo molto piu' interessante).
E comunque non e' che siano cosi' tante le applicazioni che hanno
bisogno di tutta questa pseudo casualita'... (anche se questo
fara' inorridire Cristiano sino all'orticaria).
Andrea
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff

 non comprendere la differenza.
Lo so che tu hai questa paura, ma non preoccuparti la figura dell'imbecille
l'hai già fatta alcuni mesi fa scrivendo tutto quel mare di sproloqui.
E con quest'altro messaggio non fai che peggiorare la tua situazione!
Cristiano

 non so che dirti...
Certo che non sono convinto dell'adeguatezza!
Prima mi hai chiesto un "giudizio ponderato e motivato, seriamente", ora te
lo chiedo io: se invece di usare tutto quell'intreccio di roba del link,
usassi, per esempio, questo generatore (ULONG è unsigned long):
[file: 
tausme2.ps
 di Pierre L'Ecuyer]
// Maximally-Equidistribuited Collision-Free combined LFSR
ULONG lfsr113(void) // Periodo ~2^113 ~10^34
{
 static ULONG z1,z2,z3,z4,INI=1; ULONG b;
 if(INI) {
  INI=0;
  do z1=QVC(); while(z1<2);
  do z2=QVC(); while(z2<8);
  do z3=QVC(); while(z3<16);
  do z4=QVC(); while(z4<128);
 }
 b=((z1<< 6)^z1) >> 13; z1=((z1 & 4294967294) << 18) ^ b;
 b=((z2<< 2)^z2) >> 27; z2=((z2 & 4294967288) <<  2) ^ b;
 b=((z3<<13)^z3) >> 21; z3=((z3 & 4294967280) <<  7) ^ b;
 b=((z4<< 3)^z4) >> 12; z4=((z4 & 4294967168) << 13) ^ b;
 return z1^z2^z3^z4;
}
ritieni che sia troppo dispendioso? Troppo lento? Troppo complicato da
includere nei tuoi programmi? O cos'altro?
Io trovo che ha un codice estremamente compatto, è veloce (certo, non quanto
un orribile lcg!), genera numeri da 32 bit senza bit "poco casuali", ha un
periodo enormemente superiore al "tuo" fsr e passa qualunque test
statistico.
QVC() è un generatore d'entropia che mi sono inventato, ma lo puoi
sostituire con un timer, con la posizione del mouse o con quello che vuoi
(sotto unix avete anche un generatore d'entropia incorporato!). Avresti a
disposizione uno spazio d'inizializzazione di quasi 128 bit (i valori non
ammessi vengono scartati automaticamente dal generatore, contrariamente
all'fsr che abbiamo visto prima).
Cristiano

 usare un semplice lcg senza alcuna "correzione" è un errore!
le correzioni ci sono. ma mi sono stancato di ripeterlo. e' ovvio che 
sei esperto di matematica, ma non di programmazione in C, e prendi 
posizione per partito preso. 
ti saluto, e ti do' in pasto al mio applyfilters.

 ti saluto, e ti do' in pasto al mio applyfilters.
Questa è una sicura evidenza che ti rifiuti di pensare che stai usando una
pessima rand() e che hai un atteggiamento prevenuto verso chi offende la tua
amata.
Davvero un atteggiamento infantile!
Cristiano

 statistiche.
Ma questa non e' sostanzialmente una contraddizione? Un generatore di
numeri realmente casuali generera' una sequenza statisticamente
disastrosa con probabilita' legata al rapporto tra il numero di sequenze
"disastrose" ed il numero di sequenze possibili.
Ciao,
Nicola

 Mi si perdoni l'intromissione:
Perché ti dobbiamo perdonare? Stiamo parlando in pubblico proprio perché
chiunque può intervenire e dire la sua.

Normalmente, prendere direttamente l'uscita di un generatore di numeri
(realmente) casuali è rischioso perché di solito hanno i bit "casuali"
mischiati a quelli dovuti ad eventi deterministici (non sempre!).
Con opportune tecniche (metodo di Von Neumann, FFT ed altro) è possibile
filtrare i bit in modo da ottenere un ottimo generatore di bit casuali. Nei
generatori commerciali i filtri sono, ovviamente, implementati in hardware.
Cristiano

 generatori commerciali i filtri sono, ovviamente, implementati in hardware.
Non intendevo discutere l'esistenza di tecniche simili, quanto
evidenziare la contraddizione concettuale di attendersi un comportamento
statistico molto ben definito da parte di una sequenza di eventi
casuali. Provo a fare un esempio:
Supponiamo di estrarre 100 interi compresi tra 0 e 9 da una sorgente
effettivamente casuale e da un generatore di buona qualita', entrambi
con distribuzione uniforme; se il primo numero estratto dalla sorgente
casuale e' 7, la probabilita' di avere una sequenza sbilanciata a favore
del sette e' di poco piu' elevata di quella di avere una sequenza
uniforme. Se il 7 e' il primo estratto dal generatore, ci aspettiamo
comunque una sequenza uniforme.
Il problema sta in realta' nell'uso fuorviante del termine "casuale" per
descrivere le proprieta' di un generatore, che se non combinato con un
meccanismo  di campionamento, genera una sequenza assolutamente
deterministica.
Ciao,
Nicola

 deterministica.
Come fa un TRNG a generare numeri assolutamente deterministici? Se lo fa
significa che è un PRNG hardware (anziché software)!
Proprio nel messaggio relativo al tuo follow-up, accennavo ad un TRNG
radioattivo che stiamo studiando e testando insieme ad un ricercatore
americano basato sul numero di decadimenti delle particelle alfa che
avvengono in un intervallo di tempo fisso.
Otteniamo numeri a 16 bit che hanno una distribuzione a campana (la mitica
curva di Gauss) e la frequenza di taglio è 5 kHz (questo dovrebbe essere "il
meccanismo di campionamento" a cui ti riferisci). Restando al di sotto del
limite di Nyquist (che dovrebbe essere 10 kHz) è possibile filtrare i numeri
ed ottenere una sequenza casuale di bit con ottime proprietà statistiche
(passa qualunque test). Il filtro usato è un semplice integratore.
L'esempio che ho fatto è coerente con quello che dici oppure ho capito
fischi per fiaschi? :-)
Cristiano

 fischi per fiaschi? :-)
Credo che semplicemente non ci intendiamo coi termini. Quello che
intendo dire e' che qualsiasi generatore di numeri pseudocasuali che sia
puramente algoritmico genera una sequenza perfettamente deterministica,
dipendente dal seme con cui il generatore e' inizializzato. L'importante
e' che "sembri" casuale, non solo, ma che lo sembri sempre. Al contrario
una sorgente di numeri veramente causali puo' sempre generare per caso
una sequenza statisticamente pessima.
Hai mai visto il film "Rosencranz e Guilderstern sono morti"? Nella
sequenza iniziale uno dei protagonisti gioca a testa o croce per passare
il tempo e per qualche minuto gli esce sempre testa...
Ciao,
Nicola

 il tempo e per qualche minuto gli esce sempre testa...
No, non l'ho visto; ma quei due tizi devono essere morti perché qualcuno li
ha beccati con una moneta truccata! :-))
Ciao
Cristiano

 solo la parte "casuale" usando opportune tecniche.
umm, ci vedo una contraddizione... la vera casualita' consente anche 
10.000.000 di uscite identiche, purche' mediamente 1 volta su 
2^10.000.000. perche' "filtrarlo via"?

 2^10.000.000. perche' "filtrarlo via"?
Perche' agli effetti pratici si usano sequenze di numeri casuali
leggermente piu' corte di 2^10.000.000, che potrebbero avere proprieta'
statistiche non accettabili. Il punto fondamentale delle tecniche di
generazione di numeri casuali e' forzare la legge dei grandi numeri in
modo che valga anche per numeri meno grandi.
Se la mia slot machine elettronica emette jackpot in sequenze di
10.000.000 per volta i miei clienti di Las Vegas mi seppelliscono vivo
nel deserto del Nevada...
Ciao,
Nicola

 nel deserto del Nevada...
parlando in senso lato: se lo facesse sempre, tenderei ad essere 
d'accordo. ma se non lo facesse mai, sarebbe truffa... 
cioe': se il generatore e' fallato, sono d'accordo, ma perche' 
castrarlo del tutto, se funziona abbastanza bene? basta migliorarlo, o 
no?

"uffa" ha scritto:

Oltre alla risposta di Nicola, vorrei aggiungere che quando si parla di
filtrare un trng s'intende filtrare i bit che vengono a mano a mano generati
non filtrare una sequenza dopo che abbiamo visto che ha qualcosa di strano.
Inoltre, per essere considerato valido, un rng deve generare sequenze
identiche intervallate da un preciso numero di altre sequenze diverse, la
casualità fa sì che tale "preciso numero" non venga rispettato *esattamente*
dal generatore, ma *deve* essere rispettato entro limiti stabiliti
matematicamente.
Nella pratica questo comportamento può essere controllato usando il "runs
test" del FIPS140-2 (oltre che con altri).
Cristiano

il tempo e per qualche minuto gli esce sempre testa...
Ciao...
Come suggerimento gratuito e non richiesto ti sconsiglio
di cercare nella direzione del ragionamento logico con
Cristiano. In passato ho avuto discussioni su questo
(che ritengo terribilmente noioso) argomento di rnd rng
rand random RND_32 e il mersenne twister etc. etc. e ho
il fortissimo sospetto che la testa di Cristiano sia
semplicemente piena di un cumulo enorme di dettagli, non
incasellati in un disegno logico portante.
Giusto per farti un esempio lui "conosceva" il problema
della poca affidabilita' della riduzione a modulo con
numeri piccoli e alcuni generatori random ma senza
averne pero' assolutamente afferrato il significato.
Nemmeno di fronte alla forma "essenziale" quale il voler
estrarre un numero casuale fra 0 e 9 avendo a disposizione
un generatore per definizione "buono" fra 0 e 10 e' stato
in grado di capire che stava dicendo un cumulo di
sciocchezze (chi e' interessato puo' rileggersi il thread
http://groups.google.com/groups?selm=39f2a6c6.1835593%40news.interbusiness.it
)
Per farla breve non puoi "discutere" con chi non e' dotato
dei meccanismi di base necessari per una discussione;
"ragionare" con chi e' solo in grado di accedere ad un
cumulo di nozioni mandate a memoria e che, suppongo per
principio e non per limiti cerebrali, rifiuta a priori
qualunque tipo di contestazione (inclusa la semplice
richiesta di dimostrare le sue affermazioni).
HTH


modo che valga anche per numeri meno grandi.
hehehe...
mi sembra di rileggere un articolo letto una quindicina di
anni fa su una rivista italiana (non ricordo quale) in cui
veniva presentato un simulatore di lotto piu' "corretto" della
semplice estrazione casuale e che di conseguenza dava una
maggior probabilita' di uscita ai "ritardatari" (questo per
renderlo piu' simile al mondo reale, a detta dell'autore).
Roba che dovrebbe far ridere, se non fosse per il fatto che
il tizio parlava seriamente e che la rivista non ha pubblicato
quell'articolo fra le vignette umoristiche.


 [idiozie varie]
E' già il secondo messaggio che posti per tentare di discreditarmi
(evidentemente senza riuscirci). Tutta l'importanza che mi dai mi porta a
pensare che tu abbia dei complessi d'inferiorità nei miei confronti!
E' anche logico che qualche "programmer" senza scrupoli abbia tutto
l'interesse a far passare da scemo chi dice male di una funzione di libreria
anche di fronte ad ampie motivazioni che solo chi ha interessi economici
finge di non capire.
Capisco che ti roda molto essere passato, alcuni mesi fa, da cerebroleso da
competizione, abbiamo capito che sei uno stupido lamer inconcludente, ma
evita di mettere il becco da tutte le parti dicendo soltanto idiozie!
Perdi la tua risibile credibilità giorno dopo giorno.
Far passare gli altri da deficienti non fa sembrare te più intelligente!
Anzi...
Tu stesso dici che non t'interessa parlare dei numeri casuali; restane
fuori! Non sei d'aiuto a nessuno e disturbi il normale svolgimento pacifico
e costruttivo delle discussioni! Hai fatto tre interventi, uno più
insignificante dell'altro.
Hai anche riportato il link relativo alla discussione in cui hai dato il
"meglio di te"! Ti sei dato il colpo di grazia!
Ma anche queste forme di vita hanno il diritto di dire la loro, per cui
vorrei spendere due parole sulla riduzione per il modulo che ha lasciato una
cicatrice nel tuo delicato cervello. Nel link che hai riportato dici:
"I problemi di utilizzare rand()%MAX sono solo legati a cattivi generatori
rand(); non alla riduzione modulo."
dopo tutta quella discussione e dopo avertelo anche detto, non hai ancora
capito che è il contrario di quello che dici; anche con un ottimo generatore
come MT19937 (che è un TGFSR) se devi ottenere un numero da 0 a 255 è
*molto* meglio se fai MT19937()>>24 piuttosto che MT19937()%256, infatti,
leggendo la documentazione, si nota che i bit meno significativi hanno una
distribuzione peggiore rispetto a quelli più significativi, ma non per
questo MT19937 è un cattivo generatore, tutt'altro!
Ciao buffoncello
Cristiano

 sciocchezze (chi e' interessato puo' rileggersi il thread
era mica quello della teoria dei cassetti? Cavolo, me lo ricordo ancora :-)


 era mica quello della teoria dei cassetti? Cavolo, me lo ricordo ancora
:-)
Sě, sě. Eravamo lě, io e il programmer, a tentare di far entrare i numeri
mozzi dentro ai suoi cassetti; io con la riduzione per il modulo e lui
direttamente menomando i poveri numeri togliendogli i bit piů significativi.
Ma niente... quei maledetti numeri non volevano entrare nei cassetti del
programmer!
Che sudata! :-)
Ciao
Cristiano

era mica quello della teoria dei cassetti? Cavolo, me lo ricordo ancora :-)
Non sottovalutare la potenza del "principio dei cassetti" :)
specie se conti di andare all'universita' e di studiare Algebra
e' qualcosa che risulta essere veramente illuminante nella
teoria dei gruppi finiti e delle tecnice di conteggio in genere.
I problemi che ha Cristiano non sono secondo me sulla carenza di
informazioni o di nozioni base (come il principio dei cassetti);
quello in cui secondo me deficita sono la capacita' di una
ragionevole autocritica e problemi nei meccanismi logici di base
(non credo per limiti mentali, ma per atteggiamento).
Di nozioni credo che nella testa di Cristiano che ne siano
anche troppe (tutte alla rinfusa e non capite quando non errate
in quanto erroneamente lette). Che tristezza vedere tanti
innocenti neuroni consolidati in conformazioni inutili!


Cristiano
Questo e' l'ultimo messaggio a cui rispondero' in questo
newsgroup su questo argomento. Io (al momento) non ho nessuno
nel killfile ma non sentirti offeso se non dovessi rispondere
a tue eventuali repliche...
Se hai bisogno di delucidazioni sulla matematica elementare
necessaria per comprendere quanto affermo ritieniti libero
di disturbarmi via email... come anche se tu dovessi trovare
argomentazioni valide che invece sostengano la tua tesi.
it.comp.lang.c++ non e' comunque il luogo giusto per
discussioni di questo tipo e non intendo alimentare oltre
questa sterile discussione.
Nonostante, come ho gia' detto, i generatori casuali non mi
interessino particolarmente (li uso spesso in applicazioni
reali principalmente nei problemi di ottimizzazione globale
come TSP o packing ma non ho mai sofferto dei limiti della
"devastante" rand()) sarei comunque grato a chiunque mi
smentisse su quanto ho affermato sulla riduzione modulo
(sempre meglio privatamente per non aumentare la gia'
cospicua banda OT di questo newsgroup).


 questa sterile discussione.
Ottima idea!
Addio
Cristiano

 Anzi...
ma non e' quello che hai appena fatto tu con Andrea ;-)
Ciao Anto


 teoria dei gruppi finiti e delle tecnice di conteggio in genere.
forse hai capito male il tono della mia frase. Non sottovaluto il 
"principio dei cassetti", anzi! Se mi ricordo ancora quel post e' perche' 
mi era piaciuto molto e perche' lo avevo trovato molto convincente.
Ciao Anto


 ma non e' quello che hai appena fatto tu con Andrea ;-)
No. Ricordati che in Italia chi spara per primo è colpevole (almeno) di
omicidio colposo, chi spara per secondo lo fa per legittima difesa.
Il grave errore fatto da "er cassetta" è stato proprio quello di uscirsene
all'improvviso dandomi dell'imbecille *senza alcun motivo* per un intero
messaggio facendo aumentare a dismisura il volume di questo thread che
sarebbe altrimenti finito già da un pezzo. Se non è un lamer frustrato
lui...
Beh, Antò, che vuoi che di dica... un pochetto mi hai deluso col tuo
messaggio... Mah! Andiamo a cenare che è meglio! :-))
Ciao
Cristiano

 omicidio colposo, chi spara per secondo lo fa per legittima difesa.
Invece su Usenet chi raccoglie provocazioni, vere o presunte, e'
colpevole tanto quanto chi le esprime. Piantala (Al Griffini l'ho gia'
detto in privato).
Ciao,
Nicola

detto in privato).
Ouch...
questa fa male. Dovro' meditare seriamente sul da farsi.


 rand().
Un'altra bischerata. Chi usa rand() sa quali sono le caratteristiche (e chi
non
le sa non ha studiato abbastanza). Nessuno generatore di numeri casuali che
sta sulla terra puo avere le caratteristiche di rumore "Bianco" e come se tu
volessi fare un filtro perfetto (quello rappresentato nel dominio delle
frequenze
con un rettangolo per intenderci). Quindi se esistesse la versione N di
rand()
con N grande a piacere troverei sempre l'applicazione X per cui la versione
N
di rand non mi soddisfa.
E poi basta co sta cazzata di rand e rand. Non ho mai visto nessuno litigare
come
voi su un concetto matematico. Voglio dire 2 +2 = 4 e basta.
Ogni rand ha delle caratteristiche statistiche che sono rigorosamente
matematiche,
a questo punto sparate dei numeri e dimostrate quello che dite a parole,
non ho a portata di mano nessun Matlab o Matematica .... fate voi.
-- 
Posted from [194.214.173.28] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 [...]
Abbiamo visto che questo tipo di uscite portano solo ad innescare flame;
perché continuate a venirvene fuori in questo modo?
Se io ho detto una cosa che tu non condividi non c'è bisogno che tu mi dia
del falso, è sufficiente che tu dica la tua, molto pacatamente come faccio
io e soprattutto *senza offendere*.
Nicola Musatti dice che "chi raccoglie provocazioni, vere o presunte, e'
colpevole tanto quanto chi le esprime". Ma in questo ng sembra che chi le
raccoglie per difendersi da un'ingiuria sia molto più colpevole di chi ha
ingiuriato.
Non volendo passare per "innesca flame" (visto che la mia indole e i miei
interessi sono di tutt'altra natura) eviterò accuratamente di rispondere a
questo tipo di messaggi.
Cristiano

 io e soprattutto *senza offendere*.
Vedi che sei "sul chi va la"?
Se ti dico "hai la puzza sotto il naso" ti senti offesso? Magari
prima chiedi cosa voglia dire, mi sembri quel vigile urbano
incazzato perche' qualcuno gli aveva dato del "pedante"!
Io ti ho detto solo che con quella frase hai sostenuto il falso.
Che mi sembra diverso dire: "Sei falso" che nota bene non ho mai
detto.
Dimenticavo, non ho ancora visto nessun numero da nessuna parte.
Mi sembra che tu o l'altro vogliate uscire vincitori, allora invece
che discutere sul sesso degli angeli tirate fuori un'analisi seria di
quello che state dicendo. O parlate entrambi per "sentito dire"?
E poi accetta le critiche (solo quelle negative ti fanno crescere).
----
Gaetano.


Bastaaaaaa!!!!
Ciao,
Nicola

Ottima idea!
Purtroppo, dopo lunga e sofferta riflessione, sono giunto
alla conclusione che non e' giusto permetterti di dire
qualunque nel newsgroup senza controbattere solo perche'
tu di fronte ad una contestazione degli argomenti rispondi
con flame personali.
Anche sul C++ hai per esempio dato consiglio inutili
nello specifico (usare ofstream, binary e roba simile)
e terrificanti nella filosofia ("prova questo", "prova
quello", "aspetta... magari prova cosi' che forse forse
funziona").
Programmare per tentativi e' secondo me errato in
generale... ma con il C++ sono convinto che e' proprio
un suicidio. E' un linguaggio troppo complesso e
tagliente per apprenderlo a tentoni.
Onestamente mi sconvolge il silenzio nel cui sono
cadute le cose che hai detto... e io ho provato a non
intervenire per evitare che sembrasse un accanimento
nei tuoi confronti. Credo che pero' sia piu' giusto
cercare di aiutare chi sia avvicina al C++.
Se questo vuol dire avvisare tutti quelli che potro'
di non dare retta a quanto dici tu... pazienza...
lo faro' anche se questo essere implicato in litigate
con un imbecille mi fara' sicuramente sembrare imbecille:
mi conforta sapere che forse qualcuno si prendera'
la briga di entrare nel merito.
Io non so cosa ti spinga a tutti i costi a voler
scrivere qualcosa su argomenti che, sono sicuro, nel
profondo e forse non ad un livello conscio ti sono
ostici e ti appaiono confusi; non credo che pero' sia
giusto che dei *tuoi* problemi risultino *altre* le
vittime innocenti.
Mi spiace solo che nel newsgroup non la si pensi cosi'
e si tenda a fare di tutta l'erba un fascio. Io credo
che comincerei a ignorare i tuoi post solo se credessi
che sei un professionista del trolling (ma comunque
affiggerei troll alert a beneficio di chi non ti conosce).
