Newsgroup: it.hobby.lotto
Titolo: SPECIFICHE (Proposta di formato standard per archivio estrazioni)

A questo post ci si puo' "attaccare" facendo il Re: per fare proposte
riguardo le SPECIFICHE per un formato standard degli archivi delle
estrazioni lotto.

Gli archivi lotto dovrebbero essere facilmente aggiornabili dagli
utenti e facilmente gestibili dai piu' comuni linguaggi di
programmazione, da cio' deriva:
VC01:scelta di un formato fisico del file:
secondo me va bene un file in formato testo in chiaro.
VC02: scelta del numero di file
si potrebbe scegliere un archivio unico con tutti gli anni e tutte le
ruote, oppure un archivio diviso per ruote (secondo me da scartare),
oppure un certo numero di file uno per anno (interessante, introduce
un concetto di modularita'). 
VC03: date di estrazione interne o esterne al file?
a occhio mi verrebbe di dire interne, ma la soluzine di un file a
parte per le date non e' per nulla stupida.
VC04: mettere per prima l'ultima estrazione o l'estrazione piu'
vecchia?
ci sono vantaggi e svantaggi, se l'ultima estrazione e' all'inizio edl
file l'utente puo' aggiornarlo manualmente in modo piu' semplice, di
contro i programmi che gestiscono le estrazioni saranno piu'
complicati (forse alcune ricerche diventerebbero ingestibili?). 
Victor

 complicati (forse alcune ricerche diventerebbero ingestibili?). 
Dipende da quanto bravo e' il programmatore... :-)
Se il file e' fatto bene e non contiene errori un buon programma
dovrebbe riuscire a leggere i dati e mettere automaticamente in ordine
le date, in qualsiasi ordine esse siano.
Se pero' le estrazioni sono gia' in ordine magari il caricamento dati
avviene piu' velocemente... anche se un buon algoritmo potrebbe lo
stesso caricare in modo sufficientemente veloce i dati supponendo che
non siano proprio scritti con un ordine casuale (ad esempio tentando
subito prima e subito dopo l'ultimo inserito senza cercare in memoria
la giusta posizione partendo dall'estrazione piu' recente o quella
piu' antica).
ciao
					Michele

 vecchia?
Dati in ordine casuale sarebbe meglio non averli!:))
Anche se non e' detto che non si possa pensare a programmi "robusti"
che riescano a gestirli.
Efettivamente leggere il file dal piu' vecchio al piu' recente
potrebbe avere vantaggi, credo sia la soluzione migliore.
Ciao, Michele!
Victor
 

Victor avuto una splendida idea e poi ha scritto:
V>  VC01:scelta di un formato fisico del file:
V>  secondo me va bene un file in formato testo in chiaro.
sicuramente un ottima scelta: il testo in chiaro è molto più potente e
flessibile di quello che si potrebbe pensare a prima vista.
Unix docet!
V>  VC02: scelta del numero di file
V>  si potrebbe scegliere un archivio unico con tutti gli anni e tutte le
V>  ruote, oppure un archivio diviso per ruote (secondo me da scartare),
V>  oppure un certo numero di file uno per anno (interessante, introduce
V>  un concetto di modularita'). 
un file unico per tutto lo storico. Eventuali indici e/o ottimizzazioni
dovrebbero essere specifici al programma. Infatti, oltre all'archivio, occorre
anche stabilire una rappresentazione in memoria delle estrazioni: da questa
dipendono pure le ottimizzazioni alla gestione file e definire tutto questo
diventerebbe troppo vincolante per i programmatori.
Anche se non scarterei la suddivisione per ruote.
V>  VC03: date di estrazione interne o esterne al file?
V>  a occhio mi verrebbe di dire interne, ma la soluzine di un file a
V>  parte per le date non e' per nulla stupida.
dipende. Se si usa un file unico terrei le date all'interno, ma se si usano
file separati per le ruote, si potrebbe tenere un ulteriore file con le
caratteristiche dell'estrazione: data, quali e quante ruote sono state
estratte (e quindi presenti per quella data), motivo per cui non si è avuta
l'estrazione, un indice di affidabilità sui numeri (se 30 archivi diversi
riportano gli stessi dati possiamo ritenerli affidabili, ma se ci sono
discrepanze come scegliere? sarebbe il caso di 'ricordarsi' che i numeri di
quella data potrebbero essere sacorretti).
V>  VC04: mettere per prima l'ultima estrazione o l'estrazione piu'
V>  vecchia?
- per ultima: aggiornamento da programma immediato, basta un append, mentre
l'umano deve fare un CTRL+END (o similare) per portarsi alla fine del file. 
- per prima: aggiornamento da programma più sicuro (si crea un nuovo file e si
appende quello vecchio), per l'umano basta cominciare a ascrivere.
Ciao
Marco
-- 
Se qualcosa puo' andar male, lo fara'. (Legge di Murphy)

Un bel di' Victor scrisse:
V> Gli archivi lotto dovrebbero essere facilmente aggiornabili dagli
V> utenti e facilmente gestibili dai piu' comuni linguaggi di
V> programmazione, da cio' deriva:
V> 
ottima idea!
V> VC01:scelta di un formato fisico del file:
V> secondo me va bene un file in formato testo in chiaro.
V> 
beh... sicuramente ottima, pero' si risparmierebbe un terzo dello spazio
utilizzando 1 byte per ogni numero (invece che 3: 2 per il numero ed uno
per l'eventuale spazio/tabulazione)
V> VC02: scelta del numero di file
V> si potrebbe scegliere un archivio unico con tutti gli anni e tutte le
V> ruote, oppure un archivio diviso per ruote (secondo me da scartare),
V> oppure un certo numero di file uno per anno (interessante, introduce
V> un concetto di modularita'). 
V> 
direi, vista anche l'altra risposta di rimanere sul decennio.
Attualmente avremmo 10 files.
Anche perche' programmi come Blocco Notes non gestiscono files troppo
grossi, e comunque muoversi all'interno di un file, piu' questo e'
piccolo, piu' e' comodo.
V> VC03: date di estrazione interne o esterne al file?
V> a occhio mi verrebbe di dire interne, ma la soluzine di un file a
V> parte per le date non e' per nulla stupida.
V> 
date direi interne, se vogliamo poter modificare a mano, esterne
(che secondo me e' meglio) "comprimiamo" il file (1 byte/numero), 
tanto gia' non e' leggibile... :-)
V> VC04: mettere per prima l'ultima estrazione o l'estrazione piu'
V> vecchia?
prima la piu' vecchia... senza dubbio: se gia' rimpiccioliamo il file
dividendo l'archivio in varie parti, la data in fondo va piu' che bene.
Fra l'altro gran parte degli editor di testo che ho visto (quelli in
Windows) permettono di raggiungere la fine del file con "Shift+PagDn"
o combinazioni di tasti simili.
Comunque io proporrei 2 formati: uno "da casa", facilmente leggibile, con
numeri scritti per esteso, uno spazio tra i numeri, date nel formato
gg/mm/aaaa, insomma:
01/01/1999
10 26 45 67 90
34 73 78 51 18
...
ed una versione "da asporto" compressa, nonche' zipparta... a meno che
il formato esteso non si comprima di piu' con lo zip... :-)
Ciao!
-- 
"6. Se un subordinato ti rivolge una domanda pertinente, guardalo come se
avesse perso il senno. Quando lui ha preso un'aria mortificata, fagli la
stessa domanda con altre parole", dal decalogo di Spark per il giovane manager
-- 
Emanuele Cesena
d.a.m...@iol.it
    occhio all'antispam NOSPAM!
http://www.geocities.com/SiliconValley/Grid/8879

 se una certa riga e' continuazione della successiva.
Secondo me rendi piu' complicato il programma... gia' deve controllare
se una riga e' corretta (ovvero contiene tutti i dati e nel formato
giusto), se poi deve estendere il controllo a piu' righe diventa lento
a caricarsi.
Comunque se non aggiungono a breve altre 4-5 ruote non c'e` problema
al limite dei 255 caratteri per riga.
ciao
					Michele

