Jaki tu wymyslec indeks do oznaczenia kompresorow?

[Reiter]

Po pierwsze, to czesc.
Szukam madrej glowy, ktora pomoze rozwiklac problem.
Potrzebuje znalezc matematyczny wzor na obliczenie indeksu kompresora, ktory pozwolilby uhierarchowac go posrod innych.
Do dyspozycji mam zmienne:
x- wielkosc pliku wej. w Bajtach,
y- wielkosc pliku wyj. (skompresowanego) w Bajtach ( zaloz. y < x )
t- czas kompresji w sekundach
Moge wyliczyc Ratio kompresji w %, szybkosc kompresji ( Bajtow / sek. ).

Cos, co pozwoli mi zrobic korelacje czasu kompresji z osiagnieta dlugoscia pliku wynikowego, zeby udalo sie stwierdzic grupe efektywnych kompresorow z calej plejady wielu.

Mialem pomysl, zeby to bylo
Indeks = (rozmiar wyjsciowy * czas kompresji) / rozmiar wejsciowy
ale to chyba bledne rozwiazanie.

Jakies pomysly?

[snerg__]

Co prawda wieki temu taka matma sie zajmowalem ale wydaje mi sie ze w tym przypadku wystarczy:

Index = rozm wyj / rozm wej * czas

Bedzie to zgrubne i uproszczone indexowanie lecz dla OKRESLONEJ PROBKI powinno dzialac.

NP. pl_wej 50kb
kompresor1  pl_wyj 10kb czas 10s   index bedzie 2.00
kompresor2  pl_wyj 11kb czas 09s   index bedzie 1.98

Jak widac czas gra w tym przypadku nieco wieksza role niz stopien kompresji..  Walnij w EXCEL i bedziesz mial czarno na bialym.

Lokej tyle wymyslilem po 4 browarkach

[Skull]

                   

snerg napisal:

Co prawda wieki temu taka matma sie zajmowalem ale wydaje mi sie ze w tym przypadku wystarczy: Index = rozm wyj / rozm wej * czas Bedzie to zgrubne i uproszczone indexowanie lecz dla OKRESLONEJ PROBKI powinno dzialac. NP. pl_wej 50kb kompresor1  pl_wyj 10kb czas 10s   index bedzie 2.00 kompresor2  pl_wyj 11kb czas 09s   index bedzie 1.98 Jak widac czas gra w tym przypadku nieco wieksza role niz stopien kompresji..  Walnij w EXCEL i bedziesz mial czarno na bialym. Lokej tyle wymyslilem po 4 browarkach

tez bym tak to zmienil:  rozm_wyj/rozm_wej - to wlasnie \"procent kompresji\"

[Nitro__]

Mala rada, proponuje zamiast czasu kompresji wstawiac do wzoru predkosc dekompresji.
Ja bym z checia poczekal nawet z dzien na skompresowanie 60kb, do 1kb i uwazalbym taki kompresor za osmy cud swiata

[snerg__]

                   

Nitro napisal:

Mala rada, proponuje zamiast czasu kompresji wstawiac do wzoru predkosc dekompresji. Ja bym z checia poczekal nawet z dzien na skompresowanie 60kb, do 1kb i uwazalbym taki kompresor za osmy cud swiata

O kompresji to juz gadalismy - cudow nie ma

Czas dekompresji.. zalezy po co i jak chce sie te pakery posegregowac.

[Reiter]

                   

snerg napisal:

Nitro napisal: Mala rada, proponuje zamiast czasu kompresji wstawiac do wzoru predkosc dekompresji. Ja bym z checia poczekal nawet z dzien na skompresowanie 60kb, do 1kb i uwazalbym taki kompresor za osmy cud swiata O kompresji to juz gadalismy - cudow nie ma Czas dekompresji.. zalezy po co i jak chce sie te pakery posegregowac.

Czas dekompresji - czy to istotny parametr i w jakim sensie dla Ciebie?

[Reiter]

Jak widac czas gra w tym przypadku nieco wieksza role niz stopien kompresji..  

To moze obnizyc wage czasu poprzez wymnozenie go poprzez np. 0,5?

[Jacek31]

