Newsgroup: it.discussioni.ingegneria
Titolo: secondo voi...

un algoritmo che comprime dal 25% in su qualsiasi file
(senza perdite ovviamente,anche un rar zip o un jpg avi etc)
può avere qualche tipo di "successo"
oppure è qualcosa nella norma di tutti gli algoritimi
gia inventati?
Esistono delle tabelle comparative sulla "compressione"? 

 un algoritmo che comprime dal 25% in su qualsiasi file
Comprimendo ad esempio un MP3 riesci ad ottenere minimo il 25% di 
compressione?
Ottimo direi (anche se la vedo alquanto dura :-)!
Ho fatto una prova al volo con un mp3 di 4.22MB:
Con Winrar (compressione migliore) ottengo 2% di compressione.
Con Winzip ottengo poco piů di 1% di compressione.
Se il tuo algoritmo riesce ad ottenere minimo il 25%.... bhe complimenti :-) 


Non che sia un'esperto ma un 25% di compressione (senza perdita di
dati) in file già compressi o comunque derivanti da elaborazione
numerica del file (immagini .jpg, file audio .mp3) credo sia
impossibile. Inoltre se l'algoritmo garantisce sempre un minimo di un
25% di compressione applicandolo ricorsivamente si arriva all'assurdo
di comprire fino a dimensioni infinitesime...

di comprire fino a dimensioni infinitesime...
non proprio...tende ad avere dimensioni... infinite...
se provo a ricomprimere un file compresso secondo
questo algoritimo il nuovo file compresso rimane della stessa dimensione
(o spesso aumenta...) 

 ha scritto nel messaggio 
news:%%Qpk.19626$0N.1...@tornado.fastwebnet.it...

bč... comprimere comprime di tutto almeno 25%...il problema
č il tempo...non sono un esperto programmatore...devo ottimizzare
molti aspetti..inoltre non riesco a compilare per sfruttare il multicore...

 multicore...
Mah...
nutro profondi dubbi, cmq a parte il tempo....prova a comprimere un piccolo 
file MP3 e vedi se realmente raggiungi quella compressione!
Ciao 

 Ciao
si sempre...(ovviamente con tutti i "sospetti" del caso perche è in fase
embrionale errori di valutazione ci sono sempre)...
piuttosto... mi servirebbe poter "giocare" con gli array
dallo stesso indice ho due valori che sono legati tra loro
n->array1(n)
n->array2(n)
io dovrei riuscire a ordinare array2(n) preservando
l'ordine in array1(n) ...
per oggi basta va... 

 (o spesso aumenta...) 
Questo è l'assurdo dato che tu hai premesso che comprime del 25% 
qualsiasi file.


Anche se più sopra hai detto che comprime qualsiasi file, la cosa ci può
stare. Se da un file estrai le informazioni e le riarrangi in maniera
ottimale, è pacifico che alla seconda iterazioni le cose non cambino di
molto.
Ma puoi dirci, in sintesi, come funziona questo algoritmo? L'hai messo in
piedi tutto da solo?
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 ha scritto nel messaggio 
news:suppanews-DF7E3...@nntp.aioe.org...

eccetto quelli creati dal programma stesso 

 piedi tutto da solo?
si 

 può avere qualche tipo di "successo"
Sicurmanente porta un enorme successo a chi l'ha scritto , che
dimostra cosi  di essere uno dei migliori
matematici del pianeta.

 l'ordine in array1(n) ...
???
Prova a spiegare meglio.


Fammi capire, l'hai fatto da solo e non sai ordinare un array?
Puoi descriverlo, quest'algoritmo?


Puoi descriverlo, quest'algoritmo?
E l'ipotesi che si tratti di un troll ferragostano non la valuti?

 per oggi basta va...
Basta che ri-indicizzi n definiendo un array di indici k(n) ordinato
opportunamente, tale che l'array
n->array2(k(n))
risulti ordinato.
Allora, come funziona sto algoritmo?


On 18 Ago, 00:03, 
p4...@libero.it
 (P4W) wrote:

Secondo me si basa su una tabella hash prematurata, come se fosse
antani o in due o in quattro.
Poi mi sbaglierò...

 antani o in due o in quattro.
Intenda come ispettore tombale della supercazzola?

> Prova a spiegare meglio.
allora ho per esempio il valore n=12
è associato un valore che so A(12)=200 nell array1
e contemporaneamente B(12)=23 nell array2:
volevo ordinare i valori in B in modo che per esempio
n=0 A(0)=13 B(0)=32
n=1 A(1)=44 B(1)=22
n=2 A(2)=33 B(2)=56
.. .. .. ..
ordino B però voglio che rimanga "associata" anche A
n=0 B(0)=22   -> A(0)=44
n=1 B(1)=32   -> A(1)=13
n=2 B(2)=56   -> A(2)=33
.. .. ..

Poi mi sbaglierò...
che significa? 

 Puoi descriverlo, quest'algoritmo?
per ora ... diciamo che funziona cosi:
prendi un sacco di grano (il file)
macini i chicchi
separi la crusca dalla farina
insacchetti i due materiali ottenuti 

> E l'ipotesi che si tratti di un troll ferragostano non la valuti?
...hehe il caldo spesso da alla testa in effetti...

 ha scritto nel messaggio 
news:48a929f9$0$40304$4faf...@reader5.news.tin.it...

senza contare che la supercazzora brematurata ha perso i contatti col 
tarapio tapioco 

 ordino B però voglio che rimanga "associata" anche A
Non spieghi quale sia il problema, da quello che scrivi è chiaro che 
nell'ordinamento quando ti trovi a spostare l'elemento i-esimo devi 
spostare sia quello associato da B() che da A().
La tua struttura dati è un array di coppie non i singoli array1 e array2.