il formato esteso non si comprima di piu' con lo zip... :-)
..inizio a sentire un certo peso alla nuca..:))
cerchiamo di arrivare ad una prima  prima versione..:)
Ciao!
Victor


mi sto convincendo che e' meglio mettere le estrazioni in ordine
naturale, dalla piu' vecchia alla piu'recente.
Ciao
Victor

Un bel di' Marco Pozzato scrisse:
MP> un file unico per tutto lo storico. Eventuali indici e/o ottimizzazioni
MP> dovrebbero essere specifici al programma. Infatti, oltre all'archivio, occorre
MP> anche stabilire una rappresentazione in memoria delle estrazioni: da questa
MP> dipendono pure le ottimizzazioni alla gestione file e definire tutto questo
MP> diventerebbe troppo vincolante per i programmatori.
MP> Anche se non scarterei la suddivisione per ruote.
MP> 
secondo me no.
Il formato comunque deve servire soprattutto per lo scambio, e quindi essere
previsto nei programmi di lotto, pero' non e' assolutamente vincolante
per il programmatore.
Quindi visto che, per ora, gli scambi sono lenti, secondo me e' meglio
suddividere i files (ad es. per decenni).
MP> - per ultima: aggiornamento da programma immediato, basta un append, mentre
MP> l'umano deve fare un CTRL+END (o similare) per portarsi alla fine del file. 
MP> 
MP> - per prima: aggiornamento da programma più sicuro (si crea un nuovo file e si
MP> appende quello vecchio), per l'umano basta cominciare a ascrivere.
MP> 
perche' aggiornamento piu' sicuro?? :-)
-- 
"Gli esperti di calcio non fanno mai tredici", osservazione di Malipieri


 il formato esteso non si comprima di piu' con lo zip... :-)
Il formato "esteso" lo puoi comprimere a circa 1/3 dello spazio con
zip, e forse 1/3.5 con bzip2. 
Con due formati (di cui uno semi-binario) ti incasini la vita tra
convertitori e altro... 
Nessuno ha mai pensato di usare l'algoritmo di compressione di gzip o
bzip2 (entrambi software libero) per trovare i numeri da giocare al
lotto? :-)
ciao
					Michele

Victor
Tanti Saluti.
A. GALENO

Michele Dalla Silvestra ha scritto:
MDS>  Il vantaggio di questo e' che se si rovina uno dei file e' facile
MDS>  anche scaricarlo da rete o confrontarlo da un altro sistema (md5,
MDS>  crc..)
interessante il controllo.
allora anche io propenderei per la divisione in più file (quanto si era detto?
10 anni? o più?)
per ogni archivio si dà il CRC o equivalente....e una bella firmetta PGP del
manutentore principale, no?
poi per compattare il tutto un bel
# cat ar1 ar2 ar3 ar4 ar5 > arTot
vista così, oltre ai file di archivio si dovrebbero dare anche alcuni tool per
la verifica (sum o md5sum), e un minimo di manipolazione: si potrebbero usare
i vari tool GNU (grep e textutils) con qualche semplice script, giusto per
incominciare.
MDS>  Comunque se non aggiungono a breve altre 4-5 ruote non c'e` problema
MDS>  al limite dei 255 caratteri per riga.
da dove arriva il massimo dei 255 caratteri per riga?
Ciao
Marco
-- 
C'e' un sacco di gente che si comporta secondo le regole, pur non sapendo chi
le ha scritte, quando, perche' e nemmeno che regole sono. 
(Quinta legge di Loftus)

Ema da TIN ha scritto:
EdT>  beh... sicuramente ottima, pero' si risparmierebbe un terzo dello spazio
EdT>  utilizzando 1 byte per ogni numero (invece che 3: 2 per il numero ed uno
EdT>  per l'eventuale spazio/tabulazione)
a dirla tutta, basterebbero 6 bit e qualche cosa per un numero....ma credo che
l'occupazione di spazio non sia il nostro problema principale. Per quello ci
sono sempre i compressori che fanno miracoli :-)
EdT>  date direi interne, se vogliamo poter modificare a mano, esterne
EdT>  (che secondo me e' meglio) "comprimiamo" il file (1 byte/numero), 
EdT>  tanto gia' non e' leggibile... :-)
ok, date interne
EdT>  Comunque io proporrei 2 formati: uno "da casa", facilmente leggibile, con
EdT>  numeri scritti per esteso, uno spazio tra i numeri, date nel formato
EdT>  gg/mm/aaaa, insomma:
EdT>  
EdT>  01/01/1999
EdT>  10 26 45 67 90
EdT>  34 73 78 51 18
EdT>  ....
EdT>  
terrei un solo archivio in chiaro.
Ho un archivio dal 1871 fino a metà delo scorso anno circa per un totale di
6702 estrazioni. Ogni estrazione occupa 162 byte per un totale di 1085724
byte. 
Considerando la quantità di informazione, abbiamo che 26 bit sono sufficienti
a rappresentare una cinquina, quindi con 260 bit=32.5 byte possiamo codificare
tutti i 50 numeri di una estrazione. Mancano ancora le date: se contiamo le
date a partire dal 1871 almeno fino al 2500 abbiamo altri 18 bit=2.25 byte,
per un totale di 35 byte ad estrazione. 
Quindi la miglior codifica possibile che possiamo inventare occuperà almeno 35
byte per le 10 ruote e le date.
Rispetto alla codifica del mio archivio attuale si tratta di un risparmio di
162/35=4.6 volte
La semplice compressione con gzip riduce di un fattore 3 la dimensione, quindi
senza far troppa fatica si va molto vicini all'ottimo.
Certamente poi, per le elaborazioni in memoria si useranno altre codifiche dei
dati ben più efficienti, ma questo dipende dai programmatori.
Ciao
Marco
-- 
Una qualsiasi autorizzazione sarà concessa solo quando nessuno di coloro che
la concedono potrà essere incolpato in caso di fallimento, e tutti coloro che
la concedono potranno vantarsi in caso di successo. (Regola di Roger)

