Jaki tu wymyśleć indeks do oznaczenia kompresorów?

[Reiter]

Po pierwsze, to cześć.
Szukam mądrej głowy, która pomoże rozwikłać problem.
Potrzebuję znaleźć matematyczny wzór na obliczenie indeksu kompresora, który pozwoliłby uhierarchować go pośród innych.
Do dyspozycji mam zmienne:
x- wielkość pliku wej. w Bajtach,
y- wielkość pliku wyj. (skompresowanego) w Bajtach ( założ. y < x )
t- czas kompresji w sekundach
Mogę wyliczyć Ratio kompresji w %, szybkość kompresji ( Bajtów / sek. ).

Coś, co pozwoli mi zrobić korelację czasu kompresji z osiągniętą długością pliku wynikowego, żeby udało się stwierdzić grupę efektywnych kompresorów z całej plejady wielu.

Miałem pomysł, żeby to było
Indeks = (rozmiar wyjsciowy * czas kompresji) / rozmiar wejsciowy
ale to chyba błędne rozwiązanie.

Jakieś pomysły?

[snerg]

Co prawda wieki temu taką matmą się zajmowałem ale wydaje mi się że w tym przypadku wystarczy:

Index = rozm wyj / rozm wej * czas

Będzie to zgrubne i uproszczone indexowanie lecz dla OKREŚLONEJ PRÓBKI powinno działać.

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 widać czas gra w tym przypadku nieco większą rolę niż stopień kompresji.. Walnij w EXCEL i będziesz miał czarno na białym.

Łokej tyle wymyśliłem po 4 browarkach

[skull]

Co prawda wieki temu taką matmą się zajmowałem ale wydaje mi się że w tym przypadku wystarczy:

Index = rozm wyj / rozm wej * czas

Będzie to zgrubne i uproszczone indexowanie lecz dla OKREŚLONEJ PRÓBKI powinno działać.

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 widać czas gra w tym przypadku nieco większą rolę niż stopień kompresji.. Walnij w EXCEL i będziesz miał czarno na białym.

Łokej tyle wymyśliłem po 4 browarkach

też bym tak to zmienił: rozm_wyj/rozm_wej - to właśnie "procent kompresji"

[Nitro]

Mała rada, proponuje zamiast czasu kompresji wstawiać do wzoru prędkość dekompresji.
Ja bym z chęcią poczekał nawet z dzień na skompresowanie 60kb, do 1kb i uważałbym taki kompresor za ósmy cud świata

[snerg]

Mała rada, proponuje zamiast czasu kompresji wstawiać do wzoru prędkość dekompresji.
Ja bym z chęcią poczekał nawet z dzień na skompresowanie 60kb, do 1kb i uważałbym taki kompresor za ósmy cud świata

O kompresji to juz gadalismy - cudow nie ma

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

[Reiter]

Mała rada, proponuje zamiast czasu kompresji wstawiać do wzoru prędkość dekompresji.
Ja bym z chęcią poczekał nawet z dzień na skompresowanie 60kb, do 1kb i uważałbym taki kompresor za ósmy cud świata

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]

[quote="snerg"]
Jak widać czas gra w tym przypadku nieco większą rolę niż stopień kompresji.. [quote]

To może obniżyć wagę czasu poprzez wymnożenie go poprzez np. 0,5?

[Jacek31]

Hm.. ciekawy temat, ale trochę dziwny jak dla mnie, bo czas kompresji (wydajność) zależy od wielu czynników takich jak zawartość pliku, algorytm kompresji, wydajność CPU, szybkość komunikacji z nośnikiem danych.
Reasumując, jeżeli ten sam plik na tym samym sprzęcie skompresujesz 10 różnymi algorytmami, to jedynym czynnikiem określającym wydajność jest tylko czas.
Chyba że zależy ci na rozmiarze, ale wtedy czas już jest mniej istotny, określa co najwyżej czy warto iść robić kawę czy nie.
Nie bardzo wiem do czego chcesz ten wzór, bo dla różnych plików(rozmiar, zawartość) i tak otrzymasz niemiarodajne wyniki.
Tak naprawdę ten wzór daje wam jakąś wartość abstrakcyjna która określa współczynnik kompresji (roz_wej/roz_wyj) w czasie.

[k.]

po co ? aby porównać:) dlaczego? bo życie jest krótkie. Bez sensu? jest Twoja matka.

[snerg]

Ok, po kolei więc i znowu po piwku w oczekiwaniu na Adamka

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

Zarówno czas kompresji jak i dekompresji czy też jej stopień (procent) ma znaczenie. Są to parametry charakteryzujace progz pakujący w końcu tak?! Skoro tak, to wszystkie są istotne w zależności od przeznaczenia/celu w jakim się kompresora użyło. NP. Przy archiwizacji danych główną rolę odegra stopień kompresji gdyż mamy sporo danych i chcemy je sobie upchać w jak najmniejszej "przestrzeni". Może jednak być ich tyle (tych danych) że i czas kompresji będzie miał znaczenie. Przy kompresji w locie i transferze ogromnych ilości informacji np. ziemia-satelita-ziemia, czy też ziemia-sonda-ziemia chcemy spakować wszystko jak najszybciej i na superściskanie pliku czasu i mocy nie ma.. dobra nie będę się rozwodził nad tym. Frazesów prawie dość a jeśli pytasz czy ma to dla mnie znaczenie to powiem że ma np. sensie zawodowym - chyba wyczerpuję pytanie

Poza tym do różnych rzeczy i zastosowań stosuje się różne pakery (metody/algo kompresji) ale o tym wiesz więc się nie będę produkował.

To może obniżyć wagę czasu poprzez wymnożenie go poprzez np. 0,5?

