Newsgroup: it.comp.programmare.win32
Titolo: algoritmo di compressione 2 la vendetta

Inizio un nuovo thread perchè altrimenti mi perdo nelle risposte di quello
precedente..
Chiariamo alcuni punti.
1) Per ora il programma è stato scritto con una vecchia versione di VB, a 16
bit, e non è stato ancora compilato, ma le prove le ho sempre fatte con il
prog allo stato di progetto.
2) Come avrete capito, non sono un programmatore professionista, non mi
interessa diventarlo e non voglio vivere di questo. I soldi non mi fanno
schifo, e se posso ricavare qualche cosa da questa mia idea, tanto di
guadagnato.
3) Finora ho fatto solo dei miseri e puzzolenti gestionali personalizzati, e
il massimo che ho potuto chiedere da un cliente è stata la misera cifra di
1.200.000 ...
4) Perchè parlo del Fortran? Semplice, il C è troppo complicato da imparare
in pochi mesi, e io prima dell'estate 2002 voglio aver riscritto la parte
matematica dell'algoritmo in un linguaggio diverso dal VB, e solo allora
busserò alle porte di qualche pezzo grosso.
5) Il Fortran 90 è un linguaggio che, a quanto ne so io, sta vivendo una
seconda giovinezza. Tutti i ricercatori universitari lo usano. Io conosco un
ingegnere che mangia Fortran a colazione, e mi ha detto che una routine
matematica o statistica, che abbia parti "ricorsive" (che sono quelle che
"fottono" il VB in quanto a velocità), lavora a una velocità 100 volte
superiore rispetto al VB. Quindi, la stessa funzione, se con il VB ci mette
1 minuto, con il Fortran 90 ci mette 0,6 secondi... ergo: il mio programma,
fatto in Fortran, schizzerebbe...
6) Il Fortran ha una sintassi simile al Basic, molto piu del C, ovviamente,
e quindi mi sento a "casa mia", e nel giro di 2-3 mesi posso imparare il
Fortran a un livello medio-basso, tale che mi consenta di scrivere una
routine matematica relativamente semplice, e compilarla come DLL "leggibile"
da VB.
7) Il primo problema da affrontare nei prox gg. è quello di portare il prog
da VB3 a VB6 a 32 bit. Ma sarà una cosa abbastanza semplice.
8) Il secondo problema è quello della lettura dei bytes. Finora ho usato Get
e Put, ma sono di una mosceria, di una lentezza stratosferica. Quindi dovrò
usare l'Api ReadFile, stando attento a non leggere, in una botta sola, un
numero eccessivo di bytes (ad es., ho provato a leggere, con un'unica
istruzione, 200 MB, e mi ha dato un bell'overflow...).
9) A questo programma sono affezionato in maniera particolare. Vi spiego
brevemente la storia. Il giorno piu brutto e significativo della mia vita,
il 30 gennaio 1991, ero uno scazzillo liceale che scappava di casa un giorno
sì e l'altro pure. Quel giorno scappai con l'intenzione di non tornare più.
Fu una giornata di merda. All'epoca mi piaceva moltissimo la geometria.
Mentre vagavo disperato per la città fui folgorato da un'immagine geometrica
stilizzata disegnata per caso per terra... all'epoca non sapevo granche di
programmazione, facevo programmini scemotti con QBasic, ma quell'immagine mi
è rimasta impressa per 9 anni. Quando all'inizio del 2000 ho preso in mano
il VB, e ho iniziato a fare programmini un po piu elaborati, avendo
quell'immagine ancora ben chiara, pensai a come utilzzarla nell'ambito della
programmazione. Per un anno intero, ho lavorato a questa idea. L'algoritmo
originario era un algoritmo "figurativo" (definizione azzeccata ma difficile
da spiegare), insomma, si basava più su regole geometriche che matematiche.
Una settimana fa avevo raggiunto quello che credevo fosse la fine del mio
lavoro, e provai tutto eccitato a comprimere un grosso file. La compressione
non fu un problema... ma la decompressione sì... In pratica l'algoritmo si
basava su un miscuglio tra formulette geometriche e di calcolo combinatorio,
ma mi accorsi purtroppo che non c'era corrispondenza biunivoca tra la
sequenza di bytes originaria e quella ottenuta con la compressione. In
pratica, mentre una sequenza di bytes poteva essere compressa in un unico
modo, una sequenza compressa poteva essere decompressa in piu di un modo...
Mi incazzai come una belva, anche perche l'algoritmo originario aveva una
potenza stratosferica. Qualsiasi sequenza di bytes la comprimeva SEMPRE, e
sottolineo SEMPRE, dell'83 %... capite che significava scoprire che non
potevo decomprimerla ??!!??!! Capite che cosa significa comprimere un
filmato di 100 MB in un file di 17 MB, SEMPRE ??!!??!! Ora, se io fossi un
programmatore professionista, se fossi un esperto di matematica (non lo
sono, perche all'università ho preso una facolta che con l'informatica non
ha niente a che vedere), potrei sicuramente lavorare sul vecchio algoritmo,
quello dell'83 %, e rendere la parte decompressa "biunivoca", fornendo
alcuni "indizi" al decompressore... ma purtroppo le mie conoscenza
matematiche sono sfumate nel tempo... e quindi una settimana fa pensai di
mettere una pietra sopra a questo bel sogno...
10) Poi 2-3 gg. fa la "scoperta"... Rinunciando alla compressione dell'83 %
(cosa che mi rode ancora...), alle formulette geometriche e statistiche da 4
soldi, potevo ottenere una "via di mezzo", piu veloce della precedente, ma
ovviamente meno potente. E infatti l'algoritmo attuale riduce SEMPRE con una
ratio che va dal 45 al 50 %.
11) Per concludere, tra qualche giorno avrò info piu dettagliate sui tempi e
sulle ratio di compressione e di decompressione, usando le Api (bzzz...
bzzz... !!) e la versione 32 bit del VB.
12) Quando fra qualche mese avrò imparato il Fortran, parlerò di questo
programma ai pezzi grossi di tutte le aziende che mi vengono in mente, a
cominciare da Intel, Compaq, Symantec, Microsoft, IBM, Adobe, Oracle, AOL,
Excite, Yahoo, ... e se qualcuno ha qualche nome di qualche grossa aziendona
americana o inglese presente anche in Italia si faccia avanti. Voi mi
chiederete: "Perche la parte in Fortran non te la fai fare dal tuo amico
ingegnere?". Semplice... perchè è un fottuto avidone del ca**o... per 2 lire
ammazzerebbe la madre, e se gli dico che ho ideato un algoritmo di
compressione, lui rimette in attività il lager di Auschwitz solo per me, mi
ci chiude dentro e non mi fa uscire finquando non gli ho rivelato il
codice... ::)))) Io sono un "one-man-worker"... per ora non faccio lavoro di
squadra, poi si vedrà...
Bye
P.S.: per Lorenzo: ho preso il file che mi hai detto... stasera ti faccio
sapere.

 [MEGA-CUT]