>Anche se non scarterei la suddivisione per ruote.
V>  uack, credo che decidere se file unico o no sara' arduo!
V>  
è presto fatto!
se usiamo un file unico e con le date interne, sarò sufficiente usare
separatori diversi tra numeri, ruote e date e il gioco è fatto all'istante.
ad esempio:
10 gen 1999: 5  6  7  8  9:50 60 70 80 90: .....
14 gen 1999: 1  2  3  4  5:10 20 30 40 50: ..... 
il primo campo separato da ':' è la data, il secondo è la ruota di bari, ecc...
per avere la ruota di cagliari (la seconda ruota, il terzo campo) è sufficiente
usare il comando cut (presente nel pacchetto GNU textutils) in questo modo:
c:>cut -d':' -f3 archivio.txt
e si otterrà
50 60 70 80 90
10 20 30 40 50
per avere la ruota di Cagliari con le date basterà prendere i campi 1 e 3:
c:>cut -d':' -f1,3
10 gen 1999:50 60 70 80 90
14 gen 1999:10 20 30 40 50 
semplice ed elegante, nel solito stile unix.
All'inizio può sembrare un po' difficile, ma con qualche programmino batch di
supporto si semplificherà tutto.
V>  molto interessante il fatto di associare un incice di affidabilita''
V>  per i casi noti di incogruenza tra gli archivi, ovviamente andrebbe
V>  codificato es. 1byte per ogni estrazione di 5 numeri con un 1 binario
V>  sul bit corrispondente all''estratto incerto.
ok, si può aggiungere un ulteriore campo (magari come ultimo campo) contenente
gli indici delle 10 ruote.
V>  mi sto convincendo che e' meglio mettere le estrazioni in ordine
V>  naturale, dalla piu' vecchia alla piu'recente.
ok
Ciao
Marco
-- 
(o-  | Unix is simple and coherent , but it takes a genius  to understand
//\  | and appreciate  its simplicity .
V_/_ |                                    Dennis Ritchie .

estrazioni lotto.
partecipo a questa discussione, dicendo soltanto il formato di dati che
ho utilizzato io.
Il Lottovelox II Pro per Windows 95/98 esporta le estrazioni
dell'archivio (alcune o anche tutte) nel seguente formato:
gg/mm/aaaa a1 a2 a3 a4 a5 b1 b2 b3 b4 b5 c1 c2 ... L1 L2 L3 L4 L5
cioè:
la data in formato esteso all'inizio e poi tutti e 50 i numeri (5 numeri
per 10 ruote) dopo usando 2 cifre per ogni numero.
Il separatore è per default lo spazio, ma si può scegliere quale
utilizzare.
Le estrazioni sono in ordine cronologico (dalla più vecchia alla più
nuova).
Un tale formato è facilmente importabile con un foglio elettronico!
Penso che il formato che ho utilizzato io è il più adatto, poi fate voi!
Ciao a tutti
--
Alessandro Pulvirenti
ale...@cedss.it

Un bel di' Michele Dalla Silvestra scrisse:
MDS> Il formato "esteso" lo puoi comprimere a circa 1/3 dello spazio con
MDS> zip, e forse 1/3.5 con bzip2. 
MDS> 
si', ma vediamo un po' quando zip e bzip2 comprimono il file "compresso"...
poi trarremo conclusioni :-)
MDS> Con due formati (di cui uno semi-binario) ti incasini la vita tra
MDS> convertitori e altro... 
MDS> 
chissa' quanti convertitori... :-)
-- 
"Qualsiasi informazione che comporti un cambiamento nel progetto, sara'
trasmessa al progettista dopo -e soltanto dopo- che tutti i disegni sono
stati completati", prima legge delle Modifiche


Un bel di' Marco Pozzato scrisse:
MP> 
MP> a dirla tutta, basterebbero 6 bit e qualche cosa per un numero....ma credo che
MP> l'occupazione di spazio non sia il nostro problema principale. Per quello ci
MP> sono sempre i compressori che fanno miracoli :-)
MP> 
si', ma "pseudo compresso" + compressori quanto fa??
E poi scusate... io col Pascal e col C sono piu' comodo a leggere un numero
scritto come byte, che non come stringa :-)
MP> 162/35=4.6 volte
MP> 
MP> La semplice compressione con gzip riduce di un fattore 3 la dimensione, quindi
MP> senza far troppa fatica si va molto vicini all'ottimo.
MP> 
non ho capito: dici 1 file ed un solo formato, oppure sei favorevole al
doppio formato??
Vorrei solo portare un mio risultato (su P100): Cornucopia (con
questo non voglio fare ne' pubblicita', ne pubb. negativa) da me e'
abbastanza lento a caricare un archivio dal 39 al 98 :-)
Il fatto di spezzettare in piu' files puo' anche rendere piu' rapido
l'avvio... :-)
-- 
"Il tempo speso per ogni punto dell'ordine del giorno e' sempre inversamente
proporzionale alla somma di denaro che il punto comporta", legge
dell'Insignificanza


Un bel di' Victor scrisse:
V> ..inizio a sentire un certo peso alla nuca..:))
V> cerchiamo di arrivare ad una prima  prima versione..:)
V> 
beh... sul formato leggibile ci siamo: io direi di tenere almeno un formato
"normale":
gg/mm/aaaa
aa aa aa aa aa
bb bb bb bb bb
...
mettere tutto in fila confonde... se si deve aggiungere a mano :-)
Dopodiche', formato il primo archivio e testatolo, vorrei vedere se la mia
forma "pseudo compressa" puo' dare dei vantaggi :-)
Comunque il formato comunque sara' quello leggibile! :-)
Chi converte il primo archivio?? :)
-- 
"Quando il vostro gatto vi si e' addormentato in grembo e ha l'aria
perfettamente felice e adorabile, dovrete improvvisamente andare in bagno",
legge della frustrazione da felino


Un bel di' Marco Pozzato scrisse:
MDS>>  al limite dei 255 caratteri per riga.
MP> da dove arriva il massimo dei 255 caratteri per riga?
MP> 
MP> 
eh eh eh... Windows... :-))
-- 
"In ogni impresa umana, il lavoro cerca sempre il livello gerarchico piu'
basso", assioma di Vail


Un bel di' Marco Pozzato scrisse:
MP> 
MP> il primo campo separato da ':' è la data, il secondo è la ruota di bari, ecc...
MP> 
ma perche' usare lo scomodissimo ed illeggibile separatore ':', quando abbiamo
il bellissimo [A CAPO]?? :-)
MP> per avere la ruota di cagliari (la seconda ruota, il terzo campo) è sufficiente
MP> usare il comando cut (presente nel pacchetto GNU textutils) in questo modo:
MP> 
MP> c:>cut -d':' -f3 archivio.txt
MP> 
diventerebbe qualcosa come:
cut -d'\n' -f3 archivio.txt
-- 
"Colui che sorride quando le cose vanno male ha pensato a qualcuno cui dare
la colpa", legge di Jones


Ema da TIN ha scritto:
EdT>  Quindi visto che, per ora, gli scambi sono lenti, 
perchč sono lenti? in che senso?
MP>> - per prima: aggiornamento da programma piů sicuro (si crea un nuovo file e si
MP>> appende quello vecchio), per l'umano basta cominciare a ascrivere.
MP>> 
EdT>  perche' aggiornamento piu' sicuro?? :-)
perchč se anche succede qualche casino al disco, non stavi scrivendo
sull'archivio originale, ma su una sua copia. (ma forse questa cosa non ha
molto senso.....)
Ciao
Marco
-- 
Se non ti importa dove sei, non ti sei perso. (Regola di Rune)

ho utilizzato io.
Visto che hai creato un software diffuso commercialmente il tuo
apporto e' senz'altro gradito.:)
Ciao
Victor
PS: sto per postare un riassunto di quanto discusso fin'ora.


..scusa non riesco a seguirti, indici di che tipo?


Wolf
Questo solo per essere PRECISI !!!

Questo solo per essere PRECISI !!!
Sii preciso fino in fondo... Della volontaria omissione della routine
non ne eri nemmeno a conoscenza, hai visto il programma, hai pensato
(SBAGLIANDO TOTALMENTE!) che venissero lesi i tuoi diritti e hai
subito mandato una mail in cui ti indignavi perchè nessuno ti aveva
chiesto il permesso di fare una cosa del genere, permesso che tu MAI
avresti accordato... PER ESSERE PRECISI !
Wolf
"Lo stress è quell'apostrofo grigio tra le parole...M'INCAZZO"

 cut -d'\n' -f3 archivio.txt
cut lavora riga per riga, quindi non puoi usare \n come separatore di
campo. Il ritorno a capo deve essere ben significativo (tipo separare
una estrazione dalla successiva, se il file contiene piu' estrazioni).
ciao
					Michele

 poi trarremo conclusioni :-)
