Newsgroup: it.comp.grafica.photoshop
Titolo: Deliri di Compressione ^_^ - seconda parte - Creazione dell'algoritmo: CHRIX

Cari miei.. per chi si fosse perso la prima parte di questa
interessantissima (?????) "saga", vi rimando al mio mex di ieri in reply a
"una domanda sensata ?" di non so chi....
In tale delirante scritto (che ha pure attinenza con la grafica.. dato che
qui gli algoritmi di compressione si sprecano!)  ponevo all'attenzione
dell'umanità un problema interessantissimo.. cioè la ricerca di una maniera
efficiente per elencare delle estrazioni di palline numerate.... in modo da
utilizzare per la rappresentazione della sequenza di palline estratte il
minor numero di "caselle" possibili...
Oggi torno sui vostri teleschermi con uno scritto ancora più delirante..
ON-LINE (sono le 07:43 AM di giovedì 13.01.2000) creerò per voi un vero
algoritmo di compressione adatto a codificare in maniera "NON lossy" le
estrazioni di lunghe catene di palline numerate (con su cifre da 1 a 5)
Riassumendo il mio intervento (basta applausi ^_^) di ieri, avevo presentato
due sequenze "possibili" di cifre... e 3 sistemi di compressione (due
LOSSILESS e uno LOSSY.. che mi ha però perduto circa il 50% delle
informazioni originali senza nemmeno comprimere nulla.. in una delle due
sequenze campione)
Allora le due sequenze campione di palline estratte ieri erano:
SeqA) 1,1,1,1,1,2,2,2,1,1
SeqB) 1,2,3,2,1,1,2,3,4,5
I due algoritmi di compressione presentati erano i seguenti:
A) (LOSSILESS) uso di due numeri accoppiati, di cui il primo rappresenta il
numero di cifre dello stesso tipo ripetute in sequenza.. e il secondo la
cifra stessa
B) (LOSSILESS) uso di due numeri accoppiati, di cui il primo rappresentante
la cifra iniziale di sequenze ascendenti o discendenti di numeri, il secondo
la cifra finale della stessa sequenza..
C) (LOSSY) uso di due numeri accoppiati, come all'algoritmo del PUNTO (A)..
decidendo a priori però che verranno considerate uguali (anche se non lo
sono) almeno due cifre successive...
Allora.. in base ai 3 algoritmi le sequenze di cui sopra risultavano così:
Algoritmo A/SeqA) 5,1 - 3,2 - 2,1    = compressione 40 %
Algoritmo B/SeqA) NON APPLICATO.. perchè creato solo come dimostrazione ed
inutilizzabile con tale sequenza
Algoritmo C/SeqA) 5,1 - 3,2 - 2,1    = compressione 40 % (tra l'altro.. in
questo caso.. è venuta NON LOSSY ^__^)
Algoritmo A/SeqB) NON APPLICATO.. perchè creato solo per la sequenza B
Algoritmo B/SeqB) 1,3 - 2,1 - 1,5 = compressione del 40 %
AlgoritmoC/SeqB) 2,1 - 2,3 - 2,1 - 2,2 - 2,4 = compressione ZERO e perdita
di informazione ^__^
Interessante notare, nell'ultimo esempio.. come.. a causa dell'assioma che
abbiamo imposto (considerare due cifre minimo in sequenza anche se non lo
sono) c'è stata una clamorosa perdita di metà delle informazioni
originali...
Infatti.. ricostruita dall'algoritmo di decodifica, la sequenza interpretata
sarebbe....
1,1,3,3,1,1,2,2,4,4      che è molto diversa dall'originale....
1,2,3,2,1,1,2,3,4,5      e che come si nota fa perdere la metà delle
informazioni (X = errore di ricostruzione)
1,x,3,x,1,1,2,x,4,x        quasi la metà è andata perduta ^____^
==============================
SECONDA PARTE - La creazione di un algoritmo efficiente e NON-LOSSY.. il
fantomatico... ALGORITMO CHRIX
Ecco qua che pensavo stamattina sotto la doccia (proprio vero.. quando non
si ha di meglio da fare.. si arriva agli algoritmi di compressione O______O)
Allora.. dato che nelle mie premesse le palline erano numerate da 1 a 5.. ho
deciso di abbinare ad alcune sequenze di cifre dei "codici" ..
1,1 = 01        1,2 = 02            1,3 = 03        1,4 = 04       1,5 = 05
2,1 = 06        2,2, = 07           2,3 = 08        2,4 = 09        2,5 = 10
3,1 = 11        3,2  = 12           3,3 = 13        3,4 = 14        3,5  =
15
4,1 = 16        4,2 = 17            4,3 = 18        4,4 = 19        4,5 = 20
5,1 = 21        5,2 = 22            5,3 = 23        5,4 = 24        5,5 = 25
OK.. vediamo allora come funziona praticamente questa nuova trovata (mia..
NUOVA trovata.. nel senso che 'ste cose sono usate da svariati decenni in
campo informatico ^___^)
Riecco le due sequenze di numeri campione...
SeqA) 1,1,1,1,1,2,2,2,1,1
SeqB) 1,2,3,2,1,1,2,3,4,5
ed ecco i risultati dell'applicazione dell'ALGORITMO ChriX ^__^
ChriX/A) 01,01,02,07,01    =  utilizzo di 5 caselle  per 10 cifre..
compressione del 50 % ^___^
ChriX/B) 02,12,01,08,20     = stessa compressione ^__^ l'algoritmo ChriX
comprime *SEMPRE* al 50 %
Insomma... un'altro giorno è passato ^___^
FINE DELLA SECONDA PARTE ^_____^
=======================================
(Se non verrò bannato per l'eternità dal Newsgroup potrei pure scrivere la
terza parte .... ehehe... e che scriverei ? vi domandate ? Niente ^__^
potrei codificarvi  in linguaggio simil-C o JAVASCRIPT-like l'algoritmo
CHriX....)
DISCLAIMER: se qualcuno di voi in seguito alla lettura di queste preziose
informazioni dovesse diventare programmatore di algoritmi di compressione, e
ne creasse uno rivoluzionario, potrebbe citare il suo algoritmo come
derivante dall'algoritmo CHRIX (anche nel caso ciò non fosse vero
^__________^)
Ok.. intanto il mondo ha un problema in meno oggi... con l'algoritmo ChriX
il problema delle palline estratte dalle urne è risolto ^________^
ChriS
X_X


Hai visto qui:
http://www.eetimes.com/story/OEG19991228S0028
??
io non ne sapevo niente! l'ho scoperto pochi secondi fa. Che t'abbiano
fregato l'idea? ;-)
ciao,
--
.d-ego.
d-...@NOSPAMciaoweb.it

 +AD4-
Disabilita il MIME!
-- 
Le patch per i comportamenti "devianti" di Outlook:
per Mac         
http://fly.to/risorse/
 
per Windows     
http://www.freeweb.org/computer/SourceNet/Outlook.htm
Le FAQ di it.comp.macintosh   
http://kecco.eden.it/faq/