Newsgroup: it.comp.programmare.win32
Titolo: Algoritmo di compressione 3...

Scusate se apro un nuovo 3D ma volevo solo porre una domanda all'attenzione
di Delta Hug...
Se il tuo programma comprime TUTTI i files ALMENO del 40 - 50 %... se io lo
uso con un file da 10 MB ne otterrei uno da circa 5 MB... ridandolo in pasto
al tuo programma ne uscirebbe un'altro da 2.5 MB, e ripetendo l'operazione
svariate volte... otterrei un bel file da 1 byte come ti è stato già
suggerito da qualcuno...
Quindi, penso che il tuo programma NON possa comprimere QUALUNQUE file
sempre a 40 - 50 %... o perdi delle informazioni oppure ad un certo punto
(con certi file) NON comprimi nulla...
Spero d'aver spiegato bene il mio dubbio...
Scusa per la banalità, vorrei sapere cosa ne pensi di questa mia idea...
Ciao!
P.S.
Non ho nulla per NON crederti... vorrei solo sapere come è possibile
comprimere TUTTI i file a (circa) il 50 % perchè se così fosse, lo userei
per comprimere i file "appena compressi" dal tuo stesso programma per
ridurli ancora del 50% :-)
--
Virtual (24, 120, MI)
e-mail: 
vir...@lombardiacom.it

Hmmmm... mi e' venuto un sospetto... :)
L'ottimo Delta Hug ha bisogno di numeri floating point con TANTE cifre
decimali, non e'che il suo algoritmo per funzionare ha bisogno di INFINITE
cifre decimali, per caso? E' solo un sentore, ma tanti decimali+algoritmo
geometrico lasciano spazio a dubbi. Dubbi non possono esistere, invece, sul
fatto che un algoritmo che comprima qualunque file di un fattore fisso
esista o meno. Che non si possa comprimere piu dell' entropia del segnale
e' noto da troppo tempo, e come i prototipi di moti perpetui di prima e
seconda specie non sono piu presi in considerazione dalla fine dell' 800
(due secoli, ormai), cosi' algoritmi del genere non lo sono ai giorni
nostri. 
Ho un amico, al tempo direttore di un CNR, che si occupa di complessita'
strutturale. 
Qualche ora alla settimana la doveva passare a vagliare e cestinare
dimostrazioni P=NP inviategli, per quanto riguardava algoritmi di
compressione a fattore fisso tralasciava il vaglio.
p.s.
e' vero che tra zero e uno ci sono infiniti valori razionali, ma servono
infinite cifre per descriverli

 di Delta Hug...
abbiate 1-2 gg. di pazienza... sto facendo i test... con calma... al
tempo... ::))))
poi farò una bella conferenza stampa virtuale sul NG e vi dirò a che
risultati sono giunto.
vi posso dire sin da ora solo una cosa. l'algoitmo che riduce al 50 %
funziona, ma non con VB... se eseguo i calcoli a mano, comprime e decomprime
tranquillamente, ma se lo passo su VB no... quindi mi serve un altro
linguaggio.
sul VB mi sono dovuto limitre alla grande... e cioe il massimo che posso
fare è comprimere del 25 %, ma con la possibilita di comprimere unaltra
volta del 25 %, e questo per ALMENO 5 volte, e senza perdere manco una
virgola...
quando passero al fortran potro comprimere per 5 volte del 50 %.
non ho ancora visto cosa succede se comprimo per la sesta volta, non sono
cose semplici che si risolvono in due minuti... soprattutto se si conosce
solo il VB.
fra qualche gg. saprete tutto...
un'ultimissima cosa, proprio per evitare casini, il programma NON usa numeri
con la virgola, ma solo numeri interi... numeri molto grossi certo, ma solo
interi.
bye
Delta Hug

quando passero al fortran potro comprimere per 5 volte del 50 %.
Sicche', fammi capire, un file di 100Mb lo comprimi la prima
volta e ne ottieni 50, la seconda ne ottieni 25, la terza
12,5, la quarta 6,25 e la quinta 3,125.
Sono un po' perplesso: tu comprimi 100 Mb in 3 Mb ?
Secondo me hai preso una cantonata grande quanto una casa :)
-- 
The Follet