A tal punto che saranno piu' le intestazioni TCP/IP e protocolli vari
che i dati che devi trasferire per fare gli aggiornamenti.
Io tifo per tenere le estrazioni dell'ultimo anno su un file a parte
(l'unico da scaricare), che rimane di dimensioni sufficientemente
contenute (come la dimensione media di un messaggio email, anche
notevolmente piu' piccolo a gennaio/febbraio).
L'archivio intero si scarica una volta (o comunque raramente) e 300K
circa non mi sembrano esagerati. Diventerebbe piu' macchinoso
convertirli (a mio avviso).
ciao
					Michele

Un bel di' Michele Dalla Silvestra scrisse:
MDS> A tal punto che saranno piu' le intestazioni TCP/IP e protocolli vari
MDS> che i dati che devi trasferire per fare gli aggiornamenti.
MDS> 
non direi... rimane comunque sufficientemente grande. :-)
MDS> Io tifo per tenere le estrazioni dell'ultimo anno su un file a parte
MDS> (l'unico da scaricare), che rimane di dimensioni sufficientemente
MDS> contenute (come la dimensione media di un messaggio email, anche
MDS> notevolmente piu' piccolo a gennaio/febbraio).
MDS> 
mah, sono d'accordo con la tua idea, pero' secondo me non rispecchia
l'idea dello standard (quella che ho io, almeno).
Secondo me lo standard deve essere fisso.
Archivio completo.
Al max si decide di suddividerlo, ma piu' passa il tempo, piu' mi convinco
che tenerlo tutt'uno sia la cosa migliore.
Poi, ovvio, qualcuno si puo' incaricare di tenere un archivio-ridotto
nello stesso formato standard :-)
MDS> L'archivio intero si scarica una volta (o comunque raramente) e 300K
MDS> circa non mi sembrano esagerati. Diventerebbe piu' macchinoso
MDS> convertirli (a mio avviso).
MDS> 
beh, macchinoso se non sai programmare... ma se io insieme al mio
archivio compresso di do anche un programmino da 2Kb per convertirli
nel formato che vuoi?? :)
-- 
"Finche' si morde un lupo, pazienza. Quel che secca e' quando si morde una
pecora", legge di Joyce
-- 
Emanuele Cesena
em...@iol.it
          occhio all'antispam NOSPAM!
http://www.geocities.com/SiliconValley/Grid/8879

> cut -d'\n' -f3 archivio.txt
MDS> 
MDS> cut lavora riga per riga, quindi non puoi usare \n come separatore di
MDS> campo. Il ritorno a capo deve essere ben significativo (tipo separare
MDS> una estrazione dalla successiva, se il file contiene piu' estrazioni).
MDS> 
scusate, non conoscevo "cut" :-)
Comunque non e' un grosso problema: riscriviamo cut :-))
-- 
"8. Cammina sempre a gran velocita' quando sei fuori del tuo ufficio:
eviterai un gra numero di domande sia dai subordinati che dai superiori",
dal decalogo di Spark per il giovane manager


Un bel di' Marco Pozzato scrisse:
MP> Ema da TIN ha scritto:
EdT>>  Quindi visto che, per ora, gli scambi sono lenti, 
MP> perchè sono lenti? in che senso?
MP> 
perche' sono di soli 56 kBPS :-)
(molto meno in rete) :-)
EdT>>  perche' aggiornamento piu' sicuro?? :-)
MP> 
MP> perchè se anche succede qualche casino al disco, non stavi scrivendo
MP> sull'archivio originale, ma su una sua copia. (ma forse questa cosa non ha
MP> molto senso.....)
MP> 
ah gia'... non dovrebbe essere un nostro problema :-)))
A parte che quello dipende dal programma: posso aggiungere le nuove 
estrazioni anche in un file a parte e poi appenderlo solo alla fine... :-)
-- 
"Non replicare mai un esperimento riuscito", legge di Fett


>
V>  ...scusa non riesco a seguirti, indici di che tipo?
V>  
gli indici di affidabilità.
L'ultimo campo potrebbe essere la lista degli indici di affidabilità: mediante
un separatore convenzionale si identifica l'ultimo campo, che sarà formato a
sua volta da tanti numeri quante sono le ruote: per ogni ruota un valore
numerico da 5 bit indica quale/i dei 5 numeri non sono affidabili.
Ciao
Marco
-- 
Esistono solo errori. (Assioma di Robert)
L'errore di un uomo è la certezza di un altro uomo. 
(Corollario di Berman all'assioma di Robert)

Ema da TIN ha scritto:
EdT>  Un bel di' Marco Pozzato scrisse:
MP>> 
MP>> il primo campo separato da ':' è la data, il secondo è la ruota di bari, ecc...
MP>> 
EdT>  ma perche' usare lo scomodissimo ed illeggibile separatore ':', quando abbiamo
EdT>  il bellissimo [A CAPO]?? :-)
perchè trattandosi di un database, avendo stabilito di utilizzare un'unica
tabella per i dati, mi sembra più sensato usare un'unica riga per ogni record.
Perchè moltissimi programmi e filtri lavorano riga per riga.... insomma,
dovendoci lavorare sopra, non solo a mano, ma anche sfruttando qualche utility
GNU, mi sembra la soluzione più ovvia.
MP>> c:>cut -d':' -f3 archivio.txt
MP>> 
EdT>  diventerebbe qualcosa come:
EdT>  cut -d'\n' -f3 archivio.txt
EdT>  
credo che non funzionerebbe: cut legge tutta una riga fino al carattere di a capo, poi la interpreta!
Ciao
Marco
-- 
E' meglio risolvere un problema con forte approssimazione e sapere la verità
più o meno al 10%, che esigere una soluzione esatta e non sapere la verità per
niente. (Primo postulato di Thumb)

 avresti accordato... PER ESSERE PRECISI !
Io mi indignavo ???? ma rischerzi
ma allora prendi per il culo.
Eppoi sei tu che mi hai tirato in ballo
io mi sono inserito su questo argomento solo perche'
hai inserito il mio cognome IRONICAMENTE !!!!
senza una minima spiegazione......
Inoltre scusa sai  ma le e-mail non le ho mandate a te.......
ma a lui . o forse hai anche tu degli interessi
in moneta ???
Se vuoi le e-mail io le ho.........
e sta' tranquillo che non trovi neanche una delle affermazioni
che tu mi attribuisci.
ciao

in moneta ???
E' un mio amico e collega, lavora con me e mi ha chiesto (a suo tempo)
un parere sulla cosa, io non ci guadagno una lira...


Ho postato un riassunto ed una prima idea per lo standard...
L'avete vista?
Saluti
Victor

 nel formato che vuoi?? :)
Mi dai un programma con licenza GPL? Perfetto... :-)
Altrimenti no, grazie!
Ma penso che chiunque non sia psicologicamente impedito[1] ad usare un
computer sappia aprire un editor di testo e aggiungere un file alla
fine (se vuole un archivio completo su file unico). 
ciao
					Michele
[1] chi pensa di trovarsi di fronte ad un videoregistratore

