Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1: CommentAuthormarok
   • CommentTime11 Jul 2023

    
   Odnośnie (ogólnego tematu) kompresorów.
   
   Myślę od czasu do czasu nad kompresorem przeznaczonym wyłącznie dla plików tekstowych w zakresie standardu UTF-8.
   Chciałbym, żeby dawał możliwie najlepszy wynik kompresji i miał tą ewentualną przewagę, że z poziomu dostępu do takiego archiwum dawał się konfiguracyjnie przestawiać na różny rodzaj reprezentacji znaków narodowych (po dekompresji).
   Z możliwością przystosowania do konkretnej definicji zestawu znaków (lub zastępczo do formy znaku podobnego, jak ł do l lub L - lub także form dwuczłonowych - np. w j. niemieckim).
   
   { wtręt: Dekodowanie zn. narodowych zawsze byłoby do dwóch znaków, przy czym pierwszym mógłby być "escape", a drugim literalny poj. zastępnik - kod znaku pod zestaw; taką konieczność widzę z tego względu, że pakowanie i rozpakowywanie muszą funkcjonować na tych samych wartościach offsetu, bo nie widzę szansy na efektywne przeliczanie tych offsetów przy rozpakowywaniu. }
   
   Może nie ma to dla ogółu specjalnie sensu (użytkowego), ale z pewnych względów (zajmowania się poniekąd już czymś takim na dużo mniejszą skalę) widzę okazję żeby próbować.
   
   Na razie głównie teoretyzuję (praktycznie nic nie mam).
   
   Mam zarys teorii, jak to można wykonać, natomiast nie mam pewności, czy założenia nie są może krytycznie błędne.
   
   
   Więc tak, podstawowy zakres wartości kodowania znaków w UTF-8 wyraża się jednobajtowo. Jest on tożsamy z kodowaniem w ASCII (o czym powszechnie wiemy). Poza tym jednak widziałbym konieczność uwzględnienia następujących dodatkowych "poziomów" zakresów wartości dla znaków w standardzie UTF-8.
   
   U+0080..U+00FF Latin-1 Supplement
   U+0100..U+017F Latin Extended-A
   
   - Czy może to być założenie nazbyt ograniczające? (to jest dość podstawowe założenie takiego kompresora)
   
   
   Innym "gardłowym" założeniem jest takie, że kod 0x7F ("DEL") jest w interesujących nas tekstach UTF-8 (które można by przenosić i archiwizować) nie wykorzystywany.
   
   Wydaje mi się, że jest on w istocie "normalnie" nie używany. Ale czy na pewno?
   
   
   I tak, dzielę sobie kodowanie na następujące typy (elementy):
   - znaki literalne z podstawowej grupy ASCII (0x20-0x7E);
   - wartości kontrolne z pods. zakresu ASCII (0x00-0x1F);
   - znaki o kodowaniu wartościami dwubajtowymi (pozostałe, z zakresu U+0080..U+017F);
   - powtórzenia bajtów wcześniej zdekodowanych z inf. o offsecie;
   - (ew.) powtórzenia bajtu ostatniego (ze zdekodowanych).
   
   
   
   Jakoś to sobie rozpisałem na efektywne kodowanie, ale ostatecznie jestem zdania, że kodowanie poszczególnych "typów" elementów mogłoby się (powinno?) zmieniać w procesie kompresji. Po prostu powtórzenia po pewnym czasie (schemat) następują zbyt gęsto po sobie by początkowe założenia (jakie przyjąłem) nie okazały się nieefektywne w odpowiednio długich tekstach.
   
   Przełączenie się na inny sposób traktowania zakodowanych bitów (z poziomu dekodera) odbywać się może poprzez wykrycie (pierwszego) odpowiednio długiego odnośnika dla offsetu powtórzenia.
   
   Przy czym muszę zaznaczyć, że offset nie ma tu konkretnie ustalonej granicy (do 15-bitów).
   (Zapatrzyłem się tu w metodę kodowania offsetu z ZX0.)
   
   
   I to na tą chwilę wszystko.
2. • 2:
      
     CommentAuthorpirx
   • CommentTime13 Jul 2023

    
   nie pomogę Ci w tym zadaniu, ale natknąłem się na fajny przykład użycia kompresji:
   ->link<-
   
   w skrócie - dwa teksty są podobne, gdy po kompresji sumy wychodzi podobna długość jak kompresja pojedynczego.
   wygląda to na szybsze od odległości levenshteina a papier mówi, że wyniki ma lepsze od sieci neuronkowych :)