solo il VB.
Bhé è veramente molto difficile dare un file in input ad un programma
una volta in più!
-- 
Marco Barisione (ICQ 84277092)

 una volta in più!
Pssss, ehi, shhhhhh. Non infastidirlo... non vedi che ha problemi di
spionaggio industriale? Lasciatelo lavorare in silenzio, dai.
DeltaHug: sei riuscito a decomprimere almeno uno dei file che avevi
compresso? Con che risultati?


a mano sì... con VB no...
non chiedermi di spiegarti come, altrimenti capisci tutto, e non è questo
che voglio...
in breve, a mano io vedo "a occhio" da che punto partire, con VB devo
effettuare calcoli un po complicati, e ci perde un po di tempo...
sono certo che esiste un metodo matematico sicuro che mi permetterebbe di
evitare tuttii calcoli.... ma non lo conosco...
per farla breve. io SO quale è il METODO per tornare ai bytes originari, ma
non so se esiste un metodo che consenta ad un software di farlo in breve
tempo. se vedo che il programma funziona ugualmente, ma è lento, chiedo ad
un professore universitario di matematica di risolvermi il problema, senza
dirgli che si tratta di un algoritmo di compressione... inutile dire che NON
conosco professori universitari di matematica, quindi mi presento un giorno
alla facoltà (inutile dire che non so neanche dove sta la facoltà di
matematica) e chiedo "c'è un prof di math che ha 5 min per me?" ::))))
Ugo

Per dovere di cronaca, il nostro amico MarioH alias DeltaHug
alias Ugo ha scritto da qualche parte :
"a proposito di algoritmi di compressione, se on sbaglio è
morto quello che ha inventato il primo, quello della PKZIP,
aveva 37 anni ed è morto in condizioni schifose, in mezzo
alle bottiglie di liquore semivuote, ubriaco, sporco, con i
vicini che protestavano per i cumuli di spazzatura dentro e
fuori la sua casa... insomma, un bill gates al contrario...
::))))))) se questo è il futuro di ogni buon programmatore,
quasi quasi mi vendo il computer... ihih".
Dopo quello che hai detto in questi thread sul tuo algoritmo
di compressione, potrei dirti che puoi stare tranqullo.
Quello e' il destino dei *buoni* programmatori :)
-- 
The Follet

 evitare tuttii calcoli.... ma non lo conosco...
ma guarda un po' che novita' ... ho avuto lo stesso problema per sfw di
riconoscimento di immagine, altri per riconoscimento della voce...
che il problema si chiami intelligenza?

Gordon ha letto il messaggio di "Delta Hug" <xx@xx.x>:
ma sei di coccio? 

On Sat, 20 Oct 2001 23:55:21 +0200, "MarioH" wrote:
                                    ^^^^^^^^
?????
Il nostro troll si è tradito da solo!


 Il nostro troll si č tradito da solo!
Sono stato 5 min a capire cosa intendevi... poi ho guardato con un
font a spaziatura fissa...
In pratica, aveva compresso il suo nick, poi lo ha decompresso...
MarioH č il nome di un famoso armadillo, infatti.
Ciao
("sfotti, sfotti": ebbene sě!)
--
The Secret of Tabboz Island
http://it.geocities.com/tabbozisland

MarioH è il nome di un famoso armadillo, infatti.
ROTFL


Delta Hug <xx@xx.x> wrote in message 09jA7.3347$HT2.1...@news1.tin.it...