Ema da TIN ha scritto:
MP>> a dirla tutta, basterebbero 6 bit e qualche cosa per un numero....ma credo che
MP>> l'occupazione di spazio non sia il nostro problema principale. Per quello ci
MP>> sono sempre i compressori che fanno miracoli :-)
MP>> 
EdT>  si', ma "pseudo compresso" + compressori quanto fa??
il compressore è un'utility di sistema (zip, gzip, ...)
lo zip tira giù tranquillamente di un terzo e non escludo che si possa fare di
meglio.
Poi, se proprio vuoi tirare, come ben sai, per rappresentare un cinquina basta
un numero da 1 a 43'949'268: il codice di codifica e decodifica occupa pochi
KB.
EdT>  E poi scusate... io col Pascal e col C sono piu' comodo a leggere un numero
EdT>  scritto come byte, che non come stringa :-)
e perchè mai?
ci sono istruzioni apposite per leggere stringhe e altrettante che convertono
in numeri.
EdT>  non ho capito: dici 1 file ed un solo formato, oppure sei favorevole al
EdT>  doppio formato??
mi sono perso...:-(
cos'era il doppio formato?
cmq, intendevo dire che il formato in chiaro occupa circa i MB per 130 anni,
ma se voglio occupare poco spazio (ad esempio per trasferirlo via internet)
posso comprimerlo. Di certo non può considerarsi un problema un archivio da 1
MB su disco piuttosto che da 300KB, visto che al giorno d'oggi 1 MB di hard
disk costa meno di 100 lire: non ci giochi neanche una bolletta del lotto :-))
EdT>  Vorrei solo portare un mio risultato (su P100): Cornucopia (con
EdT>  questo non voglio fare ne' pubblicita', ne pubb. negativa) da me e'
EdT>  abbastanza lento a caricare un archivio dal 39 al 98 :-)
non ho visto il formato dei dati, non so come vengano rappresentati in memoria
(e quindi convertiti), non so quanto sia bravo magopeppe a programmare e a
ottimizzare il codice...
ad esempio, sul mio Pentium 200 (che non va affatto al doppio del tuo, però)
un programmino che ho fatto, è istantaneo nel calcolare, in un sol colpo, la
frequenza degli ambi nelle 9 decine su ruota, dal 1900 e voltas'indrè :-)
(e questo non è merito di linux)
EdT>  Il fatto di spezzettare in piu' files puo' anche rendere piu' rapido
EdT>  l'avvio... :-)
e se poi vuoi fare ricerche su tutto l'archivio? lo devi comunque caricare,
aspettando. Allora, tanto vale avviare il programma senza archivio:
quest'ultimo verrà caricato solo al momento opportuno.
Ciao
Marco
-- 
Risparmiate l'acqua. Fate la doccia con un amico. (Mae West)

Ema da TIN ha scritto:
EdT>  Comunque non e' un grosso problema: riscriviamo cut :-))
ehh, che esagerazione: č open-software, i sorgenti sono disponibili.
basta modificarli....tutto sta a verificare quanto sia semplice..:-)
Ciao
Marco
-- 
Internet e' un posto dove andare quando vuoi accendere il cervello
La televisione e' un posto dove andare quando vuoi spegnerlo
(Steve Jobs)

Ema da TIN ha scritto:
EdT>>>  Quindi visto che, per ora, gli scambi sono lenti, 
MP>> perchè sono lenti? in che senso?
MP>> 
EdT>  perche' sono di soli 56 kBPS :-)
EdT>  (molto meno in rete) :-)
anche andando a 2Kbyte/sec, per scaricare 300Kbyte di archivio zippato in ftp,
bastano 2 minuti e mezzo, e stiamo parlando dell'archivio intero.
what's the problem?
Ciao
Marco
-- 
Quando non sai che cosa stai facendo fallo con la massima precisione. 
(Seconda legge del laboratorio)

Alessandro Pulvirenti ha scritto:
AP>  gg/mm/aaaa a1 a2 a3 a4 a5 b1 b2 b3 b4 b5 c1 c2 ... L1 L2 L3 L4 L5
..
AP>  Penso che il formato che ho utilizzato io č il piů adatto, poi fate voi!
e io sono d'accordo con te: semplice, chiaro e aout-esplicativo.
Magari lo si addobba un pochino, giusto per prevedere sviluppi futuri e
soprattutto se ne approfitta per codificare in modo preciso il tutto,
prendendo in considerazione anche i casi anomali.
Ciao
Marco
-- 
Non e' affatto necessario essere ricchi e famosi per essere felici. Basta
essere ricchi (Alan Alda)

>
V> separatori diversi vanno benissimo, solo non sono convinto di usare
V> gli spazi per separare i numeri della stessa ruota
V> 
suvvia, i caratteri piu' semplici vi fanno cosi' schifo?? :-)
-- 
"Riguardo ai propri problemi, la gente e' sempre molto conservatrice.
Riguardo a quelli degli altri, e' sempre molto liberale", legge di Kerr-Martin


> nel formato che vuoi?? :)
MDS> 
MDS> Mi dai un programma con licenza GPL? Perfetto... :-)
MDS> Altrimenti no, grazie!
MDS> 
no: se e' un programma di 2kb che converte e basta da un formato all'altro
non lo metto con licenza GPL, ma free, liberamente modificabile, 
scissibile, senza che mi venga reso noto delle modifiche che vengono fatte
a quel programma idiota... chemmenefrega?? :-)
La licenza GPL serve per programmi che hanno uno scopo nella vita...
questo sarebbe un'idiozzia: nemmeno degno di essere chiamato programma. :-)
MDS> Ma penso che chiunque non sia psicologicamente impedito[1] ad usare un
MDS> computer sappia aprire un editor di testo e aggiungere un file alla
MDS> fine (se vuole un archivio completo su file unico). 
MDS> 
certo... ma non eri tu che dicevi che 300kb erano pochi?? :-)
-- 
"Lasciate a se stesse, le cose tendono ad andare di male in peggio",
corollario 2 alla legge di Murphy


Un bel di' Marco Pozzato scrisse:
MP> perchč trattandosi di un database, avendo stabilito di utilizzare un'unica
MP> tabella per i dati, mi sembra piů sensato usare un'unica riga per ogni record.
Manno'... non e' un dbase: o almeno... e' un dbase leggibile!
E quindi lasciamolo leggibile!
Se vuoi fare un dbase lo fai non formattato, con numeri da 1 byte, data
da 4 (per comodita' nel comparare...) :-)
MP> Perchč moltissimi programmi e filtri lavorano riga per riga.... insomma,
MP> dovendoci lavorare sopra, non solo a mano, ma anche sfruttando qualche utility
MP> GNU, mi sembra la soluzione piů ovvia.
MP> 
mah... a me non gusta.
Ancheperche' la maggior parte delle persone di questo NG nno dispongono
delle utility GNU. :-)
Non e' giusto facilitarci noi (che sappiamo eventualmente programmare), 
sfavorendo chi non sa proprio nulla di Computer. :-)
EdT>>  diventerebbe qualcosa come:
EdT>>  cut -d'\n' -f3 archivio.txt
EdT>>  
MP> credo che non funzionerebbe: cut legge tutta una riga fino al carattere di a capo, poi la interpreta!
MP> 
Si', mi hanno riferito... ebbe', riscriviamo cut :-))
-- 
"Cambiare le cose e' l'essenza del comando; cambiarle prima di chiunque
altro e' creativita'", prima legge di Jay sul Comando


 
Va bene ma.... qui nessuno ti ha chiesto un parere sul caso
e queste tue SPARATE GRATUITE  puoi farle anche in privato
Visto che con cio' che scrivi passi solo per Un PETTEGOLO
che si interessa di cose di cui non fa parte...
Ricordati solo questo SPARARE PALATE DI MERDA sugli altri
come stai facendo tu primo o poi puo' ritorcerti contro.
Ma non sei anche tu quello che fa programmi per il lotto ?
hai forse paura di perdere CLIENTI...sta' tranquillo
io ne ho gia' piu' che a sufficenza.
Anzi non ho CLIENTI  ma MIGLIAIA di AMICI in tutta ITALIA
che non ho MAI FREGATO  (visto i prezzi che faccio!!)
e non si sono MAI lamentati ne' del programma ne' del mio
comportamento nei loro riguardi.
Questo TANTO PER FARE CHIAREZZA.
ADIOS  BURRO