SEI UN GRANDE!!!
-- 
Luc.

Luc <XXX...@katamail.comXXX> wrote in message
MPG.1638f7b72...@news.enter.it...

solo perche ho iniziato un nuovo thread ??!!??!! ::))))
Ugo

 stilizzata disegnata per caso per terra... 
Sara' stata mica la fascia di triangolini bianchi del "dare precedenza" ?
Anche a me fanno un certo effetto :)
p.s.: finora parole, parole, parole, niente fatti, fatti, fatti ;)
-- 
Posted from  [80.105.34.80] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

>>>> "DH" == Delta Hug <xx@xx.x> writes:
DH> 5) Il Fortran 90 è un linguaggio che, a quanto ne so io, sta vivendo una
DH> seconda giovinezza. Tutti i ricercatori universitari lo usano.
Perché  non hanno  imparato  altro.  Ora credo  abbia  perso anche  il
vantaggio delle routine matematiche.
DH> 6) Il Fortran ha una sintassi simile al Basic, molto piu del C,
Hai detto una cavolata grande come una casa che dimostra che non sei un pro :)
Mi spiace ma il FORTRAN  è un linguaggio sintatticamente antiquato che
si porta tuttora  ad esempi di come NON si scrive  un linguag- gio con
un esempio  che viene  dalla storia e  da una  marea di tempo  e soldi
perso  dalla NASA  (si  tratta  della dichiarazione  di  un ciclo  che
diventa l'uso di una variabile floating  point se si mette un punto al
posto  di   una  virgola  -  se  hanno   introdotto  la  dichiarazione
obbligatoria  delle  variabili ci  hanno  messo  una pezza).   Nessuna
accusa a  chi ha scritto  FORTRAN, non aveva  gli errori di  nessuno a
insegnargli qualcosa.
DH> 8) Il secondo problema è quello della lettura dei bytes.
Buono il FORTRAN qui!!! UUUUH
DH> l'Api ReadFile
Comprati  il libro  Advanced  Windows di  Richter,  esistono i  memory
mapped files. Ma voglio vedere cos'è usare le API da FORTRAN.
Seconda cosa. Se fai  un'implementazione troppo dipendente dal sistema
ne castri l'esistenza, per quanto sia diffuso Windows.
DH> 9) Per un anno intero, ho lavorato a questa idea. L'algoritmo
DH> originario era un algoritmo "figurativo" (definizione azzeccata ma difficile
DH> da spiegare), insomma, si basava più su regole geometriche che matematiche.
Porca malosca! Qui va a finire  che abbiamo uno che capisce in maniera
istintiva gli algoritmi frattali di compressione.... (NO JOKE!)
DH> modo, una sequenza compressa poteva essere decompressa in piu di un modo...
Hai   sbattuto  il   naso  probabilmente   sulle   funzioni  trap-door
(l'inversione   è  computazionalmente  un   casino  immane)   o  erano
semplicemente non invertibili ?
DH> se fossi un esperto di matematica (non lo
DH> sono, perche all'università ho preso una facolta che con l'informatica non
DH> ha niente a che vedere),
Passa a Matematica!
DH> 12) Quando fra qualche mese avrò imparato il Fortran, parlerò di questo
NON IMPARARE IL FORTRAN! NON IMPARARE IL FORTRAN! NON IMPARARE IL FORTRAN!
Non è facile (lo ho usato) e non ha la potenza del C.
L'unica cosa dove ha senso  usare il fortran sono alcuni supercomputer
paralleli in  quanto il FORTRAN  parallelo è uno  di quelli che  se la
cavano meglio.
--
Gian Uberto| main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}
Lauri      |                        David Korn, 1987 ioccc best one liner 
(aka saint)|-------------------------------------------------------------------
em@ail: 
sa...@eng.it
 ( vedere X-nospam nello header - see X-nospam in header )