Hm.. ciekawy temat, ale troche dziwny jak dla mnie, bo czas kompresji (wydajnosc) zalezy od wielu czynnikow takich jak zawartosc pliku, algorytm kompresji, wydajnosc CPU, szybkosc komunikacji z nosnikiem danych.
Reasumujac, jezeli ten sam plik na tym samym sprzecie skompresujesz 10 roznymi algorytmami, to jedynym czynnikiem okreslajacym wydajnosc jest tylko czas.
Chyba ze zalezy ci na rozmiarze, ale wtedy czas juz jest mniej istotny, okresla co najwyzej czy warto isc robic kawe czy nie.
Nie bardzo wiem do czego chcesz ten wzor, bo dla roznych plikow(rozmiar, zawartosc) i tak otrzymasz niemiarodajne wyniki.
Tak naprawde ten wzor daje wam jakas wartosc abstrakcyjna ktora okresla wspolczynnik kompresji (roz_wej/roz_wyj) w czasie.

[Kisiel]

po co ? aby porownac dlaczego? bo zycie jest krotkie. Bez sensu? jest Twoja matka.

[snerg__]

Ok, po kolei wiec i znowu po piwku w oczekiwaniu na Adamka

                   

Reiter napisal:

Czas dekompresji - czy to istotny parametr i w jakim sensie dla Ciebie?

Zarowno czas kompresji jak i dekompresji czy tez jej stopien (procent) ma znaczenie. Sa to parametry charakteryzujace progz pakujacy w koncu tak?! Skoro tak, to wszystkie sa istotne w zaleznosci od przeznaczenia/celu w jakim sie kompresora uzylo. NP. Przy archiwizacji danych glowna role odegra stopien kompresji gdyz mamy sporo danych i chcemy je sobie upchac w jak najmniejszej \"przestrzeni\". Moze jednak byc ich tyle (tych danych) ze i czas kompresji bedzie mial znaczenie. Przy kompresji w locie i transferze ogromnych ilosci informacji np. ziemia-satelita-ziemia, czy tez ziemia-sonda-ziemia chcemy spakowac wszystko jak najszybciej i na supersciskanie pliku czasu i mocy nie ma.. dobra nie bede sie rozwodzil nad tym. Frazesow prawie dosc a jesli pytasz czy ma to dla mnie znaczenie to powiem ze ma np. sensie zawodowym - chyba wyczerpuje pytanie

Poza tym do roznych rzeczy i zastosowan stosuje sie rozne pakery (metody/algo kompresji) ale o tym wiesz wiec sie nie bede produkowal.

                   

Reiter napisal:

To moze obnizyc wage czasu poprzez wymnozenie go poprzez np. 0,5?

Ja bym zrobil lopatologicznie. Dla kazdego pakera zdjal bym wszystkie trzy w/w parametry czyli ze sie powtorze bo do Adamka jeszcz chwila: czas kompresji i dekompresji oraz jej stopien. Zapodal bym teraz te wyniki w ladnych slupkach dla klientow ktorych to bedzie rajcowalo. Natomiast dla mnie kazdy z tych parametrow dawal by mi ~33% do oceny koncowej pakera - chyba ze przy ocenie ktorys z nich ma wieksze znaczenie poniewaz..
Co do poszczegolnych parametrow, to po tych wszystkich testach dla kazdego z nich bedziesz mial przedzial min max (np. czas kompresji najlepszy i najgorszy dla powiedzmy 50 programow). Pozwoli ci to zatem bardzo ladnie uplasowac dany parametr danego kompresora w szeregu - ramce takiej no...

Kurna sam bym sobie tego prosciej nie wyjasnil lol

                   

kisiel napisal:

po co ? aby porownac dlaczego? bo zycie jest krotkie. Bez sensu? jest Twoja matka.

Prawda, cala prawda i tylko prawda

[Jacek31]

Oczywiscie kisiel zamiast udzielic ludzkiej odpowiedzi zarzucil haslem z piaskownicy przy bloku. Jak nie masz zamiaru gadac jak czlowiek z czlowiekiem to nie dyskutuj lepiej wcale.
Wracajac jednak do tematu, nie analizowalem nigdy tego tak szczegolowo co prawda, ale najpierw nalezalo by sobie zadac pytanie czy aby na pewno algorytm ktory kompresuje plik bardziej jest aby na pewno wolniejszy od tego z mniejszym stopniem kompresji ? Np, czy ten sam plik kompresowany LZW i Huffmanem szybciej skompresuje sie tym pierwszym czy tym drugim ?
No i teraz jaki to ma wplyw na prawdziwosc wynikow waszych obliczen. Ja pamietam jeszcze z czasow WINRARa ktory podawal szacunkowe czasy i stopien kompresji ze czasem te sugestie byly lekko chybione w przypadku niektorych plikow, szczegolnie jak naraz kompresowalo sie ich duzo.
Jeden z kolegow podal tu taki przyklad:
                   