Ho seguito questa diatriba per un pò e volevo darti un consiglio.
Secondo me, per tutto quello che hai detto, i casi sono due: ho hai preso
una cantonata
pazzesca e non te ne sei ancora accorto oppure hai avuto un'idea geniale (e
in tal caso
fai bene a non spiegare niente). Cmq sia, perchè non ti studi un pò di
Teoria dell'Informazione
così scopri perchè è IMPOSSIBILE comprimere qualsiasi sequenza di un fattore
fisso e
comprendi meglio tutte le altre critiche che ti sono state mosse?!?! In tal
modo se hai
preso una cantonato scopri qual è il problema e magari lo puoi "migliorare",
se invece hai avuto un'idea geniale auguri e bene così.
Personalmente ho un forte sospetto, ma non è che tu comprimi numeri generi
casualmente?
No, perchè in tal caso già questa è una sequenza particolare che può essere
compressa
molto meglio di altre... per curiosità prova a comprimere centinaia di
immagine diversissime tra
loro e "ricche" (cioè che non siano scacchiere o cose di questo tipo) e
vedrai che la musica
cambia. L'altro sospetto e che ti occorrono sì pochissimi numeri per
rappresentare il tutto, ma
così enormi che perdi lo stesso gran parte del tuo 50% di compressione. Sai,
anch'io una
volta avevo preso una cantonata simile pensando ad un algoritmo "lossy" (che
non è un termine
strano ma il termine che tutti coloro che lavorano nella compressione usano,
significa che
comprimi ma perdi qualcosina) che utilizzava enormi numeri per rappresentare
una serie
di operazioni, solo che alla fine non andava per niente bene come sembrava,
dipendeva
molto da cosa comprimevi.
ciao ciao

...e Dio disse: "pkunzip universo.zip"

 geometrico lasciano spazio a dubbi. Dubbi non possono esistere, invece,
sul
Estremamente probabile.
Gia' in due thread ho esposto la mia sensazione: secondo me DH si lascia
indietro qualcosa, ad esempio un o' di cifre decimali.
E' molto probabile che il suo algoritmo ricodifichi l'input e, come
risultato, ottenga da un intero un numero in virgola mobile. Peccato che,
alla fine, il numero in virgola mobile ottenuto sia esattamente uguale, come
numero di cifre significative necessarie alla decompressione, al numero
intero iniziale...
Ciaotutti,
*


E dai... Secondo me ti stai perdendo qualcosa.
Ti ho detto: prendi un file compresso da winzip, comprimilo, decomprimilo e
riaprilo con winzip: se si apre sei un genio, se non si apre hai perso cifre
per strada.
Ciaotutti,
*


l'ho già sentita questa...non era una signature del buon Laforgia?
--
Rhymes - 
rhy...@myself.com
http://www.foxhound-games.it
"Sapete cosa fa un InputStream quando
gli si racconta una barzelletta? Reader..."


Mi e' sorto un dubbio da quando ho letto che l'LZW e' un algoritmo
asintoticamente ottimo: ma se si zippa l'universo, quanto pesa il file?
Ciaotutti,
*

 asintoticamente ottimo: ma se si zippa l'universo, quanto pesa il
file?
Mah... se l'universo è infinito... fai ratio 60%... infinito!
Questo è l'unico caso in cui l'algoritmo di Mario/Ugo/Delta/etc...
avrebbe potuto comprimere veramente ogni volta allo stesso modo. :)
Piuttosto c'è da chiedersi cosa sarebbe successo se avesse usato un
algoritmo lossy...


 molto meglio di altre...
Uh? Questa mi e` nuova. Una sequenza casuale di numeri e` per definizione
priva di ridondanza...
--
Bye! Lorenzo Lutti

> 
*> Mi e' sorto un dubbio da quando ho letto che l'LZW e' un algoritmo
*> asintoticamente ottimo: ma se si zippa l'universo, quanto pesa il file?
Niente. Il _peso_ č zero.
--
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 )

 priva di ridondanza...
Una sequenza di numeri casuali generati dal PC è pseudo casuale...ed è
quindi rappresentabile dall'algoritmo che li genera  e dalle condizioni
iniziali di generazione...
Ciao
        Riccardo

priva di ridondanza...
...o quasi...
-- 
The Follet

Lorenzo Lutti <lorenz...@DOHtiscalinet.it> wrote in message
gXXA7.73802$1H1.7...@news.infostrada.it...