fatto in Fortran, schizzerebbe...
Anche COBOL è diffuso ma non per questo ti dico di scrivere in COBOL!
Impara il C che è meglio, soprattutto è veloce e portabile! Poi quando
ormai l'algoritmo funziona è possibile ottimizzare qualche parte
particolarmente lenta in asm.
Scrivendolo in Fortran avresti un altro problema cioè che magari
l'azienda che ti compra l'algoritmo non ha dipendenti che capiscono il
fortran.
-- 
Marco Barisione (ICQ 84277092)


Di nuovo, SEMPRE significa che puo' essere usato solamente per comprimere
immagini.
Se comprime SEMPRE perde informazioni, quindi non va bene per comprimere
file generici.
Accertati che comprima davvero SEMPRE, perche' in questo caso hai di nuovo
qualche funzione one-way all'interno.
Se la funzione non e' one-way, stai dimenticando dei dati.
Non fidarti, ad esempio, delle funzioni in virgola mobile, salvano comunque
sempre solo un'approssimazione del numero iniziale, percui perdono dati.
Anche io ai tempi avevo pensato ad algoritmi di compressione, ma poi
pensandoci meglio mi sono reso conto che per comprimere un'informazione
qualunque devi poter contare che, dall'altra parte, esista una parziale
conoscenza, almeno probabilistica, del dato originale.
Per esempio: se vuoi comprimere un dato che probabilmente e' ricco di zeri
contigui, puoi inviare un bit di intestazione ogni x che specifichi se il
byte o il nibble successivo sia di dati o indichi il numero di bit zero a
seguire...
Ma questo presuppone che tu SAPPIA a priori che l'informazione sara' ricca
di bit zero contigui, altrimenti il risparmio dovuto ai byte che specificano
il numero di zero contigui si perde nella dimensione dei byte stessi e nel
numero di bit di intestazione che devi inviare.
Trovo interessante quanto diceva Gian Uberto in merito a una tua possibile
comprensione istintiva degli algoritmi di compressione frattale... Sarebbe
un gran colpo :)
Ricorda che gli algoritmi frattali, a quanto mi risulta, sono
intrinsecamente lossy, quindi servono solo per comprimere immagini :)
Ciaotutti,
*


