Newsgroup: it.hobby.enigmi
Titolo: Programma lotto di Robby

Ringrazio per il programmino che simula il lotto:
http://xoomer.virgilio.it/tmorassi/ex/lotto.zip
Ho provato il programma ed esaminato il file prove.txt
che è allegato e rappresenta una serie di 5 prove fatte
da Robby.
Per rendere meno disagevole l'analisi dei risultati
ottenuti a seguito delle estrazioni, sarebbe utile, oltre
a salvare i numeri estratti, poter registrare nel file
creato (e non solo sul display) anche la frequenza di
sorteggio di ogni numero (o, meglio, quali numeri sono
usciti 0-1-2-3.... volte).
Accetto di espormi ad una probabile figuraccia e riporto
le informazioni che ho tratto da un esame sommario delle
5 prove fatte da Robby (file prove). Ogni prova consiste
in 100 estrazioni di 5 numeri per volta e l'incognita è
rappresentata dalla quantità di numeri di partenza (che,
a discrezione di Robby, potrebbero essere 90 o 89).
E' possibile scoprire, guardando le estrazioni, se nell'urna
ci sono 90 numeri o ne manca uno?
A) Le serie n.1 e n. 3 sono assolutamente normali, partono da
   tutti i 90 numeri, nessuno escluso (e tutti sorteggiati
   entro le 100 estrazioni, com'è probabile per il 75%).
B) Le serie n. 2 - 4 - 5 hanno presentato ciascuna un numero
   che è rimasto assente dopo le 100 estrazioni. La probabilità
   che tutte e tre partono da 89 numeri è  del 42% circa;
   quella che invece si è sempre partiti da 90 numeri è molto
   minore (poco più dell'1%). Anche se questa affermazione è
   debole e avrebbe bisogno di ulteriori conferme, sono portato
   a pensare che due delle tre serie partono da 89 numeri e
   una da 90. Potrei ovviamente sbagliarmi, ma tre numeri con
   una sola presenza mi fanno dire che alla serie n. 5 era stato
   tolto in partenza il  7.  Nulla di significativo (forse
   aiuterebbero ulteriori esami sulle distribuzioni) per la serie
   n. 2 (potrebbe essere stato tolto il 56) e la n. 4 (in cui
   potrebbe mancare l'85).
Aspetto di essere sbertucciato ;-)
Ciao, Nino 


Ma figurati... sei stato bravissimo ! <:-P
Aggiungo che ho fatto anche un programmino che simula il lancio della
moneta (testa/croce), piu' che altro per vedere (per la soddisfazione
di Fulvio...) a quanto potevano arrivare le serie di "teste" o "croci"
consecutive. Con qualche milione di "lanci" si arriva quasi sempre a
25 serie, ma stranamente pare che non si vada oltre quel valore
neanche aumentando di parecchio il numero di lanci (fino a 30
milioni). Puo' darsi che anche questo sia un artefatto dipendente
dall'algoritmo random, faro' ulteriori prove.
Robby
-
-------------------------------------------------------------
Per risposte private, togliere TUTTE le "x" dal mio address !
For private replies, remove ALL the "x" from my address !
-------------------------------------------------------------