> La tua struttura dati è un array di coppie non i singoli array1 e array2.
ovvio...solo che non so implementare (per ora) il codice 

 tarapio tapioco
ahaah h 

 che la supercazzora 
Ah, un purista...

 un algoritmo che comprime dal 25% in su qualsiasi file
A comprimere puoi comprimere anche 99,99%. Ma quando decomprimi che ti 
restituisce?
--
Fabrizio

 un algoritmo che comprime dal 25% in su qualsiasi file
Confrontalo con il formato 7z, il migliore oggi disponibile. In fondo 
alla Home trovi anche una tabella comparativa: 
http://www.7-zip.org/
--
Fabrizio

 può avere qualche tipo di "successo"
Sarebbe da Nobel.
--
Fabrizio

 ha scritto nel messaggio 
news:48a9a021$0$26141$5fc...@news.tiscali.it...

un file...diciamo puro cui però dovrò aggiugere intorno a 2KB di info 
supplementari

> restituisce?
 ah ho sbagliato a leggere la domanda...
mi restituisce il file originale ovviamente...
i 2K di info x ora rimangono nel programma 

 mi restituisce il file originale ovviamente...
Ovviamente mica tanto. Se e' come scrivi sei ricco.
--
Fabrizio

 Ovviamente mica tanto. Se e' come scrivi sei ricco.
si  ma " se funziona " tutto come deve...
ho il grosso limite del tempo... per 512KB siamo
nell ordine dei minuti...almeno per ora. 

 
La lentezza non inficia l'eccezionalita' concettuale della tua
produzione intellettuale, perche' di questo si tratta.
Sempreche' funzioni davvero. Non hai ancora prodotto una prova e tu lo
sai quanto noi ingegneri siamo scettici :-)
--
Fabrizio

 insacchetti i due materiali ottenuti
Ma nei file ottenuti č preservata l'informazione? Non č che butti via la
farina e tieni la crusca?



Nel senso che la decompressione la devi fare per forza usando lo stesso
eseguibile che ha prodotto il file compresso? Cioè se uno vuole
scompattarsi il tuo archivio deve usare per forza il tuo exe?
Un exe che più lo usi per comprimere file e più si ingrossa? :-)
Ciao, Alessandro
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 farina e tieni la crusca?
assolutamente no...niente è perduto...sono tutte operazioni biunivoche
diciamo cosi (almeno fin ora) 

 ha scritto nel messaggio 
news:48a9aeb4$0$26140$5fc...@news.tiscali.it...

datemi ... TEMPO... man mano che si va avanti si trovano sempre
nuovi elementi di cui nn si tiene conto 

 Un exe che piů lo usi per comprimere file e piů si ingrossa? :-)
piu lo usi e piu si ingrossa... sdakjdasjl
no praticamente nella stessa finestra win ho messo sia la parte
compressione che decompressione gli elementi che uso
come "alfabeto" e informazioni per la compressione le riuso senza
salvarle nel file... 


Ipotesi:
1- Tu mi passi il tuo exe che comprime/decomprime;
2- Tu prendi un file qualsiasi e lo comprimi con il tuo pgm;
3- Mi passi il file compresso che è uscito;
Domanda, io posso usare l'exe che mi hai girato al punto 1 per
decomprimere il file che mi hai dato al punto 3, oppure la tua
compressione del punto 2 ha aggiunto qualcosa al tuo exe che io non ho e
quindi mi attacco?


 quindi mi attacco?
no all exe nn aggiunge niente c'è un array che cambia di volta in volta
di circa 2k piu altre poche decine di bytes con altre info
...per ora sto solo facendo prove non cè una vera interfaccia alla winzip
per dire... anzi ogni sotto-operazione è cronometrata (dal programma stesso)
e viene avviata manualmente...ogni variabile di interesse viene printata
per vedere se ci sono risultati inaspettati...sono proprio all inizio 
inizio. 

 e contemporaneamente B(12)=23 nell array2:
I dettagli continuano a sfuggirmi, ma il metodo è il seguente.
Fai un terzo array dove c(1)=1 , c(2)= 2 :  inizialmente "punta"
all'array non ordinato.
Indi lavori ( con l'algoritmo che ti pare, ma un black-red tree
sarebbe la morte sua) passando per c:
se vuoi invertire  A(3) e A(1) fai c(3)=1 c(1)=3
I  tuoi A e B rimangono come mamma li ha fatti,
ma tramite c()  hai  l'ordinamento n-->A(c(n)) : 3-->A(c(3))= A(1)
C è quel che si chiama tabella di hash prematurata, o array di
puntatori tapiochi.

puntatori tapiochi.
non mi sono messo a scrivere il codice,
diciamo che ho bypassato il problema, ma...voglio  cmq capire
perche mi potrebbe permettere di "predire" tra l'altro
la grandezza del file.
allora mettiamo che ho : n=0,1,2,3
A(0)=101  B(0)=43
A(1)=245  B(1)=355
A(2)=101  B(2)=130
A(3)=234  B(3)=43
creo:
C(0)=0
C(1)=1
C(2)=2
C(3)=3
inizialmente continua a essere
A(C(0))=101
A(C(1))=245
...etc
mettiamo caso che io voglio ordinare A
avrei:
A(0)=101             C(0)=0           B(0)=43
A(1)=101            C(1)=2            B(1)=130
A(2)=234            C(2)=3            B(2)=43
A(3)=245            C(3)=1            B(3)=355
quindi mi basta ordinare A (o una sua copia) e riuscire a salvare
l'indice in C ... bell idea

 diciamo che ho bypassato il problema,
Ahhh Antonios Antonios.... prima hai detto di aver fatto tutto da solo.
E adesso vengono fuori gli altarini....


 E adesso vengono fuori gli altarini....
no compriendo