non so manco che cosa sia un frattale... e in questo momento non mi
interessa... ::))))
in ogni casoentro domani vi darò info piu precise... non dico di essere
sicuro di non aver fatto una bufala... dico solo che se è una bufala, non me
ne sono accorto manco io, finora...
poi fra una settimana inizio a imparare il Fortran 90, e fra 2-3 mesi
chissa, forse avrò 2 lire in piu in tasca.......
Ugo

 precedente.. [...]
Hai mai sentito parlare di un certo DePalma e della sua N-machine? Si tratta
di un fisico (da poco deceduto) che sosteneva di avere costruito un
macchinario, derivato da un'idea di Faraday, che produce una quantita` di
energia cinque volte superiore a quella che assorbe. Teneva un prototipo di
questa macchina nel suo garage, e diceva che non poteva accenderlo per
dimostrarne l'efficacia perche` altrimenti il governo glielo avrebbe
sequestrato.
Hai mai sentito parlare di un certo Laureti e dell'ASPS? Si tratta di un
fisico che sostiene di aver trovato una "falla" in una legge fondamentale
della fisica, e quindi di riuscire a costruire una macchina a propulsione
non-newtoniana che genera energia dal nulla (almeno dal punto di vista della
fisica "ufficiale"). Che io sappia qualsiasi prova che ha fornito e`
autoreferenziata, e (sempre che io sappia) non ha mai dato dimostrazioni a
nessuno che non sia lui o un suo amico.
Tu ti chiederai: "perche` mi stai raccontando queste cose?". Pensaci bene e
lo capirai. ;-)
--
Bye! Lorenzo Lutti

chissa, forse avrò 2 lire in piu in tasca.......
Lascia perdere il Fortran, non e' piu' utilizzato per questi
scopi.
-- 
The Follet

poi fra una settimana inizio a imparare il Fortran 90
Ma allora ne sei proprio convinto?


Hai mai sentito parlare di un certo Laureti e dell'ASPS?
Molto piu' umilmente, hai mai sentito parlare di un certo
Mago Gabriel ?
Dice di vedere gli gnomi, solo che, siccome e' mago, li puo'
vedere solo lui :)
-- 
The Follet

 Hai mai sentito parlare di un certo