Nel NG di matematica mi ero permesso di contestare l'affermazione che
si sia verificata in un casino' la ripetizione di 64 volte il Rosso
(non credo sia possibile in un arco di tempo realistico, non credo
all'infinito che non si può dimostrare). E avevo prospettato come
eventuale spiegazione, la presenza di "soglie" (molto comuni in altri
settori, es. nel campo delle basse dosi) sotto cui la probabilità,
pur non essendo zero, in pratica azzera la frequenza.
Apriti cielo...
Ma nessuno che abbia accettato di esaminare simulazioni, che so, relative
ad un miliardo di prove.
Ciao, sono interessato alle prove con un altro algoritmo random.
Nino 


Questo e' il vero problema. In realta' nessun algoritmo da PC puo'
generare numeri realmente casuali (dice Von Neumann: chi crede di
usare l'aritmetica per generare veri numeri casuali, e' in peccato
mortale). L'algoritmo e' ripetitivo, una volta inizializzato con un
"seme" scelto a caso (dal timer di sistema), genera ciascun numero
usando come "seme" il numero precedente e applicando certe funzioni.
Fatalmente dovranno saltar fuori delle regolarita'. Per esempio,
simulando svariate decine di milioni di lanci testa/croce, vengono
fuori alcune sequenze da 23, alcune da 25 (MAI di piu') e nessuna da
24. Per me questo e' un baco dell'algoritmo.
Gli unici numeri veramente casuali si possono generare attraverso
fenomeni naturali quali il decadimento radioattivo, fluttuazioni nella
pressione atmosferica, rumore di fondo elettrico ecc. C'e' un sito
(
www.random.org
) che mette a disposizione dei file di 1 o 10 mega
formati da byte casuali generati in quel modo, sto provando a
utilizzarli per "randomizzare" maggiormente il programmino del
testa/croce, e quello del Lotto. Ti faro' sapere.


 Robby
Ti ringrazio e ci conto anche all'implementazione della stampa del
ritardo massimo riscontrato nella serie.
Ciao, Nino 

 puramente casuali?
Ciao Nino,
Mi sono tenuto fuori da questo thread ', perche' per esperienze 
precedenti, so che genera interminabili discussioni, dove alla fine 
ciascuno resta poi della propria opinione.
Sono un callito antiritardista.
Segnalo percio' questo sito dove e' possibile interrogare 100milioni di 
decimali del Pi (che sono ritenute assolutamente casuali). Il sito da' 
anche le probabilita' di trovare sequenze lunghe n:
1-5	100%
6	Nearly 100%
7	99.995%
8	63%
9	9.5%
10	0.995%%
11	0.09995%
Cosi' ciascuno puo' fare le proprie prove e vedere chiaramente che 
sequenze "impressionanti" tipo cifre tutte uguali, consecutive ecc...
hanno lo STESSO andamento che sequenze scelte a caso. Come del resto ci 
si deve aspettare in linea teorica.

 Segnalo percio' questo sito ....
http://www.angio.net/pi/piquery

 deve aspettare in linea teorica.
Ti ringrazio, gli ho già dato un'occhiata. Nulla da dire sull'assoluta
casualità delle cifre decimali di pi greco (di cui ero già convinto).
Però, forse non ho visto bene, ma mi sembra che le probabilità di trovare
sequenze lunghe come da te indicato siano solo elencate (come risultato)
e non sia possibile fare prove personali (fra l'altro, devo fare i calcoli,
ma l'1% di probabilità per sequenze di 10 cifre non mi sembra molto...).
Inoltre, non ho trovato quello che mi interessava particolarmente, cioè
la distanza massima osservata su 100 milioni di decimali per una
determinata cifra (io mi aspetto circa 175).
Ciao, Nino 

 in linea con la statistica di Poisson.
Premettendo di non essere un ritardista, anzi di non giocare proprio al 
lotto, mi sono sempre posto il quesito se un modello poissoniano non fosse 
applicabile alle sortite nel tempo di un certo numero al lotto.
Un saluto
Gianni 


Questo purtroppo non si può fare. Sarebbe necessario un programma
ad hoc.
Io ho fatto un parziale tentativo a mano:
Assumiamo che le varie cifre seguano il comportamento analogo all'uscita
estrazionale di un processo casuale di 10 numeri sorteggiati in sequenza
(con reimbussolamento).
Ammessa equiprobabilità e casualità, si può allora applicare:
   Ni = No * exp(-k*R)
dove: k= costante pari a ln(10/9)=0,105361
      R= distanza o ritardo fra le varie cifre
Da essa si rileva che le 10 cifre diventano mediamente la metà dopo
6,5788 ritardi, che il ritardo normale (cioè la distanza media teorica
dopo cui rimane l'ultima cifra non uscita) è pari a 21,85 ritardi e che
il ritardo massimo atteso (Ni) con una massa (No) di 1.000 cifre
decimali è pari a circa R = 66 (l'equivalente per il lotto di circa
200 estrazioni).
Per curiosità, ho dato un'occhiata alle prime 2.000 cifre decimali,
ottenendo per le varie cifre i seguenti ritardi massimi reali:
     da 1 a 1.000 da 1.001 a 2.000        da 1 a 1.000 da 1.001 a 2.000
     ------------ ----------------        ------------ ----------------
(0)       48             61           (1)       46            43
(2)       28             39           (3)       33            51
(4)       78             60           (5)       39            44
(6)       54             48           (7)       64            52
(8)       42             49           (9)       50            41
Si può notare un ottimo accordo con il ritardo teorico 66, con
un'eccedenza solamente per la cifra 4 (il ritardo 78 in una massa di
1.000 cifre è tuttavia probabile per l'1,6% circa).
Se qualcuno ha voglia, può proseguire nell'analisi degli altri
milioni di decimali, nell'intento di scoprire eventuali anomalie
(che sinceramente non mi aspetto. Penso che aumentando il campo di
indagine a 100 milioni di decimali, il massimo ritardo per ogni
cifra 0...9 si possa aggirare nell'intorno di 175).
Ciao a tutti, Nino

 cifra 0...9 si possa aggirare nell'intorno di 175).
Scusa Nino, capisco Samaritani, però già nei primi 1000 hai trovato un
"disaccordo", che poi giustifichi in un'altra maniera.
Io temo che la sua formula, con n molto grande, sia destinata a fallire,
mentre mi pare che tu, sbilanciandoti così, credi forse il contrario.
Vuoi spiegarmi?
Ciao

 Ciao
Il "disaccordo" è stato riscontrato solo per una cifra, è relativo a
cose che solo azzardando si possono accostare alle estrazioni del lotto
(decimali di pi greco), a mio avviso non pare eccessivo (78 contro il
66 calcolato) e soprattutto è limitato ad un campo ristretto, per me
poco significativo (1000 cifre corrispondono a 100 cicli, cioè a
circa 1800 estrazioni del lotto).  La prova è quindi da prendere con
le pinze, e non è assolutamente sufficiente nè a confermare, nè a
smentire alcunchè.
Diverso sarebbe forse se qualcuno esaminasse 100 milioni di cifre e
venisse confermato un ritardo di circa 175. Magari anche con altri
riscontri su simulazioni al PC condotte su 10 milioni di estrazioni
e ritardi di circa 280; o di 1 miliardo di lanci di monete con
consecutività circa 30.
Questo per dirti che non ho certezze, mi sbaglierò, ma sono propenso
a credere che per n molto grandi, secondo me, la formula tiene
addirittura meglio, in quanto aumentando le prove, le fluttuazioni
assolute aumentano, ma relativamente la dispersione tende ad
attenuarsi, ed il "ritardo" calcolato dovrebbe crescere molto
lentamente, secondo ln(n)/ln(1/p).
Detto questo, comunque, come più volte ho sottolineato, penso che
questi risultati più che un "ritardo massimo" debbano più propriamente
intendersi come un ritardo medio da attendersi ragionevolmente con
elevata probabilità (su cui per me non è quindi sciocco scommettere),
in funzione della massa estrazionale analizzata.
Un caro saluto, Nino

>> cifra 0...9 si possa aggirare nell'intorno di 175).
Il campo di indagine si puo' estendere ben oltre. Il sito citato da
Dario contiene un link ad una Universita' giapponese che dovrebbe
mettere a disposizione dei files con i primi 400 milioni di decimali
del Pigreco. Dico "dovrebbe" perche' quel sito risulta inattivo, e le
copie conservate nel web-archive sono incomplete. Ma si possono
ugualmente scaricare quei files da qui:
http://highpi.4t.com/custom.htm
Sono 40 files da 10 milioni di cifre ciascuno. Una volta eliminati gli
spazi e i "return" di formattazione si hanno sequenze di cifre
ininterrotte, utili per la simulazione di eventi veramente casuali.
Provero' ad usarli nel mio programmino (vedi altro post).
Robby
PS Se a qualcuno interessano quei files, gia' "ripuliti", mi contatti.
Sono 400 mega che ho compresso in uno zip di 179 mega.


ritardo massimo riscontrato nella serie.
Prima devo risolvere il problema della randomizzazione, altrimenti
questa opzione e' inutile. Se per ora ti accontenti di sapere il
ritardo massimo di ciascuna delle 10 cifre nei 400 milioni di
decimali-pigreco posso fare un programmino ad hoc, non credo sia
difficile.



Ho copiato i primi 100.000 decimali di Pigreco a questo link:
http://www.geom.uiuc.edu/~huberty/math5337/groupe/digits.html
Bella l'idea di Dario Uri di usare PiGreco: è come avere una "sorgente
infinita di casualità".
Analizzarli con un programmino ad hoc è invitante, anche se con archivi di
grosse dimensioni non sarà uno scherzo.
Intanto io provo a scrivere qualcosa per i primi 100.000, e vedremo cosa
salta fuori (secondo la formula di Samaritani il max teorico è 110).
Ciao
Francesco

PSEUDO-random...
CACCHIO !!!!! Guarda cosa ho trovato su un Forum:
"Now given that the QBasic RND function repeats after 16,777,213 ...."
Ho verificato.... e' verissimo ! Se si fa partire l'algoritmo Random
con un qualunque "seme" e lo si invoca 16777213 volte di seguito, il
ciclo dei numeri casuali si ripete esattamente dall'inizio. Casuali un
tubo ! Per forza sballava... >:-(
Motivo di piu' per insistere col pigreco.



Ciao Robby,
io ho appena scritto a Nino che manipolare archivi così grandi non sarà cosa
facile... (;-)))
Ma in quanto tempo stimi di processare 400.000.000 di cifre?
Ciao,
Francesco

Ma in quanto tempo stimi di processare 400.000.000 di cifre?
Beh, qualche minuto ci vorra'... :-)
Sinceramente non ne ho idea. Qualche ora, penso. Sara' conveniente
processare i 40 files da 10000000 cifre ciascuno, uno dopo l'altro,
anziche' unirli in un solo grosso file da 400 milioni. Penso che in
tal modo potrebbero essere mantenuti in una memoria cache velocizzando
l'operazione: con un grosso file, si dovrebbe avere un piu' frequente
accesso al disco fisso, notoriamente piu' lento della RAM !
Domani ci provo. Ciao.


 salta fuori (secondo la formula di Samaritani il max teorico č 110).
Fatto,
ecco i massimi ritardi sulle prime 100.000 cifre di Pi calcolati da un mio
programmino:
1 --> 85
2 --> 83
3 --> 96
4 --> 93
5 --> 86
6 --> 81
7 --> 79
8 --> 81
9 --> 117
0 --> 90
Beh, i valori sono piuttosto omogenei, a parte quel 9 che alza la media (e
supera il max previsto).
Vedremo per valori piů alti di decimali.
Ciao

 Vedremo per valori più alti di decimali.
Questa volta ho scaricato un archivio zip dal seguente link:
http://www.geocities.com/thestarman3/math/pi/picalcs.htm
dove si può scegliere fino a 1.250.000 decimali di Pi.
Ho fatto un'analisi su 1.000.000 di cifre (tempo di elaborazione...
vergognoso: 54 min.)
Ecco i risultati:
1 --> 126
2 --> 128
3 --> 121
4 --> 156
5 --> 106
6 --> 102
7 --> 103
8 --> 104
9 --> 124
0 --> 113
Anche in questo caso i valori sono tutti al di sotto dell'atteso 131,
eccetto il 4, il quale ha toccato 156 attorno alle 350.000 cifre e non si è
più mosso (credo che tale valore rimarrà stabile per almeno altri 30 mln di
cifre).
Direi che è evidente però l'assenza di scompensi e anomalie.
Chiederei però a Nino un suo parere, e a quanto corrisponde questo 156 nel
lotto.
Ciao

 Vedremo per valori più alti di decimali.
Sei incontentabile...
Io sono soddisfatto, era più o meno quello che mi aspettavo...
Nino 

 Robby
Aspetto, grazie.
Ciao, Nino 

 -
Io in queste cose ci capisco poco piů di niente. E un po' mi rode...
Perň sono molto veloce, e, senza nč mangiare, nč dormire, a mano
potrei riuscirci in una decina d'anni. :-)
Ciao, Nino


Per fortuna, le estrazioni del lotto avvengono ancora a mano ;-)
Se no fra un 100.000 anni avresti potuto indovinare tutte
le estrazioni...  Altro che Einstein...
Nino 

 salta fuori (secondo la formula di Samaritani il max teorico è 110).
ln(100000)/ln(10/9)= 109,27
Resterai stupito dell'accordo...
Ciao, Nino


I miracoli non sono di questo mondo, però questi risultati dovrebbero
far meditare. Un milione di cifre sono tante, il disordine del caso non
avrebbe avuto difficoltà a far osservare, che so, una distanza di 1000.
Comunque, visto sotto un altro aspetto, il 156 del 4 è un po' anomalo,
fra l'altro è comparso addirittura intorno alle prime 350.000 cifre.
156 potrebbe essere considerato il ritardo medio corrispondente ad una
massa di 14 milioni di cifre.
Ammettendo (è una forzatura!) di poter trattare questi ritardi con la
statistica di Poisson, la probabilità di trovare 156 sarebbe dello 0,35%.
Se applichiamo lo stesso criterio alle estrazioni del lotto e consideriamo
pari al 131 teorico il ritardo attualmente osservato di 200 estrazioni,
il 156 sperimentale per dare una prob. dello 0,35% condurrebbe ad un
ritardo per il lotto pari a 229 estrazioni.
Aspettiamo i risultati su 400 milioni di cifre, che ovviamente
potrebbero anche smentire tutto.
Ciao, Nino 


Perfetto ! Se il mio programma non dovesse funzionare ti ripasso i
file, e ci pensi tu. A mano.


 vergognoso: 54 min.)
E ci credo!
Il "contatore" della cifra in analisi fa perdere un mucchio di tempo
macchina.
Inoltre ho alleggerito l'elaborazione dandogli da tritare delle
"bistecchine" da 10.000 cifre alla volta, anzichč tutta la stringa da 1 mln.
Come contatore ho usato il numero della bistecchina in analisi.
Risultato: 67 secondi!
Ciao

informatico (conosciuti i limiti degli algoritmi random).
Che io sappia, la questione della "normalita'" (cioe' dell'unifor-
mita' della distribuzione delle cifre decimali) e' la principale
questione aperta riguardante pigreco. Finche' qualcuno non dimostra
il contrario, si potrebbe anche pensare che "da un certo punto in
poi" le cifre decimali di pigreco possano smettere di somigliare ad
una distribuzione casuale!
Per questo motivo, e per non essere costretti a maneggiare file
molto grandi, io al posto di pigreco consiglierei di usare un
buon generatore di numeri pseudocasuali di cui siano note le
proprieta' statistiche.
Io nelle mie simulazioni random uso un generatore noto come
"Mersenne Twister" avente un periodo pari a  2^19937-1 (credo
sufficiente per tutti gli scopi pratici :-), un'uniformita' di
distribuzione in spazi multidimensionali fino a 632 dimensioni
(credo sufficiente per simulare le cinquine del lotto :-) e
avente una velocita' di generazione di numeri 4 volte superiore
alla rand()!!!
Se programmate in C o C++, potete usare il codice del Mersenne
Twister che trovate qui:
http://www-personal.engin.umich.edu/~wagnerr/MersenneTwister.html
o qui
http://www.bedaux.net/mtrand/
Detto questo, a mio avviso, per validare la strategia ritardista,
non dovreste guardare i ritardi massimi, ma piuttosto dovreste far
girare il programma fino a che non trova ritardi di entita'
prefissata, e verificare per almeno 10000 di quei casi se la
strategia ritardista da quei punti in poi e' premiante rispetto
alla strategia di puntata casuale.
E scoprirete di no... ;-)
Un saluto,
              Antonio

 E scoprirete di no... ;-)
