From: Anonymous CowardHet idee is om een veld van X*Y te vullen met bytes. Door deze velden per rij, kolom en de 2 diagonaal richtingen op te tellen komt er een waarde uit welke kleiner is (byte wise) dan de originele reeks. met 32bit (4byte) kan je tot 16,...miljoen tellen. om daar te komen met het op tellen van een reeks bytes kan je met een gerust hart een veld van 1024*1024 maken.
Als voorbeeld.. 8 bits leverdt max 255 (decimaal)op. 2 bytes opgeteld leverdt 510 en dat past in 9 bit. in 10 bit past 4byte. enz.
Ivm magische vierkanten kan je ipv een vierkant veld ook een rechthoekig veld opgeven, scheeld iets.
dus in een veld van 256*256 bytes gaat die 65K aan data in. en komt er 4096byte uit. (256*4richtingen)*4byte. ok. had ik dus een klein rekenfoutje in excel.. met overhead ff over de 5KB.
Ah ok. Stel ik neem een bestand van 16 bytes als voorbeeld. Dan zou ik die 16 bytes in een vierkant van 4 bij 4 moeten zetten. De rijen, kolommen en diagonallen tel ik dan op. En die 10 waardes (4 rijen, 4 kolommen en 2 diagonalen) sla ik dan op?
De som van 4 bytes past in 10 bits. Dus mijn originele bestand was 16*8 = 128 bits en packed gaat dat dus naar 10*10=100 bits. En 100 is minder dan 128 dus we hebben het ingepakt. Dat is voor een bestand van 16 bytes. Voor grotere bestanden is de ratio veel hoger, dat snap ik.
Het probleem is dat er in die 100 bits die je opslaat niet genoeg informatie aanwezig is om de originele 128 bits terug te krijgen. Er zijn 2^100 bestanden van 100 bits en 2^128 bestanden van 128 bits. Het is dus onvermijdelijk, helaas, dat er meerdere 128 bits bestanden verwijzen naar hetzelfde packed bestand van 100 bits.
Laat ik een weinig origineel voorbeeld geven. Beschouw het volgende bestand van 16 bytes:
1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16
Niet bijster origineel en even gewoon in decimale notatie opgeschreven voor het gemak. Deze zet ik dan dus zo in een vierkant:
1 2 3 4
5 6 7 8
9 10 11 12
13 14 15 16
De rijen optellen geeft: 10, 26, 42 en 58. De kolommen optellen geeft: 28, 32 36 en 40. Voor beide diagonalen krijg ik dan 34.
De compressie verloopt dus als volgt:
1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16 -> 10-26-42-58-28-32-36-40-34-34
Dat ziet er nog allemaal goed uit toch?
Nu een ander voorbeeld. Een ander bestand van 16 bytes:
2-3-2-3-4-5-8-9-9-10-11-12-13-14-15-16
Krijgen we dit vierkant:
2 3 2 3
4 5 8 9
9 10 11 12
13 14 15 16
De rijen optellen geeft: 10, 26, 42 en 58. De kolommen optellen geeft: 28, 32 36 en 40. Voor beide diagonalen krijg ik dan 34. Valt je iets op:
2-3-2-3-4-5-8-9-9-10-11-12-13-14-15-16 -> 10-26-42-58-28-32-36-40-34-34
Nog een voorbeeld:
3-4-1-2-3-4-9-10-9-10-11-12-13-14-15-16 -> 10-26-42-58-28-32-36-40-34-34
Dit is het grote probleem van jouw methode. Een bepaald packed bestand kun je op meerdere manieren uitpakken. Dit probleem gaat niet alleen voor jouw methode op, het is fundamenteel. En onoplosbaar. Het is dezelfde getalsmatige realiteit waar Sloot tegenaan was gelopen.
Omdat ik op byte nivo werk maakt het eigenlijk niet uit wat voor data er in het in te pakken bestand staat. En je verwerkt net zo veel velden als nodig is om het gehele bestand ingelezen te hebben. Hierbij zal in het laatste veld een deel gevuld worden met 0 als waarde.Daar je de uitkomsten e.d. ook weer als bytes kan inlezen kan je het resultaat van de eerste verwerkings ronde nog (meer) maals inlezen en inpakken.
Dan zou jouw methode nog beter zijn dan die van sloot. Je begint met een film van tig gigabyte, die zet je in een heel groot vierkant. Het packed bestand zet je in een kleiner vierkant en zo verder net zolang totdat je bij een 4x4 vierkant uitkomt. Dat zou je een hele film in 100 bits kunnen comprimeren. Jammer dat het niet werkt, anders waren die miljarden die Pieper aan het eind van de regenboog zag nu voor jou geweest...
beetje als een zip in een zip in een zip bestand, waarbij het bij zip niet kleiner wordt maar hier het resultaat wel.
Het uitpakken doe je (brute force) door de resultaat waardes langs de kanten van het veld te zetten en dan het veld net zo lang invullen/muteren tot je bij het optellen van de velden op de resultaten komt.
Hehe nu snap ik dat het uitpakken van het bestand zo lang moet duren. Als een bestand, dat origineel zeg 1 gb was, zou willen uitpakken moet je alle bestanden van 1 gb gaan aflopen. Dat hoeft niet met brute-force, je kunt veel sneller een origineel vinden. Het grote probleem is dat je dus een heleboel originelen zult vinden.