Ik weet mogelijk hoe het systeem van Sloot werkt

[Johan1951]

From: Tijn

[Johan1951]

From: Raptorix

Tijn schreef:

4 kleuren eitje

[Johan1951]

From: GlowMouse

Raptorix schreef:
[..]
Laten we er een challenge van maken, jullie mogen een willekeurig image van 32x32 (8 bits kleuren) posten, ik ga dan proberen een stukje software te schrijven, wat de image zal comprimeren volgens mijn theorie, als tegentest zullen we de image met diverse anderen compressores verkleinen om te kijken of mijn techniek van toegevoegde waarde is.

Wil je nou lossy of lossless comprimeren?

[Johan1951]

From: HenryHill

@TS: heb je wel eens over het volgende nagedacht:
Er moet wel een ondergrens zijn aan hoe sterk je iets kunt comprimeren, want anders zou je het resultaat van n bytes nog een keer door het compressiealgoritme kunnen halen om het te comprimeren tot n-1 bytes, en dan nog een keer, en nog een keer, etc. Net zolang totdat je 1 byte overhebt.

En van 1 byte weet je zeker dat je er maar 256 films van kunt maken, toch? Dus dit scenario kan niet.

Blijft over: er is wel een ondergrens aan hoe sterk iets gecomprimeerd kan worden - kleiner is wiskundig onmogelijk zonder het tegelijkertijd onmogelijk te maken om andere datastromen ook te kunnen comprimeren. En die ondergrens is al 60 jaar geleden gedefinieerd.

[Johan1951]

From: Raptorix

GlowMouse schreef:
[..]
Wil je nou lossy of lossless comprimeren?

Losless, dat is namelijk eerlijk te meten.

[Johan1951]

From: Raptorix

HenryHill schreef:
@TS: heb je wel eens over het volgende nagedacht:
Er moet wel een ondergrens zijn aan hoe sterk je iets kunt comprimeren, want anders zou je het resultaat van n bytes nog een keer door het compressiealgoritme kunnen halen om het te comprimeren tot n-1 bytes, en dan nog een keer, en nog een keer, etc. Net zolang totdat je 1 byte overhebt.

En van 1 byte weet je zeker dat je er maar 256 films van kunt maken, toch? Dus dit scenario kan niet.

Blijft over: er is wel een ondergrens aan hoe sterk iets gecomprimeerd kan worden - kleiner is wiskundig onmogelijk zonder het tegelijkertijd onmogelijk te maken om andere datastromen ook te kunnen comprimeren. En die ondergrens is al 60 jaar geleden gedefinieerd.

Eens, het idee wat ik heb zal ook niet gaan werken voor hele kleine reeksen, maar ik gok erop dat het bij langere reeksen wel zal gaan werken, immers hoe langer de reeks, hoe groter de kans dat het ergens verstopt zit

[Johan1951]

From: JoPiDo

Raptorix schreef:
Ok ik heb dit idee al vele jaren, en heb dit al met meerdere mensen besproken, ik wou het nu met jullie delen wat mijn theorie is, weet je niet wie Jan Sloot is, lees dan eerst de wiki graag: http://nl.wikipedia.org/wiki/Jan_Sloot

Ok dit is mijn theorie, zoals jullie weten zijn getallen zoals PI volledig willekeurig wat decimalen betreft, de anekdote is dat als je de decimalen maar lang genoeg zou analyseren je vanzelf de mona lisa tegen zou komen, of wel de kans dat je bijvoorbeeld 3x achter elkaar een 9 zou tegenkomen is geheel in de verwachting van de kansberekening, van 1/10 x 1/10 x 1/10 kortom, of wel om de 1000 decimalen zul je deze frequentie zien (eigenlijk iets vaker omdat je ook aangrenzende getallen hebt, maar dat terzijde).

Maar goed, nu verder op mijn theorie, als je nu een enorme database hebt van een getal wat altijd te reproduceren is (bijvoorbeeld PI), dan zou je deze data kunnen gebruiken om data te comprimeren, kijk maar eens op: http://www.thealmightyguru.com/Pointless/PI-10000.html

Daar zie je allerlei setjes van willekeurige data, dat is handig, immers met een paar regels code kan je een enorme database opbouwen om deze data te reproduceren:

Voordeel: Koste geen osplagruimte
Nadeel: Kost CPU kracht is nodig om deze te reproduceren.

Echter naargelang CPU minder belangrijk word, en gezien Moore's law is dat zo, zal dat een minder groot probleem zijn.