Tornando alle tesi che definisci ritardiste e quindi dal tuo punto di
vista assurde.
Io non ho mai pensato, nè parlato di ritardi "massimi" stabiliti da Dio
ed insuperabili. Ad es., dicevo:
"Diverso sarebbe forse se qualcuno esaminasse 100 milioni di cifre e
venisse confermato un ritardo di circa 175. Magari anche con altri
riscontri su simulazioni al PC condotte su 10 milioni di estrazioni
e ritardi di circa 280; o di 1 miliardo di lanci di monete con
consecutività circa 30.
Questo per dirti che non ho certezze, mi sbaglierò, ma sono propenso
a credere che per n molto grandi, secondo me, la formula tiene
addirittura meglio, in quanto aumentando le prove, le fluttuazioni
assolute aumentano, ma relativamente la dispersione tende ad
attenuarsi, ed il "ritardo" calcolato dovrebbe crescere molto
lentamente, secondo ln(n)/ln(1/p).
Detto questo, comunque, come più volte ho sottolineato, penso che
questi risultati più che un "ritardo massimo" debbano più propriamente
intendersi come un ritardo medio da attendersi ragionevolmente con
elevata probabilità (su cui per me non è quindi sciocco scommettere),
in funzione della massa estrazionale analizzata."
Quindi, la strategia di gioco ritardista (come altri metodi, a mio
avviso altrettanto "non indifferenti" rispetto all'approccio casuale)
si deve basare sulla verifica o meno della sostanziale tenuta ed
attendibilità dei risultati ottenuti dalla relazione più volte riportata
(in funzione della massa estrazionale); bada bene, non è, come potresti
contestare, un controllo a posteriori, come nel caso delle estrazioni
del lotto. Se, come per il momento sembra, i dati sui ritardi delle
cifre di pigreco venissero confermati (per 400 milioni di decimali)
io, ripeto, appunto perchè non ragiono da matematico, credero'
all'utilità di scommettere sull'attendibità di non scostamento temporale
di un limite determinabile (quindi continuerò a ritenere assurdo il
convincimento di chi, guardando solo alla probabilità dell'evento
successivo, sostiene che un numero, anche limitandosi alla nostra
percezione di tempo reale, potrebbe non uscire mai).
Ciao, Nino

percezione di tempo reale, potrebbe non uscire mai).
Intanto, ringrazio Antonio per la segnalazione dell'algoritmo random
"Mersenne Twister" che, se pur ciclico, evita gli inconvenienti del
RND per simulazioni di un certo peso. Me lo studiero', per vedere se e
come si possa implementare nel modesto Quick Basic che uso io.
Poi, come promesso, vi fornisco i risultati dell'analisi dei primi 400
milioni di decimali del pigreco, riguardo ai "ritardi" delle singole
cifre e alla "ripetizione" della stessa cifra piu' volte consecutive.
Mi limito a riportare i dati senza entrare in altri tipi di
discussione, ognuno li interpreti come gli pare ;-)
RITMAX e' il massimo ritardo (distanza fra due occorrenze successive)
di ciascuna cifra, e RIT-POS la posizione in cui lo si trova per la
prima volta, cioe' dalla quale la cifra comincia a "ritardare".
Occorrenze successive dello stesso ritardo, anche se presenti, sono
state ignorate (se interessa, posso fare una piccola modifica per
registrare quante volte quel RITMAX si ripete). La media dei ritardi
e' 175, la cifra "primatista" e' l'8 con un ritardo di 196.
SEQMAX e' la massima sequenza riscontrata di ciascuna cifra, e SEQ-POS
e' la sua posizione. SEQMAX e' circa 8-9, con una punta record di 10
"6" consecutivi a partire dalla 386980412a posizione:
.....684034599643705666666666691436679246313.....
                    ^^^^^^^^^^         