ADIOS  BURRO
"Burro", che significa "asino", lo vai a dire a tutti i tuoi
consanguinei, visto che nonostante il mio tono aggressivo, non mi sono
mai sognato di offenderti.
...PER ESSERE CHIARI
Wolf
"Lo stress č quell'apostrofo grigio tra le parole...M'INCAZZO"

Un bel di' Marco Pozzato scrisse:
EdT>>  si', ma "pseudo compresso" + compressori quanto fa??
MP> il compressore è un'utility di sistema (zip, gzip, ...)
MP> 
MP> lo zip tira giù tranquillamente di un terzo e non escludo che si possa fare di
MP> meglio.
MP> 
appunto: quindi 1/3 per 1/3 fa 1/9... o sbaglio?? :-)
E nno mi ritirare a mano la epsilon... :-)))
MP> Poi, se proprio vuoi tirare, come ben sai, per rappresentare un cinquina basta
MP> un numero da 1 a 43'949'268: il codice di codifica e decodifica occupa pochi
MP> KB.
MP> 
no, non voglio tirare: un byte per numero mi basta, perche' poi,
in memoria, uso un byte per numero.
MP> e perchè mai?
MP> 
MP> ci sono istruzioni apposite per leggere stringhe e altrettante che convertono
MP> in numeri.
MP> 
si', ma perche' dover teneresi i dati in memoria un numero=un byte e su
disco un numero=una stringa??
E poi leggere+convertire e' piu' lungo di leggere+e basta :-))
MP> mi sono perso...:-(
MP> cos'era il doppio formato?
MP> 
1° formato: leggibile.
E qui non ci piove... resta da decidere se su una o piu' righe :-)
2° formato che proponevo: non formattato... quello di cui stavamo
discutendo :-)
MP> cmq, intendevo dire che il formato in chiaro occupa circa i MB per 130 anni,
MP> ma se voglio occupare poco spazio (ad esempio per trasferirlo via internet)
MP> posso comprimerlo. Di certo non può considerarsi un problema un archivio da 1
MP> MB su disco piuttosto che da 300KB, visto che al giorno d'oggi 1 MB di hard
MP> disk costa meno di 100 lire: non ci giochi neanche una bolletta del lotto :-))
MP> 
no... non era per quello (anche: io in Linux c'ho pochi mega...) ma
gia' in itnernet dovresti scaricarti 100kb invece di 300 :-)
MP> non ho visto il formato dei dati, non so come vengano rappresentati in memoria
MP> (e quindi convertiti), non so quanto sia bravo magopeppe a programmare e a
MP> ottimizzare il codice...
MP> 
il formato e' molto simile a quello leggibile di cui stiamo discutendo
(mancano gli "a campo :-)" ).
in memoria vengono rappresentati abbastanza in modo standard, sicuramente
non come stringhe.
MagoPeppe e' il piu' grande programmatore e ottimizzatore che esista! :-)
Una sua patch tiene 100kb, Cornucopia intera tiene 250kb :-))))
MP> ad esempio, sul mio Pentium 200 (che non va affatto al doppio del tuo, però)
MP> un programmino che ho fatto, è istantaneo nel calcolare, in un sol colpo, la
MP> frequenza degli ambi nelle 9 decine su ruota, dal 1900 e voltas'indrè :-)
MP> (e questo non è merito di linux)
MP> 
beh, un pochinoinoino si' :-)
Ma poi te lo sappiamo tutti che c'hai i PC fallati... anche i ridotti ci
mettevi 10 secondi, e io 3 giorni :-)
MP> e se poi vuoi fare ricerche su tutto l'archivio? lo devi comunque caricare,
MP> aspettando. Allora, tanto vale avviare il programma senza archivio:
MP> quest'ultimo verrà caricato solo al momento opportuno.
MP> 
aho... io sono favorevole al file unico... cercavo solo di venirvi
incontro qui... per accaparrarmi le "piu' righe" :-)
-- 
"La vita, la liberta' e la proprieta' di ogni uomo sono in pericolo quando
il parlamento e' riunito", postulato di Jacquin sui Governi Democratici


Un bel di' Marco Pozzato scrisse:
MP> Ema da TIN ha scritto:
EdT>>  Comunque non e' un grosso problema: riscriviamo cut :-))
MP> ehh, che esagerazione: č open-software, i sorgenti sono disponibili.
MP> basta modificarli....tutto sta a verificare quanto sia semplice..:-)
MP> 
certo, si'... anch'io parlavo di modificare... :-)
-- 
"Un generatore di numeri casuali non puo' essere scelto a caso", Knuth


Un bel di' Marco Pozzato scrisse:
MP> anche andando a 2Kbyte/sec, per scaricare 300Kbyte di archivio zippato in ftp,
MP> bastano 2 minuti e mezzo, e stiamo parlando dell'archivio intero.
MP> what's the problem?
MP> 
ma metterci molto meno vi infastidisce cosi' tanto?? :-)))
-- 
"Riguardo ai propri problemi, la gente e' sempre molto conservatrice.
Riguardo a quelli degli altri, e' sempre molto liberale", legge di Kerr-Martin


Ema da TIN ha scritto:
MP>> Perchč moltissimi programmi e filtri lavorano riga per riga.... insomma,
MP>> dovendoci lavorare sopra, non solo a mano, ma anche sfruttando qualche utility
MP>> GNU, mi sembra la soluzione piů ovvia.
MP>> 
EdT>  mah... a me non gusta.
EdT>  Ancheperche' la maggior parte delle persone di questo NG nno dispongono
EdT>  delle utility GNU. :-)
quale occasione migliore per procurarsele e imparare a usarle? :-)
EdT>  Non e' giusto facilitarci noi (che sappiamo eventualmente programmare), 
EdT>  sfavorendo chi non sa proprio nulla di Computer. :-)
io credo invece che sfruttando le texutils si potrebbe creare una raccolta di
script per fare cose interessanti, il tutto sfruttando la filosofia del
pipe&filter, tipica di unix.
Io uso questa 'tattica' da tempo ed č molto efficace per fare analisi potenti
e senza perdere troppo tempo a scrivere programmi ad hoc.
Ciao
Marco
-- 
La scienza e' vera. Non fatevi traviare dai fatti. (Credo di Finangle)