No. O meglio forse mi sono spiegato male. Intendevo dire che a meno di
scriversi un
generatore di numeri VERAMENTE casuali, se si usano le classiche routine
(tipo rand() per
intendersi) per generare i numeri casuali questi, non solo sono
pseudo-casuali, ossia partano
da un seme e poi sono deterministici, ma in più queste routine tendono a
fornire numeri
con una distribuzione uniforme (se non erro). Ribadisco che secondo me per
testare un
qualsiasi compressore "fai-da-te" è opportuno prelevare sequenze di bit da
qualche parte.
Qualcuno aveva suggerito di usare i bit di un file già zippato, mi sembra
una buona
idea così la ridondanza è già stata tolta.
Cmq, noto che questa discussione per un verso o per l'altro appassiona un
bel pò !!
Ciao ciao

bel pò !!
Bhé quando dio disse "pkunzip universo.zip" perché scompatto anche i
troll?
Mi vengono in mente solo 2 soluzioni
1 - ha commesso un grande errore
2 - aveva capito che senza troll non ci si diverte



Interessante :)
Certo e' che quando diventano troppi fanno danni...
Ciaotutti,
*


Di' la verita', sei laureato in fisica :)
Ciaotutti,
*


Ma sei certo che non l'abbia fatto? :P
Ciaotutti,
*

 writes:
MB> Bhé quando dio disse "pkunzip universo.zip" 
Nooo, disse :
cat universo.tar.Z | compress -d -c | tar -xf -


 cat universo.tar.Z | compress -d -c | tar -xf -
Ecco perchè al 7o girono si dovette riposare (le dita).
8-PPP
-- 
Luc.

> cat universo.tar.Z | compress -d -c | tar -xf -
L> Ecco perchè al 7o girono si dovette riposare (le dita).
Carina questa!!!!!


> 
*> Di' la verita', sei laureato in fisica :)
:) :)
No sono un ingegnere, il dipartimento di fisica č stato il mio incubo :) :)


 Ma sei certo che non l'abbia fatto? :P
Questo risponderebbe alla domanda "Perché ha scompattato anche i
troll?".
Ciao
--
Che mondo sarebbe senza troll?


 wrote in[...]
 ^^^^^^
Avrei dovuto capirlo subito! i punti di sospensione... gli smiley con 
gli occhi multipli... la fissazione per il FORTRAN... il recente 
interesse per la compressione dati... VB 3... tutte le prove portavano a 
te, che altri non sei che Stanislao Moulinski!!!

: 
[...]
MarioH, ma ci facci il piacere, ci facci... che l'ultima volta che ti 
sei interessato alla compressione dati credevi si facesse con lo XOR :)

 sei interessato alla compressione dati credevi si facesse con lo XOR :)
Di certo ha movimentato il NG.....
Ha generato decine (per non dire centinaia) di risposte.....
Insomma, ha raggiunto il suo scopo, prenderci per il c**o (almeno per un po'
di tempo)

controlli di CRC che consentono di scoprire subito eventuali errori.
Meglio RAR. Che cambia algoritmo in base al tipo di dati, che ha il 
controllo di ridondanza e il mitico record di ripristino

Ha generato decine (per non dire centinaia) di risposte.....
Avrei potuto fermarlo subito, se solo avessi fatto più attenzione :) Non 
ha nemmeno provato a fingersi qualcun altro, ha semplicemente cambiato 
nome. Vedi il mio messaggio da queste parti che spiega perchè sono stato 
un vero pirlengo a non riconoscerlo subito

Ecco perchè al 7o girono si dovette riposare (le dita).
tra l'altro è ridondante, non capisco questa strana passione per i gatti 
che ha certa gente. E comunque non bastava tar -xzf universo.tar.Z? o 
funziona solo con gzip?

> Ecco perchè al 7o girono si dovette riposare (le dita).
K:H> tra l'altro è ridondante, non capisco questa strana passione per i gatti 
K:H> che ha certa gente. E comunque non bastava tar -xzf universo.tar.Z? o 
K:H> funziona solo con gzip?
La seconda che  hai detto (bastava leggere il man).   E non solo. Solo
il tar della GNU ha la decompressione "builtin" e solo per gzip e bz2.
Ancora adesso se qualcuno usa il vetusto compress (basato su LZW) deve
fare la decompressione separatamente.
Il cat deriva  dal fatto che a volte ti trovi  (trovavi, sono cose che
come ftp e soci ho cominciato ad  usare passa 10 anni fa) i vari pezzi
di un file fatto a fette da split e quindi la linea diventa
cat xaa xab ... | compress -dc | tar -xf -