Cytat:

NP. pl_wej 50kb kompresor1 pl_wyj 10kb czas 10s index bedzie 2.00 kompresor2 pl_wyj 11kb czas 09s index bedzie 1.98

mamy tu 2 wyniki 2.00 oraz 1.98, i teraz pytanie czego miara sa one tak naprawde czasu kompresji czy jej skutecznosci (upakowania) ? Pamietajmy ze uzytkownik widzi tylko wynik, i nie zna danych ktore posluzyly do jego obliczenia, bo w przeciwnym razie nie mialo by wiekszego sensu obliczanie takiego indexu, bo wiadomo ze kazdego interesuje bardziej rozmiar pliku niz czas (przynajmniej wiekszosc. )
No nie wiem, dla mnie wszystkim czego bym w programie pakujacym potrzebowal jako danych to wlasnie rozmiar pliku wynikowego i czas, wszelkiego rodzaju wspolczynniki czy indexy sa zbedne, bo nie pomagaja w zaden w sposob w wyborze pakera, i sa dla mnie wartosciami abstrakcyjnymi, taka srednia obliczona dla samej sredniej.
A namieszam wam jeszcze bardziej mam czas. Co teraz reprezentuje index i jaki to ma wplyw na jego wiarygodnosc?
NP. pl_wej 50kb
kompresor1 pl_wyj 10kb czas 10s index bedzie 2.00
kompresor2 pl_wyj 11kb czas TEZ10s index bedzie 2.20

[Reiter]

Moze podesle link, to bedzie mozna przeanalizowac na realnych danych:
http://www.testy.filety.net/wyniki-testow.rar

[snerg__]

                   

Reiter napisal:

Moze podesle link, to bedzie mozna przeanalizowac na realnych danych: http://www.testy.filety.net/wyniki-testow.rar

Niezle Reiter! Z tego co widze to jest to jednak Twoj projekt wiec pozbieraj w calosc co zostalo powiedziane a sam podolasz

Poza tym skoro dotyczy to tylko pakerow na komcia, to chyba tym bardziej czas rozpakowywania moze miec dla ludzi znaczenie! A tak dla mojej ciekawosci prosze zapodaj mi rozmiary plikow ktore byly kompresowane(nawet lepiej mozesz mi je podeslac - mail od lat ten sam lub see csdb).

[Jacek31]

O.. widze wlozyles w to wiele pracy. Szkoda ze nie podales w tej tabeli rozmiarow pliku przed kompresja. Troche ulatwilo by to analize (przynajmniej dla mnie). Sprobowalem podpiac do tego omawiany tu wzor, ale wyniki byly ciekawe, otoz okazalo sie ze na 1 miejscu nie byl by wcale paker najszybszy i najmocniejszy, tylko taki ktory mial by najkorzystniejsza srednia. Podobnie jak zrobilem ze pomnozylem stopien kompresji (w %) przez czas.
Reasumujac moje szybkie eksperymenty z EXELem. Nie da sie bardzo stworzyc wzoru ktory uporzadkuje ci te pakery od najlepszego do najgorszego za pomoca uniwersalnego indexu. Raczej potrzebowal byc jakiegos bardziej zlozonego algorytmu sortujacego ktory posortowal by taka tablice biorac pod uwaga rozmiar i czas.
Ogolnie lepiej chyba w artykule opublikowac 2 tabele (moze nawet nie tak rozbudowane) w jednej pakery wg rozmiaru pliku wynikowego, w drugiej wg. czasu operacji, a wybor zostawic juz samemu uzytkownikowi. Ja przynajmniej na chwile obecna nie widze mozliwosci opracowania wzoru ktory za pomoca indexu zrobi to w sposob klarowny i jednoznaczny.

[Skull]

                   

Jacek31 napisal:

O.. widze wlozyles w to wiele pracy. Szkoda ze nie podales w tej tabeli rozmiarow pliku przed kompresja. Troche ulatwilo by to analize (przynajmniej dla mnie).

Na drugim arkuszu sa dane plikow zrodlowych.