Ema da TIN ha scritto:
MP>> lo zip tira giù tranquillamente di un terzo e non escludo che si possa fare di
MP>> meglio.
MP>> 
EdT>  appunto: quindi 1/3 per 1/3 fa 1/9... o sbaglio?? :-)
non capisco.
L'archivio ascii occupa un mega, lo zip tira di 1/3 e scende a 300 e rotti k
EdT>  E nno mi ritirare a mano la epsilon... :-)))
ehehe
EdT>  no, non voglio tirare: un byte per numero mi basta, perche' poi,
EdT>  in memoria, uso un byte per numero.
e che spreco!
5 byte =40 bit per una cinquina, quando ne sono sufficienti 26! :-))
e tu vuoi sprecare tuttto questo spazio su disco? :-D
EdT>  si', ma perche' dover teneresi i dati in memoria un numero=un byte e su
EdT>  disco un numero=una stringa??
perchè la memoria la legge la CPU, mentre i file li leggono gli umani che
hanno seri problemi di efficienza coi codici binari :-)
EdT>  E poi leggere+convertire e' piu' lungo di leggere+e basta :-))
EdT>
e chi lo dice?
ho appena fatto un programmino che verifica quante ripetizioni di numeri ci
sono sulle cinquine e calcola la frequenza (come float, quindi usando la FPU
che rallenta...) sulle cinquine: solito programma a riga di comando, archivio
testuale da 130 anni, il tutto in 4.7 secondi per 10 ruote su un P200. Non so
se sia tanto o poco, ma mi sembra molto più che accettabile.
E si tratta di un programma scritto in 4 e 4 8, senza ottimizzazioni.
EdT>  no... non era per quello (anche: io in Linux c'ho pochi mega...) ma
EdT>  gia' in itnernet dovresti scaricarti 100kb invece di 300 :-)
ahh, ora capisco 1/3 per 1/3!
purtroppo non è così!
se usi il formato 'stretto' non puoi comprimere di un terzo.
un cinquina necessita di 25.4 bit, al di sotto è _impossibile_ andare.
(allora non hai ancora dato un'occhiata a quegli appunti sulla teoria
dell'informazione di cui ti avevo parlato mesi fa?)
sole le 10 cinquine dell'estrazione (senza contare la data) occupano 32 byte,
nessun compressore può scendere al di sotto.
Forse, con un compressore inventato ad hoc, si potrebbe risparmiare ancora
qualche byte, relativamente alle estrazioni con meno di 10 ruote.
EdT>  il formato e' molto simile a quello leggibile di cui stiamo discutendo
EdT>  (mancano gli "a campo :-)" ).
e ti credo!
maga peppe ha lasciato l'aratro per la sega :-)
MP>> un programmino che ho fatto, è istantaneo nel calcolare, in un sol colpo, la
MP>> frequenza degli ambi nelle 9 decine su ruota, dal 1900 e voltas'indrè :-)
MP>> (e questo non è merito di linux)
MP>> 
EdT>  beh, un pochinoinoino si' :-)
no, anzi: semmai linux in questo caso rallenta, perchè si cucca un po' di CPU
time, fregandolo da sotto il naso ai programmi. Invece il buon vecchio DOS
tira...
EdT>  Ma poi te lo sappiamo tutti che c'hai i PC fallati... anche i ridotti ci
EdT>  mettevi 10 secondi, e io 3 giorni :-)
EdT>  
questo era merito della codifica usato per le colonne e per la routine di
confronto, queste sì ottimizzate. E poi tu scrivevi ancora codice a 16 bit....:-)
EdT>  aho... io sono favorevole al file unico... cercavo solo di venirvi
EdT>  incontro qui... per accaparrarmi le "piu' righe" :-)
EdT>  
a me il multiline sta proprio sul gozzo :-))
Ciao
Marco
-- 
Il progresso non consiste nel rimpiazzare una teoria sbagliata con una giusta,
ma nel rimpiazzare una teoria sbagliata con una sbagliata in maniera piu'
sottile. (Teoria di Hawkins sul progresso)

Un bel di' Marco Pozzato scrisse:
EdT>>  mah... a me non gusta.
EdT>>  Ancheperche' la maggior parte delle persone di questo NG nno dispongono
EdT>>  delle utility GNU. :-)
MP> quale occasione migliore per procurarsele e imparare a usarle? :-)
MP> 
ma tu sei pholle... :-))
MP> io credo invece che sfruttando le texutils si potrebbe creare una raccolta di
MP> script per fare cose interessanti, il tutto sfruttando la filosofia del
MP> pipe&filter, tipica di unix.
MP> 
MP> Io uso questa 'tattica' da tempo ed è molto efficace per fare analisi potenti
MP> e senza perdere troppo tempo a scrivere programmi ad hoc.
MP> 
vabbuo' :-)
-- 
"2. Fatti sempre vedere con la gente che conta", dal decalogo di Spark per
il giovane manager


Un bel di' Marco Pozzato scrisse:
EdT>>  appunto: quindi 1/3 per 1/3 fa 1/9... o sbaglio?? :-)
MP> non capisco.
MP> L'archivio ascii occupa un mega, lo zip tira di 1/3 e scende a 300 e rotti k
MP> 
quello non formattato tiene circa 1/3 di quello ASCII, ossia 300kb.
Lo comprimi, ed arriverai a 200-150 :-)
MP> e che spreco!
MP> 5 byte =40 bit per una cinquina, quando ne sono sufficienti 26! :-))
MP> e tu vuoi sprecare tuttto questo spazio su disco? :-D
MP> 
ok, ma in memoria, usi 26 bit?? :-)
MP> perchč la memoria la legge la CPU, mentre i file li leggono gli umani che
MP> hanno seri problemi di efficienza coi codici binari :-)
MP> 
e anche con i separatori strani :-))
EdT>>  E poi leggere+convertire e' piu' lungo di leggere+e basta :-))
EdT>>
MP> e chi lo dice?
MP> 
io!
MP> ho appena fatto un programmino che verifica quante ripetizioni di numeri ci
MP> sono sulle cinquine e calcola la frequenza (come float, quindi usando la FPU
MP> che rallenta...) sulle cinquine: solito programma a riga di comando, archivio
MP> testuale da 130 anni, il tutto in 4.7 secondi per 10 ruote su un P200. Non so
MP> se sia tanto o poco, ma mi sembra molto piů che accettabile.
MP> 
MP> E si tratta di un programma scritto in 4 e 4 8, senza ottimizzazioni.
MP>
mah... sulle ottimizzazioni avrei da ridire... ormai ottimizzi in
automatico!
E poi 4.7sec sul tuo P200 diventano 10 sul mio P100, per non
parlare del mio 386 40MHz, sempre che non decida di far fare i
conti al mio 286 12 :-)
 
MP> ahh, ora capisco 1/3 per 1/3!
MP> purtroppo non č cosě!
MP> se usi il formato 'stretto' non puoi comprimere di un terzo.
MP> 
vabbe', comprimerai alla meta' :-)
Rimane sempre molto ridondante...
MP> un cinquina necessita di 25.4 bit, al di sotto č _impossibile_ andare.
MP> (allora non hai ancora dato un'occhiata a quegli appunti sulla teoria
MP> dell'informazione di cui ti avevo parlato mesi fa?)
MP> 
quali appunti!? :-)
MP> sole le 10 cinquine dell'estrazione (senza contare la data) occupano 32 byte,
MP> nessun compressore puň scendere al di sotto.
MP> 
MP> Forse, con un compressore inventato ad hoc, si potrebbe risparmiare ancora
MP> qualche byte, relativamente alle estrazioni con meno di 10 ruote.
MP>
Non ho capito una Valeria, ma mi sa che ti sbagli: nel file ci saranno 90 
valori che si ripeteranno un sacco di volte... secondo me uno zip
comprime benissimo! :-)
 
MP> no, anzi: semmai linux in questo caso rallenta, perchč si cucca un po' di CPU
MP> time, fregandolo da sotto il naso ai programmi. Invece il buon vecchio DOS
MP> tira...
MP> 
che stress!! :-)
EdT>>  Ma poi te lo sappiamo tutti che c'hai i PC fallati... anche i ridotti ci
EdT>>  mettevi 10 secondi, e io 3 giorni :-)
EdT>>  
MP> questo era merito della codifica usato per le colonne e per la routine di
MP> confronto, queste sě ottimizzate. E poi tu scrivevi ancora codice a 16 bit....:-)
MP> 
aho... :-)
Io dico che era il PC :-))
MP> a me il multiline sta proprio sul gozzo :-))
MP> 
a me sta in sul gozzo il tuttosuunariga :-)
-- 
"Grazie a Dio sono ateo"