Basta il comando test, WinZip usa un CRC per ogni file, e' estremamente
difficile che un file zip corrotto possa passare per integro.
Ciaotutti,
*

 controllo di ridondanza e il mitico record di ripristino
Ma funziona? Il recovery record, dico...
Ciaotutti,
*

 iniziali di generazione...
Certamente, ma dato che esistono infiniti algoritmi di generazione, non e`
possibile (in generale) determinare tali dati partendo dalla sequenza
pseudocasuale... che poi molte implementazioni della rand (o chi per lei) si
basino su algoritmi molto simili e quindi in questi sia possibile farlo, non
significa che lo sia in generale.
--
Bye! Lorenzo Lutti

 l'altro appassiona un bel pò !!
Beh, cio` che diceva Delta Hug era talmente enorme che era un po' difficile
ignorarlo... :)
--
Bye! Lorenzo Lutti

 troll?
Secondo le teorie fisiche più accreditate l'universo era un punto privo
di dimensioni, poi c'è stato il big bang. prima del big bang c'è stato
un big crunch, dove tutta la massa dell'universo si è concentrata in un
punto.
Sostenere che un algoritmo può essere applicato un numero arbitrario di
volte ottenendo sempre un risultato ha un risvolto mistico.
Speculare su questo algoritmo significa speculare su dio.
Possederlo significa "essere" dio.
Soprattutto: non usate algoritmi lossy per comprimere l'universo, o la
prossima volta questo pianeta sembrerà un immagine quadrettizzata da due
soldi !!
perdono,
Giacomo

> iniziali di generazione...
LL> Certamente, ma dato che esistono infiniti algoritmi di generazione, non e`
                                     ^^^^^^^^
Non ne  sarei così  certo. Di sicuro  non si  fa un buon  algoritmo di
generazione  dei  numeri  casuali  facendo  "le  cose  a  caso"  (Vedi
algoritmo K di Knuth).


: 

Non recupera i dati persi, ma almeno rende l'archivio leggibile, e 
permette di recuperare tutti gli altri file, anche in un archivio 
"solido". E' solo che ci mette una vita a calcolarlo, soprattutto con 
archivi molto voluminosi

 Non ne  sarei così  certo.
Sommando due sequenze pseudocasuali non correlate, si ottiene una nuova
sequenza pseudocasuale (cambia il valor medio e forse la varianza, ma non
importa). Per cui se hai un algoritmo di generazione che parte da N semi e
ti genera una sequenza A0(n), puoi definire un nuovo algoritmo
A1(n,m) = A0(n)+A0(m)
ed esso partira` da N*N semi. E cosi` via (teoricamente puoi iterare il
procedimento per un numero infinito di volte). Onestamente non so se sia
possibile (teoricamente e/o praticamente) riuscire a trovare tutti i semi di
un algoritmo di generazione cosi` fatto, anche conoscendo perfettamente
l'algoritmo A0...
--
Bye! Lorenzo Lutti

 archivi molto voluminosi
Io con pkzipfix in genere riesco a recuperare zip troncati, su quelli
corrotti non ho mai provato...
Ciaotutti,
*

 corrotti non ho mai provato...
Anche i file zippati sono corrotti? Ommamma... almeno loro potevano
salvarsi... e allora chi non è corrotto oggi? ;^)

 caso"
Altrimenti si potrebbe sempre adottare questa filosofia:
http://www.comics.com/comics/dilbert/archive/images/dilbert2001182781025.gif
--
Bye! Lorenzo Lutti

>>>> "LL" == Lorenzo Lutti <lorenz...@DOHtiscalinet.it> writes:
LL> Altrimenti si potrebbe sempre adottare questa filosofia:
LL> 
http://www.comics.com/comics/dilbert/archive/images/dilbert2001182781025.gif
:) :) :)