mai sentiti questi signori ...
ok ora facciamo sul serio, perche mi sto cominciando ad offendere... ::)))))
ribadisco per la milionesima volta: non è a voi che devo dimostrare il
funzionamento del mio programma, ma a chi deciderà di comprarlo...
ora seguitemi con MOLTA attenzione... please... il Mago Gabriel sta per
parlare a voi miscredenti... ::))))
(ps, nel thread passato mi avete chiamato "troll"... non so che cosa
significa, ma sono sicuro che è un'offesa... ma tralasciamo...::)))))
mi sono appena accorto che per colpa del VB il mio prog non funziona...
l'algoritmo è giusto, facendo i calcoli con la calcolatrice di win funziona
da dio, ma lo passo in vb e non funziona.
volete la spiegazione? semplice.
provate a fare
Dim X, Y
X = 7E+16
Y = X + 1
Debug.Print X - Y
sapete quanto vi esce ?
0
eh gia...
e il mio prog ha bisogno di fare calcoli simili... quindi... la routine
matematica la DEVO scrivere in un altro linguaggio...
ho dato un'occhiata a un paio di programmini assembly che sommano strutture
ularge_integer, a 64 bit, ma sinceramente non mi sento di avventurarmi su
quel terreno... è davvero troppo complesso l'assembly.
il C lo scarto a priori perche ci metterei 2 anni per impararlo
dite quello che volete, ma io domani compro un libro sul Fortran 90.
ora, se mi volete dare i seguenti consigli, bene, altrimenti amen, cercherò
altrove...
1) chi conosce il Fortran 90, mi puo assicurare che se sommo un numero MOLTO
grande (tipo 2 ^ 20), con un numero piccolo come 1 (restando sempre nel
campo degli interi, niente virgola), non mi viene fuori la porcheria che
viene fuori col VB, per cui Y = X + 1 = ..... X ??!!??!! me lo potete
assicurare?
2) chi conosce un buon libro sul Fortran 90 ?
3) chi conosce un buon compilatore per il Fortran ? e ovviamente un buon
linker, che possa fare DLL leggibili da altre applicazioni a 32 bit ? avevo
sentito parlare di un certo Compaq Visual Fortran... che mi dite ? utilizza
la stessa "sintassi" del Fortran 90 che si studia sul libro di cui al punto
2 ? che consigli mi potete dare ?
ah, un'ultima pillola per i miscredenti... il VB ha, come visto sopra, quel
limite maledetto per quanto riguarda i calcoli con numeri troppo grossi. ho
provato di tutto, con CDec, Currency, Double, ma NIENTE.... si perde i
numeri per strada...
ovviamente ho visto anche da che punto in poi cio avviene. il che significa
che potrei "limitare" la potenza dell'algoritmo, mantenendomi entro quei
limiti, ma NON VOGLIO... preferisco aspettare 2 mesi ma fare un algoritmo
potente... dimenticavo... la cifra della ratio, 45-50 % , era per difetto...
quando potro usare il Fortran, ho appena visto, facendo i calcoli a mano e
con la calcolatrice di Win, la ratio sarà 45-63 %...
aspetto fiducioso numerosi consigli...
Ugo (alias Mago Gabriel)

con la calcolatrice di Win, la ratio sarà 45-63 %...
Mah... non so che pensare... tu non sarai sicuramente un
troll, ma sei la persona piu' simile a un troll che abbia
mai visto girovagare sui ng :)
Non te la prendere, ma non puoi pretendere di far digerire
qualcosa di difficilmente credibile senza prove concrete :)
Non ti devi infuriare se nessuno ti da' dei consigli su
quello che cerchi, si e' molto piu' propensi a dare consigli
qualora non ci si senta presi in giro :)
-- 
The Follet


Secondo me scoprira che, quando avra' abbastanza cifre da non predere
precisione, il risultato della compressione avra' la stessa dimensione del
file originale.
Si perde delle cifre significative per strada.... A questo prezzo posso
farlo pure io un ottimo algoritmo di compressione, peccato che sia
impossibile decomprimerlo :PP
Ciaotutti,
*


Beh, te lo auguro, anzi, CE lo auguro: se davvero hai trovato un algoritmo
che comprime *qualunque* informazione anche solo dello 0.00000000001%, ma
SEMPRE, applicandolo N volte si avrebbe un'informazione (e ho detto
informazione, non file, quindi un dato a bassa ridondanza) di parecchi MB
all'interno di un file di pochi KB, il tutto a prezzo di una certa quantita'
di potenza di calcolo, che oggi compri a due lire al megaherzt, con dei
vantaggi enormi per tutti.
Pero' qualcosa mi dice che prima faresti meglio a studiare un po' di
matematica :)
Ciaotutti,
*

