oneindige codering
 

Ok hier komt het, er bestaat iets als een japanse puzzel.
In een japanse puzzel is het de bedoeling om een aantal vakjes in een raster in te kleuren, hiervoor krijg je aanwijzingen, namenlijk het aantal zwarte vakjes in elke colom en rij van het raster.

Ok dat is duidelijk, vat nu de zwarte vakjes op als 1 en de niet ingekleurde vakjes als 0. Wat er dus onstaat is wat ik voor het gemak een "bitmap" noem, letterlijk genomen is dit het ook.

Maargoed, de "sleutel" voor deze puzzel is dus de getallen die naast en boven de puzzel staan.

laten we uit gaan van een puzzel van 32x32 vakjes.
de maximale waarde bij een rij of colom zal dus 32 zijn, dit is binair vertaalt dus maximaal 5 bits (10000)

De sleutel bestaat dan uit 32 * 2 * 5 = 320 bits
Het raster word gevuld met 32 * 32 = 1024 bits

Afijn, de output bevat 3,2 maal zoveel bits.

Wat als je nou in dit eerste raster 3 nieuwe sleutels stopt?
En daarin weer 3 sleutels, je blijft dit uitpakken todat je tegen de computer zegt "ok, na deze keer moet je alle output als bruikbare informatie opslaan"

Een ander idee is dat je in het gecreerde bitmap 1 nieuwe sleutel stopt en de rest van de informatie opslaat of laat zien op een monitor, op deze manier maak je dus een "self-streaming" bitmap.

Checklist: een algoritme wat de vergelijking oplost, een master-sleutel en een index file die informatie bevat over hoe de oorspronkelijke informatie versleutelt is.

Elke hoeveelheid informatie (van 1 mb tot 1000 terrabyte) zou dan theoretisch in 1 sleutel van 320 bits (hangt af van het raster) terug te brengen zijn. De index file neemt iets toe in grote naarmate er meer informatie is opgeslagen maar dat is niet zo relevant IMO.

Maargoed, als dit allemaal zo makkelijk was als het klonk zat ik nu op een tropisch eiland.

HIER HET PROBLEEM:
Er is een groot aantal mogenlijkheden binnen een raster als je alleen de rijen en colommen aangeeft, ik heb ook geprobeerd de 2 diagonalen te beschrijven en in geo-centrische ringen. Maar tot dusver is niet voldoende gebleken. (al heb ik niet geprobeerd alles tegelijk te beschrijven)

Heeft iemand hier iedeen over?
Ik vond het wel een leuk probleem :cool:

Stel dat zoiets werkt, weet je hoe een complex werk het dan wordt om met behulp van dat ingepakte sleutelgebeuren een TB aan informatie te berekenen ? Ik snap het principe ook niet helemaal, overigens. Die puzzel ken ik wel.

Ik kan best een file maken van 1 TB die in te pakken is tot +/- 9 bytes. So? Er is no way dat dat 'algorithme' semi-random data kan comprimeren.

Dat is het wel, want de grootte van die 'index file' is evenredig aan de grootte van de input file.

In het geval van een grote japanse puzzel krijg je bovendien ook nog eens het probleem dat er vaak meerdere oplossingen mogelijk zijn, of dat bepaalde oplossingen niet in een 'puzzel' te vatten zijn.

jah dat is het probleem, de mogelijkheden.

De indexfile is IMO echt geen probleem,
want stel, je pakt 3 sleuteld uit 1 sleutel. herhaal je dit process 10 maal dan heb je 3^10 = 59049 paketjes

in de index iets van //decrypt itteration = 10 "all key data"

daarna bevat ieder pakketje 2/3 informatie van de "source" data , dwz die originele 10TB (of wat dan ook)
en 1/3 sleutel, dus de sleutel voor het volgende pakket

hij blijft nu bij die 59049 pakketten, die zich steeds vernieuwen

laten we zeggen dat die zich 2 miljoen keer moeten herhalen
in de index iet in de trand van
//decrypt itteration = 2000000 "store 2/3" "rest key data"

dit alleen om aan te tonen dat ik IMO denk dat de index file totaal niet groot hoeft te zijn.

Daarom, heeft iemand ideen hoe je wel misschien de lokaties efficient doch absolut kan opslaan.

Als iemand creatieve gedachten heeft, wat dan ook, post het!

Vertaald:
Je kan alle getal met 1 miljoen cijfers schrijven met maar 320 cijfers.

Als je maar genoeg tekens hebt om uit te kiezen lukt dat.

Verder snap ik amper iets van zijn verhaal.

in het zelfde getallen stelsel :)

ok het is waarschijnlijk een erg vaag verhaal :D

misshien kan ik het uitleggen aan de hand van dit exel bestandje.
www.geocities.com/mvdanker/32x32.xls

dit is om het enigzins te begrijpen, er is nog geen echte oplossing.

ok, kijk naar dat raster, kleur nu in de bovenste helf een X aantal vakjes zwart, maak een tekeningetje ofzoiets. Dit is raster 4 (we werken achterwaarts, coderen dus)

tel nu voor elke horizontale en verticlale rij het aantal zwarte vakjes. Begin bij de eerste horizontale rij en ga dan naar de verticale rijen.

goed, nu pak je raster 3, een leeg raster. Maak ook hierin weer een tekening. In de onderste helft kun je nu alle getallen kwijt die je bij het vorige raster telde. let wel, je moet ze opslaan in 1 byte (dus 8 lege vakjes). 15 word dus 00001111 oftewel 4 lege vakjes en 4 zwarte.

Tel nu alle vakjes in raster 3 op de zelfde manier als bij raster 4

Als je dat gedaan hebt, pak je wederom een nieuw raster, raster 2. Maak een nieuwe tekening en zet de getelde waardes weer in de hokjes van de onderste helft.

Als laatste tel je de hokjes bij raster 2, en die zet je in de onderste helft van raster 1....

goed, raster 1 bevat nu een korte code. Met daarin de volgende codes... het werkt nog niet, dat weet ik zelf ook wel.

Ik zoek naar meer manieren om de posities op te slaan.

Mjah

dus er word echt alleen nog maar gebruik gemaakt van 1 en 0, vrij binair dus. (y)