Newsgroup: it.scienza.informatica
Titolo: Enzo Criscione

Ciao a tutti, su comp.compression oggi mi sono imbattuto in un post di
un tale che parlava di aver letto di una "incredible compression
ratio", di quelle che si leggono ogni tanto in giro.
Ma rispetto al solito, e rispetto al mitico personaggio Jules Gilbert
(che sostiene di aver inventato un metodo di compressione ricorsiva!),
l'algoritmo di cui si parlava aveva una particolarità: l'aveva fatto
un italiano!
Ho cercato su Google e mi sono imbattuto su questo ng, e poi qui:
http://www.db.avvenire.it/avvenire/edizione_2004_03_06/oggi_frontiere.html
Da cui sono finito su:
http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=TW487854
dove c'è anche la documentazione del brevetto pubblicamente
scaricabile, in formato PDF.
Che ne pensate? Non ho avuto tempo di leggere quel papiro di roba, ma
lo farò quanto prima.
Ho visto che sul ng è una persona già conosciuta, e ovviamente è presa
con le molle (e pure io lo faccio)
Volevo soltanto condividere la mia "scoperta" con voi e sentire che ne
pensate.
Ciao,
Marco

 lo farò quanto prima.
Ho dato una scorsa alle 42 pagine di blablabla....
sostanzialmente il metodo di compressione proposto consisterebbe
nell'applicare ripetutamente una determinata funzione
ad una porzione dell'input, visto come un numero.
Il numero di volte che e' stato necessario applicare la funzione
per raggiungere un determinato valore costituisce
la "compressione" dell'input. Invertendo la funzione
e iterando un numero opportuno di volte si ottiene
la decompressione.
Questa sarebbe la sua idea "rivoluzionaria" (come dice lui),
anche se a me sembra che sia stata gia' proposta e riproposta
in tutte le salse.
Negli esempi che lui disegna (le flow-chart) la funzione che viene
iterata e' il decremento unitario (!!!)
Poi piu' avanti si sbilancia a spiegare meglio quale funzione
iterata usare e fa anche un esempio di come
comprimerebbe il file che contiene dei bit il cui valore numerico
corrisponde al numero 100. Il procedimento corrisponde a determinare
i valori iniziali di una serie di Fibonacci generalizzata, il cui
n-esimo termine corrisponde al numero da comprimere.
Cioe',
100 verrebbe compresso come una tripla (10,14,4)
dove 10 e 14 sono i valori iniziali e 4 il numero di iterazioni,
e la decompressione avviene come:
10+14=24
14+24=38
24+38=62
38+62=100
La compressione, ovvero la coppia di numeri iniziali viene ottenuta
ponendo il primo numero (62) uguale a 100 per la sezione aurea 
(sqrt(5)-1)/2, e poi andando a ritroso fino a che si puo'.
Questo medoto potrebbe anche sembrare intelligente:
in fondo, siccome le sequenze fibonacci-like crescono
esponenzialmente, anche partendo da numeri piccoli e
in un numero piccolo di passi posso arrivare a grandi numeri,
ottenendo cosi' una bella compressione.
Il problema e' che non e' vero che questo costituisca
in generale una compressione, cosi' come non e' vero
che io possa sempre ricondurmi  a numeri piccoli.
Per esempio se voglio "comprimere"
2147614720
 che e' un numero che occupa 32 bit,