Kern van mijn theorie is, dat als je bijvoorbeeld een plaatje zou opsplitsen in reekjes van decimalen, dan zou je dus kunnen gaan kijken of deze reeks ergens in PI voorkomt, als je dat nou eenmaal hebt gevonden, dan hoef je alleen de referentie naar deze reeks op te slaan om je compressie te bereiken. Nu zou je dat met alleen PI kunnen doen, maar daarmee verlaag je je kansen op een succes naar een kleine referentie, immers ga je uit van 1 te reproduceren getal (bijvoorbeeld PI), dan is die kans kleiner dat je een reeks van bijvoorbeeld 8 decimalen bij de eerste 10.000 decimalen vind. Echter gebruik je nog meer te reproduceren getallen, dan neemt die kans toe. De clue van mijn theorie is echter dat je ontzettend veel van dit getallen in een geoptimaliseerde database zet, zodat je snel kan zoeken naar gunstige referenties, het mooie is dat je voor het terug rekenen deze database niet nodig hebt, immers als je weet hoe je het getal moet genereren, is de database niet nodig.

Ook vuur maar los

Pi is niet willekeurig en oneindig lang, je aanname dat de Mona Lisa er ergens in voorkomt klopt, maar niemand weet waar deze begint en waar deze eindigt, het idee dat je pi kunt gebruiken voor jouw methode is dus onzin.

Zoals Jan Sloot heeft gezegd en ook in het boek over de broncode terug is te lezen, is zijn methode niet gebaseerd op het opslaan van 1'en en 0'en.

Dat kan ook niet, want stel dat je een film kunt opslaan op 100kb, dan waren er maar 2^(8*100*1000) verschillende films mogelijk en had je me deze methode alle films die je ooit kunt maken te pakken.

[Johan1951]

From: HenryHill

Raptorix schreef:
[..]
Eens, het idee wat ik heb zal ook niet gaan werken voor hele kleine reeksen, maar ik gok erop dat het bij langere reeksen wel zal gaan werken, immers hoe langer de reeks, hoe groterkleiner de kans dat het ergens verstopt zit

De kans om een een specifieke reeks van 4 cijfers te vinden is 10 keer zo klein als die om een specifieke reeks van 3 cijfers te vinden.

M.a.w.: als je een kleine reeks al niet efficient kunt vinden, lukt je dat voor een grotere reeks ook niet.

[Johan1951]

From: Rekenwonder

Raptorix schreef:
[..]
Wel als je uitgaat van 1 reeks, immers de kans dat je daadwerkelijk "hit" is waarschijnlijk net zo lang als de referentie, voorbeeld de kans dat je een 16 bits getal hit, zal waarschijnlijk ook 16 bits aan referentie duren, echter mijn theorie gaat niet uit van 1 getal maar van meerdere, en dan ook over meerdere dimensies.

Laten we er een challenge van maken, jullie mogen een willekeurig image van 32x32 (8 bits kleuren) posten, ik ga dan proberen een stukje software te schrijven, wat de image zal comprimeren volgens mijn theorie, als tegentest zullen we de image met diverse anderen compressores verkleinen om te kijken of mijn techniek van toegevoegde waarde is.

Ook als je gebruikt maakt van 'meerdere reeksen' bega je de klassieke fout: de sleutel om een bepaalde cijferreeks aan te wijzen is minimaal even groot als de bewuste cijferreeks.

Een specifiek plaatje van 32x32 kun je tot 1 bit comprimeren. De compressor en decompressor bevatten dan wel het plaatje zelf En dat is dan ook het enige plaatje dat je kunt comprimeren.

Maar je mag de uitdaging uiteraard aangaan. Voor mijn part gebruik je een willekeurig 32x32 plaatje.

[Johan1951]

From: Raptorix

HenryHill schreef:
[..]
De kans om een een specifieke reeks van 4 cijfers te vinden is 10 keer zo klein als die om een specifieke reeks van 3 cijfers te vinden.

M.a.w.: als je een kleine reeks al niet efficient kunt vinden, lukt je dat voor een grotere reeks ook niet.

Dat bedoelde ik ook
Het lijkt me gewoon leuk om te kijken of wat ik in me hoofd heb naar iets praktisch om te zetten,

A) goede programmeer oefening
B) geeft leuk inzicht of zoiets werkt (of juist niet, ook nuttig )
C) 0.0001 % dat het wel zo is, ik koop Ajax op en noem het FC Haarlem