Ema da TIN ha scritto:
MP>> non capisco.
MP>> L'archivio ascii occupa un mega, lo zip tira di 1/3 e scende a 300 e rotti k
MP>> 
EdT>  quello non formattato tiene circa 1/3 di quello ASCII, ossia 300kb.
EdT>  Lo comprimi, ed arriverai a 200-150 :-)
dipende dalla quantità di informazione contenuta (nonostante l'apparenza, la
"quantità di un informazione" è un termine tecnico e ben preciso e misurabile)
A 150Kb non ci arrivi neanche piangendo in cinese se vuoi memorizzare 7000
estrazioni da 10 ruote con la data: per arrivarci ci vorrebbe una compressione
di tipo lossy, che _perde_ informazione.
Ci sono 44 milioni di combinazioni equiprobabili, quindi utilizzando una
codifica a dimensione fissa occorrono log2(4'949'268)=25.4 bit per
rappresentarla.
MP>> e che spreco!
MP>> 5 byte =40 bit per una cinquina, quando ne sono sufficienti 26! :-))
MP>> e tu vuoi sprecare tuttto questo spazio su disco? :-D
MP>> 
EdT>  ok, ma in memoria, usi 26 bit?? :-)
se vuoi sì: eri tu che ci tenevi a stringere....
con un array da 9 byte rappresenti tutte e 10 le cinquine di un'estrazione
 
MP>> E si tratta di un programma scritto in 4 e 4 8, senza ottimizzazioni.
MP>>
EdT>  mah... sulle ottimizzazioni avrei da ridire... ormai ottimizzi in
EdT>  automatico!
è un discorso molto lungo...
EdT>  E poi 4.7sec sul tuo P200 diventano 10 sul mio P100, 
magari il P200 fosse 2 volte veloce  il P100.
EdT>  parlare del mio 386 40MHz, sempre che non decida di far fare i
EdT>  conti al mio 286 12 :-)
il 286 era a 16 bit, quindi ne risentirebbe parecchio
MP>> ahh, ora capisco 1/3 per 1/3!
MP>> purtroppo non è così!
MP>> se usi il formato 'stretto' non puoi comprimere di un terzo.
MP>> 
EdT>  vabbe', comprimerai alla meta' :-)
EdT>  Rimane sempre molto ridondante...
il limite è di 26 bit per cinquina
x 10 cinquine
+ i bit per la data
il tutto moltiplicato per il numero di estrazione
sotto questo valore, una compressione senza perdita non può andare
 
MP>> (allora non hai ancora dato un'occhiata a quegli appunti sulla teoria
MP>> dell'informazione di cui ti avevo parlato mesi fa?)
MP>> 
EdT>  quali appunti!? :-)
te ne avevo parlato mesi fa in e-mail, erano sulla home-page di Tubaro
MP>> sole le 10 cinquine dell'estrazione (senza contare la data) occupano 32 byte,
MP>> nessun compressore può scendere al di sotto.
MP>> 
EdT>  Non ho capito una Valeria, ma mi sa che ti sbagli: nel file ci saranno 90 
EdT>  valori che si ripeteranno un sacco di volte... secondo me uno zip
EdT>  comprime benissimo! :-)
EdT>   
se tu riesci a scendere al di sotto dei 32 byte per estrazione, io riuscirò a
darmi un bacio in fronte :-)
MP>> questo era merito della codifica usato per le colonne e per la routine di
MP>> confronto, queste sì ottimizzate. E poi tu scrivevi ancora codice a 16 bit....:-)
MP>> 
EdT>  aho... :-)
EdT>  Io dico che era il PC :-))
EdT>  
'an vedi questo! :-)
io c'avevo un 486dx2 66MHz a quell'epoca.
mica un Pentium...:-DD
MP>> a me il multiline sta proprio sul gozzo :-))
MP>> 
EdT>  a me sta in sul gozzo il tuttosuunariga :-)
EdT>  
allora facciamo metà e metà :-)
Ciao
Marco
-- 
Il senno di poi e' una scienza esatta. (Regola di Fagin)

darmi un bacio in fronte :-)
Scusate ma non sarebbe meglio "cavare il sangue dalle pietre"?
[...]
Bacetto Marcuzzo, ciao! :)
MagoPeppe
ICQ 9759626
"La fortuna è donna e va battuta". (Machiavelli)
Staff Tecnico MPO & NuovaCornucopia
Home page:
http://dreamlink.net/magopeppe
ATTENZIONE: il mio indirizzo email cambierà dal 16 Giugno 1999.
Togli levaccà per contattarmi via email.

EdT>>  Lo comprimi, ed arriverai a 200-150 :-)
MP> 
MP> dipende dalla quantità di informazione contenuta (nonostante l'apparenza, la
MP> "quantità di un informazione" è un termine tecnico e ben preciso e misurabile)
MP> 
MP> A 150Kb non ci arrivi neanche piangendo in cinese se vuoi memorizzare 7000
MP> estrazioni da 10 ruote con la data: per arrivarci ci vorrebbe una compressione
MP> di tipo lossy, che _perde_ informazione.
MP> 
eh eh eh... :-)
non lo sapevo :-)
MP> Ci sono 44 milioni di combinazioni equiprobabili, quindi utilizzando una
MP> codifica a dimensione fissa occorrono log2(4'949'268)=25.4 bit per
MP> rappresentarla.
MP> 
MP> 
Ma che bello... :-)
MP>>> 
EdT>>  ok, ma in memoria, usi 26 bit?? :-)
MP> se vuoi sì: eri tu che ci tenevi a stringere....
MP> con un array da 9 byte rappresenti tutte e 10 le cinquine di un'estrazione
MP>  
che stress! :-)
MP>>> E si tratta di un programma scritto in 4 e 4 8, senza ottimizzazioni.
MP>>>
EdT>>  mah... sulle ottimizzazioni avrei da ridire... ormai ottimizzi in
EdT>>  automatico!
MP> è un discorso molto lungo...
MP> 
ok, evitiamolo :-)
EdT>>  parlare del mio 386 40MHz, sempre che non decida di far fare i
EdT>>  conti al mio 286 12 :-)
MP> il 286 era a 16 bit, quindi ne risentirebbe parecchio
MP> 
eh eh eh... sempre a cercare il pelo nell'uovo :-))
 
MP> il limite è di 26 bit per cinquina
MP> x 10 cinquine
MP> + i bit per la data
MP> il tutto moltiplicato per il numero di estrazione
MP> sotto questo valore, una compressione senza perdita non può andare
MP>  
ok, mi fido :-)
EdT>>  quali appunti!? :-)
MP> te ne avevo parlato mesi fa in e-mail, erano sulla home-page di Tubaro
MP> 
ehm ehm... :-(
MP> se tu riesci a scendere al di sotto dei 32 byte per estrazione, io riuscirò a
MP> darmi un bacio in fronte :-)
MP> 
non dubito che ce la faresti :-))))
MP> 'an vedi questo! :-)
MP> io c'avevo un 486dx2 66MHz a quell'epoca.
MP> mica un Pentium...:-DD
MP> 
appunto :-))
MP>>> a me il multiline sta proprio sul gozzo :-))
MP>>> 
EdT>>  a me sta in sul gozzo il tuttosuunariga :-)
MP> 
MP> allora facciamo metà e metà :-)
MP> 
vabbe', cedo :-)
-- 
"1. Per quanto uno faccia, non fara' mai abbastanza.
 2. Quel che non si fa e' sempre piu' importante di quello che si fa",
dilemmi del Lavoratore