procedendo come Criscione ottengo la tripla
{35340, 6784, 25}
Siccome 35340 > 6784 non posso andare avanti,
o meglio, posso andare avanti quanto voglio, ma
ottengo numeri negativi che poi in valore assoluto
crescono.
Ora, se uno va a vedere quanti bit ci vogliono
per rappresentare 35340, 6784 e 25 vede bene
che non ho copresso un bel nulla....
E' chiaro che ci sono dei casi in cui la compressione
e' buona, anche buonissima,
per esempio 218922995834555169026 lo posso
"comprimere" nella tripla {1,0,99},
ma sono controbilanciati
dai casi (piu' frequenti) in cui non c'e'
compressione alcuna (o meglio c'e' una "espansione"...).
Questo non e' strano:
se consideriamo "piccolo" un numero di 8 bit,
(tanto per fare un esempio) e' evidente che con
una tripla di 8+8+8 bit al massimo posso codificare
256*256*256 = 16777216 numeri diversi, molti dei quali
saranno molto maggiori del numero 16777216.
Questo significa che ci sono molti numeri minori di 16777216
(che occupa 24 bit) che NON posso codificare con quel sistema in 24
bit.
Insomma, il brevetto non spiega affatto come Criscione riesca
(cosa della quale dubito fortemente) a comprimere qualsiasi file
di 100 mega in 100-200 bytes, come lui afferma,
anzi gli esempi che porta sono di fatto controproducenti.
Io sinceramente non riesco a capire se questo signore crede veramente
nelle cose che dice o se ha brevettato 'sta roba (molto generica)
nella speranza di poter accampare diritti qualora qualcuno trovi
un metodo funzionante di compressione attraverso iterazione funzionale.
ciao,
g.

~\/~ "Giovanni" == Giovanni Resta <g.r...@iit.cnr.it.nospam> writes:
Giovanni> Marco wrote:
citiamo meglio in presenza di altri Marco (io sono MARco, MunARi)
entrati in discussione, ci tengo a precisare che quel "Marco" citato
cosi` sinteticamente fa riferimento a
         > From: "
pattu...@pippo.it
 (Marco)"
         > X-Original-NNTP-Posting-Host: 151.96.0.8
         > MX-Original-X-Trace: 
posting.google.com
 1079964819
         >          8109 127.0.0.1 (22 Mar 2004 14:13:39 GMT)
....
Giovanni> Ho dato una scorsa alle 42 pagine di blablabla....
Complimenti Giovanni per essere arrivato in fondo a quel nausenate bla bla,
_estraendone_ con impegno _correttivo_, qualcosa di sensato.
Io avevo visto che faceva riferimento anche a 5 figure assenti,
le istruzioni non erano spiegate (quantomeno per giustificare
"INPUT file A" seguito poi da "SET A=A-1" in uno stesso flow chart)
che denota come minimo incompetenza nella teoria di cosa e` un file.
avrei postato qualcosa dicendo che il castello di sabbia di
Enzo Crescione crollava dove dava una personale e limitata
definizione di "rapporto di compressione di uno *schema* di compressione"
facendo riferimento ad uno specifico solo input (evidentemente scelto
da lui su cui costruisce l'algoritmo), non all'input generico.
.....
Giovanni> Il problema e' che non e' vero che questo costituisca in
Giovanni> generale una compressione, cosi' come non e' vero che io
Giovanni> possa sempre ricondurmi a numeri piccoli.  Per esempio se
Giovanni> voglio "comprimere" 
2147614720
 che e' un numero che occupa
Giovanni> 32 bit, procedendo come Criscione ottengo la tripla {35340,
Giovanni> 6784, 25} Siccome 35340 > 6784 non posso andare avanti, o
Giovanni> meglio, posso andare avanti quanto voglio, ma ottengo numeri
Giovanni> negativi che poi in valore assoluto crescono.  Ora, se uno
Giovanni> va a vedere quanti bit ci vogliono per rappresentare 35340,
Giovanni> 6784 e 25 vede bene che non ho copresso un bel nulla....
Giovanni> E' chiaro che ci sono dei casi in cui la compressione e'
Giovanni> buona, anche buonissima, per esempio 218922995834555169026
Giovanni> lo posso "comprimere" nella tripla {1,0,99}, ma sono
Giovanni> controbilanciati dai casi (piu' frequenti) in cui non c'e'
Giovanni> compressione alcuna (o meglio c'e' una "espansione"...).
Giovanni> Questo non e' strano: se consideriamo "piccolo" un numero di
Giovanni> 8 bit, (tanto per fare un esempio) e' evidente che con una
Giovanni> tripla di 8+8+8 bit al massimo posso codificare 256*256*256
Giovanni> = 16777216 numeri diversi, molti dei quali saranno molto
Giovanni> maggiori del numero 16777216.  Questo significa che ci sono
Giovanni> molti numeri minori di 16777216 (che occupa 24 bit) che NON
Giovanni> posso codificare con quel sistema in 24 bit.
Senza tener poi conto che in un file non c'e` spontaneo spazio
per una terna di valori aperti, senza introdurre meccanismi
(che occupano spazio) per permettere a questi tre numeri
di crescere indefinitamente.
Giovanni> Insomma, il brevetto non spiega affatto come Criscione
Giovanni> riesca (cosa della quale dubito fortemente) a comprimere
Giovanni> qualsiasi file di 100 mega in 100-200 bytes, come lui
Giovanni> afferma, anzi gli esempi che porta sono di fatto
Giovanni> controproducenti.
Giovanni> Io sinceramente non riesco a capire se questo signore crede
Giovanni> veramente nelle cose che dice o se ha brevettato 'sta roba
Giovanni> (molto generica) nella speranza di poter accampare diritti
Giovanni> qualora qualcuno trovi un metodo funzionante di compressione
Giovanni> attraverso iterazione funzionale.
Giovanni> ciao, g.
Saluti,
MARco
-- 
x(t),y(t) = th(3t-34.5)*e^[-(3t-34.5)^2]/2-4.3+e^(-1.8/t^2)/(.8*atg(t-
3)+2)(t-1.8)-.3th(5t-42.5),(1.4e^[-(3t-34.5)^2]+1-sgn[|t-8.5|-.5]*1.5*
|sin(pi*t)|^[2e^(-(t-11.5)^2)+.5+e^(-(.6t-3.3)^2)])/(.5+t)+1  ; 0<t<14

 ha scritto nel messaggio
news:2ba248af.04032...@posting.google.com...

oggi al tg3 delle marche ha dimostrato al giornalista V. Varagona di
riuscire a comprimere un file "incomprimibile" costituito da una "sequenza
di dna" dimenticanto di dire che le informazioni genetiche sono tutt'altro
che "incomprimibili" essendo caratterizzate da una forte ridondanza. (tra le
atre anche da una interessante "codifica di canale" stile Hamming)

 atre anche da una interessante "codifica di canale" stile Hamming)
Apparizione Iterata a Neapolis, sempre su RaiTre: gli dev'essere stata
aperta una fidejussione di credibilità... ;-)
DarK

 scaricabile, in formato PDF.
non riesco a scaricarla tutta in una botta, ma solo una pagina alla volta.
che sistema del bip...
-- 
              o         _        _            _
   _o        /\_      _ \\o     (_)\__/o     (_)
 _< \_      _>(_)    (_)/<_       \_| \      _|/' \/
(_)>(_)    (_)           (_)      (_)       (_)'  _\o_
----------- 
http://magicforum.altervista.org
 ----------