#41
Nyugi, úgy értettem ahogy mondtam.
És gyakorlatilag annyira optimalizálatlanok most még a kódjaim,hogy optimalizálva, kb 60-80 szor lenne majd gyorsabb.
Gyakorlatilag a könnyebb kezelhetőség érdekében, minden bájtot, amiben 8 bit van, felbontok 8 bájtra, minden bájt egy bitet szimbolizál. Szóval kurvára nem érdekel most még a time hatékony kód.
De a könnyű módosítás, gyors kódírás az igen.
Amit optimalizálok az az algoritmus.
Úgy indult fél éve, hogy csináltam egy algoritmust ami kb 3-8 % al csökkenti az adatok méretét. Aztán rájöttem hogy ez lehet magasabb is, azóta sokszor változott már gyökeresen az algoritmus, és minden változtatás után jobban megértettem a háttérben meglévő elveket ami működőképessé teszi a dolgot, majd arra alapozva frissítettem megint az algoritmust.
Sokszor gyökeresen más algoritmusokat eredményezett egy egy új tényező beleszámolása, ami közösek maradtak, azok a kód felbontása több nem egyenértékű együtthatókra. Amik csak közösen tudják vissza reprodukálni az eredeti kódot.
Nagyon fontos a szimbólumok statisztikai valószínűsége is, fix táblákkal kell dolgozni, amiket nagyon be kell optimalizálni. Már 2 hónapja ezzel tökölök.
Egy nagyon egyszerű példát mondok, miért lehet megírni működőképesre egy ilyen programot. Igaz,hogy nagyon proci tabáló egy dolog, de működik.
Mondjuk ha feldobok egy érmét 100 szor, matematikailag az lesz a legvalószínűbb hogy 50 X fej, és 50 X írás. Ezek nagyjából helyesek is, egy kis hibahatáron belül. Ha veszel egy adatfolyamot, és mintákat veszel belőlle véletlen időközönként akkor 100 bitből, kb 50 egyes lesz és 50 nulla. Kis hibatűréssel. Mint a pénz feldobásoknál.
Na.. szépen elkezdem dobálni a pénzt, feldobom tízszer, amiből 7 szer fej lesz, és csak 3 szor írás. Ebből már én tudom, hogy a következő dobásnál az írásnak nagyobb lesz az esélye ha a statisztikánál maradunk. És így már egy ilyen helyzetre optimalizált elkódolással létrejön egy olyan állapot ami ahoz vezet hogy kevesebb információt használunk az adatok letárolásához.
Persze csak akkor ha bekövetkezik az előre jelzés, a "jóslás" ha a "feldobott pénz ÍRÁS lesz akkor sikerült tömöríteni az adott helyen, de ha nem jöb be a jóslás akkor viszont sajnos többlet adatot halmozunk fel a leírókódban.
Aki egy kicsit jártas a tömörítésben az tudja hogy egy adott bit hosszúságú értékben, bizonyos szimbólumok leírásakor csak akkor tudunk tömöríteni "kevesebb bittel leírni adott szimbólumokat" ha más szimbólumok leírásához többlet biteket teszünk. Mint a huffman kódolásban.
A 8 bites bájtokat alapul véve, a leggyakoribb, a leggtöbbször előforduló szimbólumokat kevesebb mint 8 biten tárolja, de viszont cserébe a legkevesebbszer előfurduló szimbólumokat kénytelen TÖBB mint 8 biten letárolni. De ez nem baj, mert így is elérhető egy 30-40 % os ráta, ha kellően van redundancia a kódban.
Na szóval, ha a pénz feldobásnál beigazolódik a "jóslat" azaz a matematikai statisztikai előre jelzés, bekövetkezhet a tömörítés, ha mégsem, akkor adat többletet halmozunk fel. De mivel statisztikailag az előre jelzések 100 esetből több mint 50-szer igazak, ezért a teljes adatállományra levetítve, többször történik tömörebb adatleírás, mint adatfelhalmozás, ezért a végén kisebb adatméretet fogunk kapni. Egyértelmű nem? Ez a gyakorlatban működik.
De már nem 3-8 % os hatásfokkal, hanem 20 % körüli most az érték. De ez már jó is. És ez az eljárás nem érzékeny az adatok entrópiájára.
Csak az a lényeg, hogy az egyesek és nullák összege a kódban, legyen mindig közel ugyan annyi, ami 99%-osan be is következik.
#41