3. • 3:
      
     CommentAuthorjhusak
   • CommentTime13 Jul 2023

    
   Czad! Plus kompresja Jarosława Dudy i mamy odpowiedź natychmiast!
4. • 4: CommentAuthormarok
   • CommentTime25 Jul 2023 zmieniony

    
   wyciągam (6.7.23) i "archiwizuję" otrzymane rezultaty po pewnych dostosowaniach w pack2.asm ("Energy")
   zajęły mi one sporo dodatkowego miejsca (nie pisałem zbyt ergonomicznie, ale żeby tylko zadziałało)
   
   przy okazji, doszedłem do przekonania iż:
   
   pack2.asm ma linie zbędne tu: 142-148
   (istnieje analogia z pack.asm)
   
   w podsumowaniu program zlicza i zapisuje nast. wartości (do "tabelki" w pamięci na 6 stronie):
   
   - objętość danych przed spakowaniem (O, = O1 + Ok),
   - objętość danych po spakowaniu (U),
   - objętość danych elementów powtarzalnych (Ok),
   - objętość danych elementów niepowtarzalnych (O1 \ E1),
   - liczba elementów powtarzalnych (P, = P2 + Pn),
   - liczba elementów powtarzalnych tylko 2 razy (P2),
   - liczba elementów powtarzalnych >2 razy (Pn),
   - liczba elementów "pn" po "o1,p2*" ,
   - liczba elementów "pn" po "pn,p2+" ,
   - liczba elementów "pn" po "pn" .
   
   ( całkowita liczba elementów (E) = P + E1 )
   
   wyniki na wybranym pliku z zinu (po konwersji na utf-8)
   "art.utf"
   
   (to ta "tabelka")
   

   06A0: B6 01 EE C8 5A 0B 4F C5 5D 2D
   06B0: 35 1C 33 01 0C 03 09 00 01 07
   

   
   
   0,478618181818 st. kompresji (O-U)/O
   
   "obszarowo", O (rozkł. %)
   0,0331636363636 O1/O
   0,966836363637 Ok/O (k>1)
   -
   0,113309090909 P2*2/O (O2/O)
   = On (n>2)
   
   "elementarnie", E (rozkł. %)
   0,126036484245 E1
   0,873963515754 P
   =
   0,215371855129 P2
   0,658651188502 Pn
   "pn" po
   0,082668904742 "o1,p2*"
   0,146454049517 "pn,p2+"
   0,770877045741 "pn"
   
   
   stosunek proporcji E1 do P na poszczególnych etapach od początku pliku
   
   

   (lim) 00 00 00 00 00 00 00 00 01 02 04 08 10 20 35  (U)
         01 02 04 08 10 20 40 80 00 00 00 00 00 00 B6
                           15 25 27 24 42 2E 29 56 34  E1
   0620: 00 00 00 00 00 00 05 0D 25 55 A7 2D 0A 8F 60  P
   0630: 00 00 00 00 00 00 00 00 00 00 00 01 02 03 04
       0,                  4, 2, 1, 0, 0, 0, 0, 0, 0,  E1/P
       14                  2  8  0  42 39 15 08 09 04
   ogółem  E1/P = 0,144212523719
   

   
   
   czy to są dane prawidłowe tego nie wiem (mogłem się oczywiście gdzieś pomylić)
   
   wszystko to powstało bo 1) pack.asm jest odpowiednio do takich statystyk przystosowany z racji zwracania uwagi na rozmiar offsetu (i pakuje z elastycznym offsetem), 2) interesowało mnie dokładnie jak to się kształtuje z powtórzeniami czym dalej od początku pliku
   
   dla porównania podsumowanie z pakowania do zx0 ("salvador")
   spakowany plik do wielkości 0x1A62
   0,5088 st. kompresji (wyższy)
   
   

   Literals: min: 0 avg: 1 max: 53 count: 519 (0x207)
   Normal matches: 2930 rep matches: 102 EOD: 1 (0xB72; 0x66)
   Offsets: min: 1 avg: 1305 max: 13712 count: 3032 (0xBD8)
   Match lens: min: 1 avg: 4 max: 26 count: 3032
   RLE1 lens: min: 1 avg: 1 max: 2 count: 3
   RLE2 lens: none
   Safe distance: 6999 (0x1B57)