> 
DH> quindi non è "lossy" (come dite voi... PS: che razza di termini... ::))))
Non è un "che razza di  termine". E' un termine tecnico di derivazione
inglese. "loss"  vuol dire perdita,  "lossy" è l'aggettivo  che indica
"con perdita", "lossless" significa "senza perdita"
DH> poi fra una settimana inizio a imparare il Fortran 90, e fra 2-3 mesi
NON IMPARARE IL FORTRAN! PASSA AL C, NON E' VERO CHE FORTRAN E' PIU' SEMPLICE
NON IMPARARE IL FORTRAN! PASSA AL C, NON E' VERO CHE FORTRAN E' PIU' SEMPLICE
NON IMPARARE IL FORTRAN! PASSA AL C, NON E' VERO CHE FORTRAN E' PIU' SEMPLICE
NON IMPARARE IL FORTRAN! PASSA AL C, NON E' VERO CHE FORTRAN E' PIU' SEMPLICE
NON IMPARARE IL FORTRAN! PASSA AL C, NON E' VERO CHE FORTRAN E' PIU' SEMPLICE
NON IMPARARE IL FORTRAN! PASSA AL C, NON E' VERO CHE FORTRAN E' PIU' SEMPLICE
NON IMPARARE IL FORTRAN! PASSA AL C, NON E' VERO CHE FORTRAN E' PIU' SEMPLICE
NON IMPARARE IL FORTRAN! PASSA AL C, NON E' VERO CHE FORTRAN E' PIU' SEMPLICE
NON IMPARARE IL FORTRAN! PASSA AL C, NON E' VERO CHE FORTRAN E' PIU' SEMPLICE


 aspetto fiducioso numerosi consigli...
cui non vuoi dar peso...
Cmq ed infine: cosa succede se tenti la compressione di un file gia'
compresso col tuo algoritmo?
Saluti
Paolo Arosio


se oggi ho la botta di culo che dico io, succederà questo: se comprimo un
file col mio prog, lui lo comprime mettiamo del 40 % (con il fortran
arriverei a 45/63 %, restando con VB e con le limitazioni dei variant, long,
double, poso arrivare fino a 40-45 %, mentre ho provato a fare i calcoli con
la calcolatrice di Win e arrivo a volte fino al 63 %).
se lo comprimo di nuovo, lui lo coprime di un ulteriore 40 %...... ma di
questo non sono ancora sicuro...
sembra impossibile, lo so, ma credo che sia così... e senza perdere un
cacchio di byte....
il problema è la lentezza della scompattazione... per compattare basta una
iterazione (un prog di 50 MB lo compatta in meno di un secondo), per
scompattare ce ne vogliono parecchie... anche per questo devo passare ad un
linguaggio meno lento di VB.
bye
Ugo

 iterazione (un prog di 50 MB lo compatta in meno di un secondo)
Altre str*nzat* come queste e ti killo!!!!!!!!!!!!!!!
Scusate per il quoting eccessivo...
-- 
Luc.

 iterazione (un prog di 50 MB lo compatta in meno di un secondo),
Non c'e' dubbio, e' un troll :)


 Non c'e' dubbio, e' un troll :)
Secondo me ci sono tre possibilita':
1) e' un troll: 30%
2) si e' perso qualcosa (tipo un 40% delle sifre significative, a giudicare
da quello che scrive) per strada: 70%
3) siamo di fronte ad un genio di tale portata che il suo lavoro
rivoluzionera' la vita di tutti noi:
Un uomo che ha creato un algoritmo in grado di comprimere qualunque
informazione con un tasso di compressione MINIMO inferiore ad 1:1 (quindi
almeno 1.0[...]1:1), il che significa che, comprimendo N volte una certa
informazione, si arrivera' a contenere MB e MB di dati in pochi kB di file
compresso.
Ovviamente questo rivoluzionera' anche la teoria dell'informazione (perche'
il suo algoritmo "non si basa sulle ridondanze ma sui bit") e gli fruttera'
miliardi di dollari e una notorieta' al cui confronto Linus Torvalds sara'
piu' ignoto del creatore dell'aranciata gasata.
La probabilita' di questa terza opzione e', ovviamente, il resto della
differenza tra la somma delle probabilita' precedenti e il canonico 100% :)
Io spero che sia un troll, perche' se e' in buona fede andra' incontro ad
una delusione devastante.
Ciaotutti,
*