Ja bym zrobil łopatologicznie. Dla każdego pakera zdjął bym wszystkie trzy w/w parametry czyli że się powtórzę bo do Adamka jeszcz chwila: czas kompresji i dekompresji oraz jej stopień. Zapodał bym teraz te wyniki w ładnych słupkach dla klientów których to będzie rajcowało. Natomiast dla mnie każdy z tych parametrów dawał by mi ~33% do oceny końcowej pakera - chyba że przy ocenie któryś z nich ma większe znaczenie ponieważ..
Co do poszczególnych parametrów, to po tych wszystkich testach dla każdego z nich będziesz mial przedział min max (np. czas kompresji najlepszy i najgorszy dla powiedzmy 50 programów). Pozwoli ci to zatem bardzo ladnie uplasować dany parametr danego kompresora w szeregu - ramce takiej no...

Kurna sam bym sobie tego prościej nie wyjaśnił lol

po co ? aby porównać dlaczego? bo życie jest krótkie. Bez sensu? jest Twoja matka.

Prawda, cała prawda i tylko prawda ;D

[Jacek31]

Oczywiście kisiel zamiast udzielić ludzkiej odpowiedzi zarzucił hasłem z piaskownicy przy bloku. Jak nie masz zamiaru gadać jak człowiek z człowiekiem to nie dyskutuj lepiej wcale.
Wracając jednak do tematu, nie analizowałem nigdy tego tak szczegółowo co prawda, ale najpierw należało by sobie zadać pytanie czy aby na pewno algorytm który 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 się tym pierwszym czy tym drugim ?
No i teraz jaki to ma wpływ na prawdziwość wyników waszych obliczeń. Ja pamiętam jeszcze z czasów WINRARa który podawał szacunkowe czasy i stopień kompresji że czasem te sugestie były lekko chybione w przypadku niektórych plików, szczególnie jak naraz kompresowało się ich dużo.
Jeden z kolegów podał tu taki przykład:

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 miarą są one tak naprawdę czasu kompresji czy jej skuteczności (upakowania) ? Pamiętajmy że użytkownik widzi tylko wynik, i nie zna danych które posłużyły do jego obliczenia, bo w przeciwnym razie nie miało by większego sensu obliczanie takiego indexu, bo wiadomo że każdego interesuje bardziej rozmiar pliku niż czas (przynajmniej większość. )
No nie wiem, dla mnie wszystkim czego bym w programie pakującym potrzebował jako danych to właśnie rozmiar pliku wynikowego i czas, wszelkiego rodzaju współczynniki czy indexy są zbędne, bo nie pomagają w żaden w sposób w wyborze pakera, i są dla mnie wartościami abstrakcyjnymi, taką średnią obliczoną dla samej średniej.
A namieszam wam jeszcze bardziej mam czas. Co teraz reprezentuje index i jaki to ma wpływ na jego wiarygodność?
NP. pl_wej 50kb
kompresor1 pl_wyj 10kb czas 10s index bedzie 2.00
kompresor2 pl_wyj 11kb czas TEŻ10s index bedzie 2.20

[Reiter]

Może podeślę link, to będzie można przeanalizować na realnych danych:
http://www.testy.filety.net/wyniki-testow.rar

[snerg]

Może podeślę link, to będzie można przeanalizować na realnych danych:
http://www.testy.filety.net/wyniki-testow.rar

Nieźle Reiter! Z tego co widzę to jest to jednak Twój projekt więc pozbieraj w całość co zostało powiedziane a sam podołasz

Poza tym skoro dotyczy to tylko pakerów na komcia, to chyba tym bardziej czas rozpakowywania może mieć dla ludzi znaczenie! A tak dla mojej ciekawości proszę zapodaj mi rozmiary plików które były kompresowane(nawet lepiej mozesz mi je podeslac - mail od lat ten sam lub see csdb).

[Jacek31]

O.. widzę włożyłeś w to wiele pracy. Szkoda że nie podałeś w tej tabeli rozmiarów pliku przed kompresją. Trochę ułatwiło by to analizę (przynajmniej dla mnie). Spróbowałem podpiąć do tego omawiany tu wzór, ale wyniki były ciekawe, otóż okazało się że na 1 miejscu nie był by wcale paker najszybszy i najmocniejszy, tylko taki który miał by najkorzystniejszą średnią. Podobnie jak zrobiłem że pomnożyłem stopień kompresji (w %) przez czas.
Reasumując moje szybkie eksperymenty z EXELem. Nie da sie bardzo stworzyć wzoru który uporządkuje ci te pakery od najlepszego do najgorszego za pomocą uniwersalnego indexu. Raczej potrzebował być jakiegoś bardziej złożonego algorytmu sortującego który posortował by taką tablicę biorąc pod uwaga rozmiar i czas.
Ogólnie lepiej chyba w artykule opublikować 2 tabele (może nawet nie tak rozbudowane) w jednej pakery wg rozmiaru pliku wynikowego, w drugiej wg. czasu operacji, a wybór zostawić już samemu użytkownikowi. Ja przynajmniej na chwile obecną nie widzę możliwości opracowania wzoru który za pomocą indexu zrobi to w sposób klarowny i jednoznaczny.

[skull]

O.. widzę włożyłeś w to wiele pracy. Szkoda że nie podałeś w tej tabeli rozmiarów pliku przed kompresją. Trochę ułatwiło by to analizę (przynajmniej dla mnie).

Na drugim arkuszu są dane plików źródłowych.

[Reiter]

Dzięki za rady, na razie krótka przerwa od tematu, po której wrócę kończyć te moje dzieło. Częściowo coś tam wdrożyłem do arkusza wyników, reszta rzeczy będzie do przemyślenia.