La ricerca ha richiesto poco meno di due ore.
 Cifra         Ritmax        Rit-pos       Seqmax        Seq-pos
 
 0             165           391666652     8             172330850 
 1             179           329806827     8             159090113 
 2             156           122054043     8             175820910 
 3             174           319413568     8             36488176 
 4             160           390897843     8             22931745 
 5             172           67172342      8             168743355 
 6             194           380007622     10            386980412 
 7             164           163831820     9             24658601 
 8             196           18522937      9             46663520 
 9             190           362361794     8             36356642 
Cifre esaminate: 400000000 in 1 ore 51 minuti 15 secondi
Buone elucubrazioni !



Ciao iant,
Su questo hai ragione, perň č anche vero che le analisi finora fatte tendono
a dimostrare che siano casuali.
Ad esempio ho trovato la seguente pagina web:
http://www.super-computing.org/pi-decimal_current.html
dove, tra le varie indicazioni statistiche su 1200 miliardi di decimali di
Pi, viene riportata anche una tabella delle frequenze relative, e come
potrai notare la presenza di ciascuna cifra si attesta praticamente a 120
miliardi (con uno scarto dell'ordine del milione in piů o in meno), nel
pieno rispetto della LDGN.
Ciao


Innanzitutto, ti ringrazio per il lavorone (soprattutto perchč,
interpretando il tuo pensiero, probabilmente l'hai fatto solo
per farmi contento, e lo ritenevi  inutile).
Guarderň con calma i risultati, per il momento sono piů che
soddisfatto...
Infatti, poco sopra, dicevo:
"Diverso sarebbe forse se qualcuno esaminasse 100 milioni di cifre e
venisse confermato un ritardo di circa 175."
Ciao, Nino

per farmi contento, e lo ritenevi  inutile).
Qui ti sbagli. L'ho fatto perche' mi piace programmare, soprattutto le
cose intriganti ancorche' inutili. All'epoca del mio primo computer,
vent'anni fa (era un C64), l'ho quasi fuso programmando di tutto. Una
ventina me li hanno pure pubblicati... :-)
Domani metto anche i risultati con le ripetizioni dei massimi. Certo
che guardando il link indicato da Francesco, con i risultati della
ricerca su 1200 miliardi di decimali, questi programmini sono roba ben
misera... loro hanno ben altre macchine e mezzi ! <:-(