> e il tipo dov'e'? Prova
DH> il tipo non c'č apposta, perche se metto Long non va oltre una certa cifra,
DH> se metto Double si impalla con le virgole..
?????????????????????????????????????????????????????????????????????
DH>  ... quindi ci vuole il variant.
Beh, allora ci vuole anche un bel loop vuoto da 1 a 10000 per dare un'altra
rallentata :) :) :) :)
DH> io i congili li vorrei sul compilatore... finora ho preso un compilatore
DH> gratuito (ELF90) che fa un po cagare, e manco ho capito come si fanno le
DH> DLL...
Oddio, nella suite del GCC - anche sotto Windows graze a Cygwin - c'č un 
Fortran. 
Quanto alle DLL... ti voglio vedere fare la DllMain() in FORTRAN :).
DH> se lo comprimo di nuovo, lui lo coprime di un ulteriore 40 %...... ma di
DH> questo non sono ancora sicuro...
Questo parremi pericoloso - per il fatto che il programma funzioni - 
DH> sembra impossibile, lo so, ma credo che sia cosě... e senza perdere un
DH> cacchio di byte....
Sei  sicuro che  la funzione  sia realmente  invertibile ?  Non vorrei
trovarmi a comprimere la foto  di una teiera e riespandendola trovarmi
un armadillo.... :)


un armadillo.... :)
Impossibile. L'algoritmo non solo e' potente, ma si basa su
un meccanismo intelligente.  Nel caso dell'immagine teiera,
il file compresso e' un file di testo con scritto "teiera". 
-- 
The Follet

una delusione devastante.
Pensa in positivo, se è un genio che rivoluziona l'informatica tu
potrai dire ai tuoi nipotini "IO ERO LI`!"  ;-)


un armadillo.... :)
Bhé è ancora provvisorio (lo devo ancora riscrivere in c++ e metterlo
un po' a posto visto che è stato scritto maluccio) ma funziona, riesce
a comprimere un file del 50% circa *sempre*, purtroppo non sono ancora
riuscito a far scendere l'archivio ottenuto sotto il byte ma ci
proverò.
#Questo software è sotto GPL
input = open("in", "rb")
output = open("out", "wb")
w = 1
for c in input.read():
    if w:
        output.write(c)
    w = not w


 potrai dire ai tuoi nipotini "IO ERO LI`!"  ;-)
BELLO! ANCH'IO!!!
O racconta storie, o ha il cervello compresso mpeg (tipcamente lossy).
Se desideri non offenderti, dichiara pubblicamente la prima (fine del
divertimento).


Veloce, codice semplice, cosa puoi chiedere di piů?
Ne ho fatto uno migliore io, perň richiede l'originale per
scompattare. Lo chiamerň "copy", a causa di un algoritmo segreto, che
non posso rivelare a nessuno.

     w = not w
Interessante.
Ho pero' sentito parlare di una cosa che comprime *tutto* in 16 (o 32?)
byte, ma ha un nome un po' criptico: "md5".
Secondo voi vale la pena di approfondire?
Saluti
Paolo Arosio

 writes:
PA> Ho pero' sentito parlare di una cosa che comprime *tutto* in 16 (o 32?)
PA> byte, ma ha un nome un po' criptico: "md5".
Ha a che fare con la  criptatura se non ricordo male... Non vorrei che
quello sia un digest...


 quello sia un digest...
criptatura:=crittografia e sia=fosse...
Non mi ricordo (strano, l'avevo visto di recente), ma... sě, č un
algoritmo di hashing.
Un'occhiatina a MSDN... 16 byte.

 writes:
Ir> Non mi ricordo (strano, l'avevo visto di recente), ma... sì, è un
Ir> algoritmo di hashing.
Ir> Un'occhiatina a MSDN... 16 byte.
Non è un algoritmo di hashing banale (forse MSDN se ne dimentica :>).
Un   message  digest  (cryptographic   checksum  o   fingerprint)  )ha
particolari proprietà:
	E' computazionalmente improponibile calcolare una stringa
	che generi lo stesso digest
	Il digest non rivela nulla del contenuto
		(Non serve a comprimere, quindi :) )
	Il  cambiamento  di  1  solo  bit  del  messaggio  provoca  il
	cambiamento di almeno metà dei bit del digest.
E questo è per essere  corretti sull'algoritmo. Ieri sera, dopo 10 ore
pesanti di ufficio con un po' di febbre (causa degli errori di lingua)
ancora mi ricordavo,  anche se non con certezza,  cosa era dopo alcuni
mesi che avevo toccato  l'argomento, qualche corrifogna non è riuscito
a  dare   una  definizione  corretta   nemmeno  dopo  aver   letto  la
documentazione :)


 documentazione :)
Ehi, sono un ratto carino, e quando esco dalle fogne mi lavo!
Comunque su MSDN non parlava nel dettaglio (o io non sono sceso nel
dettaglio, volevo solo vedere se generava 128bit o no).
Ciao.
Ps: visto che ti lamenti di chi sta nelle fogne, perché voi tutti non
vi impegnate un po' a tenerle più pulite?
--
The Secret of Tabboz Island
http://it.geocities.com/tabbozisland

> 
Ir> In pratica, è un algoritmo di hashing.
Si,  ma non  si usa  usualmente per  l'hashing classico,  anche perché
almeno per ora un array con indice a 128 bit è arduo a trovarsi... :)
Anche  se  indubbiamente  dovrebbe  dare  un  numero  molto  basso  di
collisioni.


Delta Hug, per curiosità: quanti anni hai?


Ehm... Indubbiamente, pero' la creazione di un array di 2^128 puntatori da
32 bit la vorrei proprio vedere...
Anche nei prossimi dieci anni, eh? Non ho fretta :P
Ciaotutti,
*

> 
*> Ehm... Indubbiamente, pero' la creazione di un array di 2^128 puntatori da
*> 32 bit la vorrei proprio vedere...
*> Anche nei prossimi dieci anni, eh? Non ho fretta :P
Siamo in 2 :).  Anche perché ci  vuole lo spazio per il qualcosa a cui
puntano, se no  servono a nagott. Non mi servono 2^19  - 1 puntatori a
NULL, me ne basta 1...


 che generi lo stesso digest
...
a meno, ovviamente, di sapere conbuona precisione cosa contenesse la
stringa originale.
cmq direi che effettivamente e' dura ritrovare la sequenza di bit-e-byte
originaria disponendo solo del digest (ovviamente se non si dispone di
un computer a la Quarantine).
Saluti
Paolo Arosio


Anche se lo sai...
Il principio per cui nasce il digest e' quello di generare una base per la
firma digitale: tu hai il messaggio in chiaro, il digest criptato con la
chiave privata e la chiave pubblica; decripti il digest, lo ricalcoli
partendo dal messaggio originale e confronti il tuo digest con quello
ottenuto dalla decriptazione del digest di firma.
Se sono uguali, la chiave che ha firmato il digest e' la chiave privata
della chiave pubblica che hai usato per decriptarlo, inoltre il messaggio
non e' stato modificato; se sono diversi o la chiave privata non era quella
che pensavi o qualcuno ha modificato il messaggio.
Ciaotutti,
*

> che generi lo stesso digest
PA> ...
PA> a meno, ovviamente, di sapere conbuona precisione cosa contenesse la
PA> stringa originale.
Neanche conoscendo quella. C'è gente con lo scroto tetragono che ci ha
lavorato sopra.
Lo scopo  è proprio impedire  che qualcuno modifichi il  messaggio (la
stringa)  originale  senza che  sia  possibile  scoprirlo. Trovare  le
ulteriori  modifiche che  devi fare  al messaggio  modificato affinché
abbia  lo  stesso  digest  dell'originale è  computazionalmente  molto
arduo, improponibile in pratica.
PA> cmq direi che effettivamente e' dura ritrovare la sequenza di bit-e-byte
PA> originaria disponendo solo del digest (ovviamente se non si dispone di
PA> un computer a la Quarantine).
Questa  invece  non  è  dura.   E' impossibile  perché  hai  eliminato
dell'informazione.  Se  sommo  500  numeri  differenti  non  li  posso
ricostruire a partire dalla loro somma.
