mega-compressie - deel 2 -

quote:

Op vrijdag 22 juli 2005 20:33 schreef gnomaat het volgende:

[..]

Hint: als het decimale getal 112131032202120121 is, van welke ascii waardes komt dat dan? (m.a.w. welke originele file hoort hierbij?)

Bedoel je dat één getallenreeks kan staan voor meerdere ASCII files?

Ok, dan moet je dus inderdaad werken met A0 + 256*A1 + 256²*A3, enz.., met Ai de ASCII waarde van karakter 'i', maar dat maakt het uiteindelijke getal toch alleen maar nog langer? Dat maakt Gelly's methode nog inefficienter.

Maar ok, je hebt gelijk, mijn uitleg was te simpel gedacht, wat dit betreft.

[edit] Je getal hoort volgens bovenstaande methode bij de volgende 8 bytes:

192 139 180 102 148 94 142 1

_{De 'Prime test' maakt er vervolgens 15 van}[/edit]

[ Bericht 6% gewijzigd door BUG80 op 22-07-2005 20:52:11 ]

Ik heb al heel lang geleden een systeem proberen te maken gebaseerd op Chaos. Bij een willekeurig bestand neemt een tabel met verwijzingen gewoon meer ruimte in dan het origineel. Ik denk dat dat met priemgetallen niet veel beter zal zijn.


Dit figuur is met een paar regels code te maken, het opgeslagen plaatje kost veel meer ruimte dan de broncode.

quote:

Op vrijdag 22 juli 2005 20:40 schreef BUG80 het volgende:
Bedoel je dat één getallenreeks kan staan voor meerdere ASCII files?

Ok, dan moet je dus inderdaad werken met A0 + 256*A1 + 256²*A3, enz.., met Ai de ASCII waarde van karakter 'i', maar dat maakt het uiteindelijke getal toch alleen maar nog langer?

Nog langer dan iets wat niet werkt ja, dus je moet wel

quote:

Op zaterdag 23 juli 2005 00:10 schreef gnomaat het volgende:

[..]

Nog langer dan iets wat niet werkt ja, dus je moet wel

Ja, dat is waar.

Maar goed, dat deze specifieke methode niet werkt betekent nog niet dat we het idee van Gelly moeten afschrijven. Ik maakte al eerder een semi-grappige opmerking over "priemwoorden", maar misschien zit daar wel wat in. Stel nou dat we met een getallenstelsel gaan werken dat niet uit de decimalen 0-9 bestaat, maar uit ASCII waarden 0-255. Met zo'n getallenstelsel kun je net zo goed bewerkingen uitvoeren, zoals optellen en vermenigvuldigen. Vergelijk het met het hexadecimale stelsel 00-FF. Aangezien je lineaire operaties uit kunt voeren, zouden er ook equivalenten van priemgetallen moeten bestaan, toch?

Alleen ben ik bang dat de volgende stelling geldig is: Ontbinding van een getal in andere getallen zal gemiddeld genomen niet tot compressie leiden.

quote:

Op vrijdag 22 juli 2005 21:12 schreef BabeWatcher het volgende:
Ik heb al heel lang geleden een systeem proberen te maken gebaseerd op Chaos. Bij een willekeurig bestand neemt een tabel met verwijzingen gewoon meer ruimte in dan het origineel. Ik denk dat dat met priemgetallen niet veel beter zal zijn.

[[url=http://img280.imageshack.us/img280/3992/fb9yy.th.png]afbeelding][/URL]
Dit figuur is met een paar regels code te maken, het opgeslagen plaatje kost veel meer ruimte dan de broncode.

jaja, maar, dat zegt niet zoveel.
Er zijn ook programma´tje die een landschap genereren waar je dan virtueel zeg maar door heen gaat.
Dat is echter geen compressie, maar genereren van beelden.

Stel, en ik zeg stel, je kan een bitmap plaatje omrekenen naar een vectorgrafiek, en dat naar een fractale formule die dat zou genereren, en je doet dat 25 maal per seconde, dan zou je film kunnen omrekenen naar een fractale formule.
Dan zou je eventueel een compressie methode hebben (vooropgesteld dat het resultaat dan kleiner is)
Okay, stel dit zou kunnen, dan zou de hoeveelheid iteraties per film enorm groot zijn, en het is met zekerheid niet de methode die Sloot zou kunnen hebben gebruikt omdat
1) De wiskunde die daarvoor nodig is eerst eens moet uitgevonden worden.
2) De rekencapaciteit nodig is astronomisch.
3) Ook je met deze methode geen film naar 4K gaat krijgen.

quote:

Op zaterdag 23 juli 2005 12:05 schreef Pietverdriet het volgende:

[..]

jaja, maar, dat zegt niet zoveel.
Er zijn ook programma´tje die een landschap genereren waar je dan virtueel zeg maar door heen gaat.
Dat is echter geen compressie, maar genereren van beelden.

Stel, en ik zeg stel, je kan een bitmap plaatje omrekenen naar een vectorgrafiek, en dat naar een fractale formule die dat zou genereren, en je doet dat 25 maal per seconde, dan zou je film kunnen omrekenen naar een fractale formule.
Dan zou je eventueel een compressie methode hebben (vooropgesteld dat het resultaat dan kleiner is)
Okay, stel dit zou kunnen, dan zou de hoeveelheid iteraties per film enorm groot zijn, en het is met zekerheid niet de methode die Sloot zou kunnen hebben gebruikt omdat
1) De wiskunde die daarvoor nodig is eerst eens moet uitgevonden worden.
2) De rekencapaciteit nodig is astronomisch.
3) Ook je met deze methode geen film naar 4K gaat krijgen.

Voornamelijk het laatste punt is waar het om gaat. De stelling dat het met 32768 bits mogelijk zou zijn om meer dan 32768 verschillende films te produceren is ridicuul. Dat kan iedere wiskundige je vertellen. Daarom is het, zoals ik al aangaf, wellicht wel mogelijk om films tot tientallen tot honderden mb's te reduceren, mits je bereid bent een bepaald kwaliteitsverlies toe te staan. Wellicht dat dit visueel kan worden gereduceerd tot praktisch 0, maar logisch gezien (op bitniveau) is het verlies er.

quote:

Op zaterdag 23 juli 2005 12:41 schreef -erwin- het volgende:
Voornamelijk het laatste punt is waar het om gaat. De stelling dat het met 32768 bits mogelijk zou zijn om meer dan 32768 verschillende films te produceren is ridicuul.

Ehm, meer dan 2³²⁷⁶⁸ films. En dat zijn er heel wat meer dan er ooit gemaakt zullen worden

quote:

Op zaterdag 23 juli 2005 11:15 schreef BUG80 het volgende:
Maar goed, dat deze specifieke methode niet werkt betekent nog niet dat we het idee van Gelly moeten afschrijven. Ik maakte al eerder een semi-grappige opmerking over "priemwoorden", maar misschien zit daar wel wat in. Stel nou dat we met een getallenstelsel gaan werken dat niet uit de decimalen 0-9 bestaat, maar uit ASCII waarden 0-255. Met zo'n getallenstelsel kun je net zo goed bewerkingen uitvoeren, zoals optellen en vermenigvuldigen. Vergelijk het met het hexadecimale stelsel 00-FF. Aangezien je lineaire operaties uit kunt voeren, zouden er ook equivalenten van priemgetallen moeten bestaan, toch?

Natuurlijk, die priemgetallen zijn hetzelfde als "onze" priemgetallen.

Het priem zijn van getallen hangt niet af van het talstelsel waarin je ze noteert.

quote:

Alleen ben ik bang dat de volgende stelling geldig is: Ontbinding van een getal in andere getallen zal gemiddeld genomen niet tot compressie leiden.

Ik weet het wel zeker

quote:

Op zaterdag 23 juli 2005 12:45 schreef gnomaat het volgende:

[..]

Ehm, meer dan 2³²⁷⁶⁸ films. En dat zijn er heel wat meer dan er ooit gemaakt zullen worden

ahum. mijn fout ik zal hem maar niet editen, anders lijkt het zo raar. goede morgen

quote:

Op zaterdag 23 juli 2005 12:48 schreef -erwin- het volgende:

[..]

ahum. mijn fout ik zal hem maar niet editen, anders lijkt het zo raar. goede morgen

Neem een bakkie koffie zou ik zeggen

Stel dat de code bestaat, alsnog had geen enkele laptop in die tijd de benodigde rekenkrecht voorhet direct afspelen van 16 filmen simultaan

quote:

Op zaterdag 23 juli 2005 12:46 schreef gnomaat het volgende:

[..]

Natuurlijk, die priemgetallen zijn hetzelfde als "onze" priemgetallen.

Het priem zijn van getallen hangt niet af van het talstelsel waarin je ze noteert.
[..]

Ik weet het wel zeker

Ja ik ook, gevoelsmatig. Heb je toevallig een link naar een wiskundig bewijs?

Gevoelsmatig zou het argument van -erwin- al voldoende moeten zijn:

quote:

hierbij geldt hetzelfde principe als hierboven al aangehaald. ik kan in een paar bytes een heel groot getal produceren, maar ik kan niet in een paar bytes elk groot getal produceren. zoiets valt via relatief eenvoudige logica te bewijzen.

quote:

Op zaterdag 23 juli 2005 12:53 schreef JasperE het volgende:
Stel dat de code bestaat, alsnog had geen enkele laptop in die tijd de benodigde rekenkrecht voorhet direct afspelen van 16 filmen simultaan

Als zowel beeld als geluid ongecomprimeerd zijn zou het wel moeten kunnen, toch? Maarja, ze waren wel gecomprimeerd, dat is juist het punt.

Dat is dus ook zoiets: als het algoritme bestaat moet het wel verdomd "licht" zijn geweest. Neem een equivalent van audio compressie: Ogg Vorbis. Daarmee haal je veel betere kwaliteit dan MP3 op dezelfde bitrate, maar het kost dan ook veel meer rekenkracht.

quote:

Op zaterdag 23 juli 2005 12:45 schreef gnomaat het volgende:

[..]

Ehm, meer dan 2³²⁷⁶⁸ films. En dat zijn er heel wat meer dan er ooit gemaakt zullen worden

en dan heb je 1 0 bit´s per film
De 2³²⁷⁶⁸ posities zijn dan alleen maar het catalogusnummer, je hebt niets meer over om informatie van de film op te slaan

Maar goed, ik zie eigenlijk alleen maar het herkauwen van de dingen die in de vorige topics al uitvoerig herkauwt zijn.

quote:

Op zaterdag 23 juli 2005 13:03 schreef Pietverdriet het volgende:
en dan heb je 1 0 bit´s per film
De 2³²⁷⁶⁸ posities zijn dan alleen maar het catalogusnummer, je hebt niets meer over om informatie van de film op te slaan

De eigenlijke films zouden dan in een database staan. Niet dat ik ook maar iets zinnigs zie in zo'n oplossing, maar het ging er alleen om dat de bewering dat 32768 bits al niet genoeg was om uberhaupt alle films uniek mee te identificeren omdat er veel meer zouden zijn, niet klopte.

quote:

Op zaterdag 23 juli 2005 12:57 schreef BUG80 het volgende:
Als zowel beeld als geluid ongecomprimeerd zijn zou het wel moeten kunnen, toch? Maarja, ze waren wel gecomprimeerd, dat is juist het punt.

Hoe zat dat eigenlijk bij die uitvinding van Jan Sloot, decomprimeerde zijn kastje de data? Of las hij alleen data uit dat kastje wat vervolgens met een normaal programma werd gedecomprimeerd?

quote:

Op zaterdag 23 juli 2005 12:55 schreef BUG80 het volgende:
Ja ik ook, gevoelsmatig. Heb je toevallig een link naar een wiskundig bewijs?

Nee zo niet, maar moet niet al te moeilijk zijn.
Wat voor ontbinding bedoel je precies, een getal normaal ontbinden in priemfactoren en dan voor iedere priemfactor opschrijven het hoeveelste priemgetal het is?
Of een zo groot mogelijk priemgetal vinden dat je van het getal af kunt trekken (eventueel alleen Mersenne priemgetallen of een andere bekende serie zodat je ze heel kort kunt noteren) en dan hetzelfde met het restant tot je 0 overhoudt. Dus een soort ontbinden in "priemsommen". Dat is geloof ik ook wat gelly deed?

quote:

Op zaterdag 23 juli 2005 14:03 schreef gnomaat het volgende:

[..]

Nee zo niet, maar moet niet al te moeilijk zijn.
Wat voor ontbinding bedoel je precies, een getal normaal ontbinden in priemfactoren en dan voor iedere priemfactor opschrijven het hoeveelste priemgetal het is?
Of een zo groot mogelijk priemgetal vinden dat je van het getal af kunt trekken (eventueel alleen Mersenne priemgetallen of een andere bekende serie zodat je ze heel kort kunt noteren) en dan hetzelfde met het restant tot je 0 overhoudt. Dus een soort ontbinden in "priemsommen". Dat is geloof ik ook wat gelly deed?

Ik bedoelde eigenlijk in het algemeen. Dus elke lineaire ontbinding. Gevoelsmatig denk ik namelijk dat je alleen compressie kunt bereiken door de entropie van een reeks tekens te verlagen. Ontbinden in priemgetallen, factoren van 256, of wat dan ook maakt daar geen gebruik van toch?

quote:

Op zaterdag 23 juli 2005 14:00 schreef gnomaat het volgende:

[..]

Hoe zat dat eigenlijk bij die uitvinding van Jan Sloot, decomprimeerde zijn kastje de data? Of las hij alleen data uit dat kastje wat vervolgens met een normaal programma werd gedecomprimeerd?

Als je de vorige topics doorleest zal je zien dat de uitvinding geen van beide deed, omdat het helemaal niet kan.

quote:

Op zaterdag 23 juli 2005 14:22 schreef Pietverdriet het volgende:
Als je de vorige topics doorleest zal je zien dat de uitvinding geen van beide deed, omdat het helemaal niet kan.

Say what! Was het NEP?!

Ik weet het, maar ik bedoelde: wat werd er gesuggereerd door Jan Sloot

Ik heb wiskundig bewijs dat Sloots verhaal niet kan kloppen.

Een sleutel van 128 kilobyte kan 2^128*1024*8 = 2^1048576 verschillende waarden aannemen. Ik ga er even vanuit dat Sloot zijn algoritme volledig optimaal werkt, dus met die sleutel kan hij 2^1048576 films genereren.

Zou dit aantal genoeg zijn om alle mogelijke films weer te geven die mogelijk zijn? Laten we eerst eens kijken naar 1 frame van 640x480 pixels met 16bit kleurdiepte. Hoeveel mogelijkheden zijn hiervoor?

Stel je hebt 3 pixels met elk 2 mogelijke kleurwaarden. De kleurwaarde mogelijkheden noem ik gewoon even 0 en 1. De mogelijkheden hiermee zijn:
0 0 0
0 0 1
0 1 0
0 1 1
1 0 0
1 0 1
1 1 0
1 1 1
Aantal mogelijkheden is 2³ = 8

Voor een plaatje van x pixels en y kleurwaarden per pixel is het aantal mogelijkheden y^x
Voor een plaatje van 640x480 = 307200 pixels met 2¹⁶ = 65536 mogelijke kleurwaarden is het aantal mogelijkheden dus 65536³⁰⁷²⁰⁰ = (2¹⁶)³⁰⁷²⁰⁰ = 2^4915200

Zoals je kan zien zijn er 2^4915200/2^1048576 = 2^3866624 zoveel plaatjes mogelijk dan met 128kbyte kan gekatalogiseerd worden.

Nu hebben we het nog niet eens over films. Neem een film van 640*480@25fps, 16bit kleurdiepte en 90 minuten lang.
Aantal mogelijkheden nu:
Totaal aantal pixels: 640x480x25x90x60 = 41472000000
2¹⁶ mogelijkheden per pixel

Totaal: (2¹⁶)^41472000000 = 2^663552000000 mogelijkheden.

Wat Sloot dus al die tijd heeft beweerd is dat 128kilobyte alle 2^663552000000 mogelijke films zou kunnen bevatten. Sure...

quote:

Op dinsdag 26 juli 2005 00:31 schreef DirtyHarry het volgende:
Ik heb wiskundig bewijs dat Sloots verhaal niet kan kloppen.

dat is evident.

quote:

Op dinsdag 26 juli 2005 00:31 schreef DirtyHarry het volgende:
Nu hebben we het nog niet eens over films. Neem een film van 640*480@25fps, 16bit kleurdiepte en 90 minuten lang.
Aantal mogelijkheden nu:
Totaal aantal pixels: 640x480x25x90x60 = 41472000000
2¹⁶ mogelijkheden per pixel

Totaal: (2¹⁶)^41472000000 = 2^663552000000 mogelijkheden.

Da's mooi, maar hoe verklaar je dan dat je films kunt downloaden van 700Mb? Zelfs als je 512x384 als resolutie gebruikt dan zit je er nog een paar flinke factors naast...

quote:

Op dinsdag 26 juli 2005 00:36 schreef HenryHill het volgende:

[..]

Da's mooi, maar hoe verklaar je dan dat je films kunt downloaden van 700Mb? Zelfs als je 512x384 als resolutie gebruikt dan zit je er nog een paar flinke factors naast...

lossy compression

quote:

Op dinsdag 26 juli 2005 00:36 schreef -erwin- het volgende:

[..]

lossy compression

Maar ik geloof dat uit Sloot zijn "paper" ( ) niet te destilleren valt of hij nu wel of geen lossy compressie gebruikt of niet.

quote:

Op dinsdag 26 juli 2005 00:36 schreef HenryHill het volgende:

[..]

Da's mooi, maar hoe verklaar je dan dat je films kunt downloaden van 700Mb? Zelfs als je 512x384 als resolutie gebruikt dan zit je er nog een paar flinke factors naast...

Bij het comprimeren van films verlies je waanzinnig veel data. Als je een film van 640x480@25fps van 90 minuten verliesloos wil opslaan heb je volgens mij minstens 80 gigabyte ruimte nodig.

quote:

Op dinsdag 26 juli 2005 00:39 schreef HenryHill het volgende:

[..]

Maar ik geloof dat uit Sloot zijn "paper" ( ) niet te destilleren valt of hij nu wel of geen lossy compressie gebruikt of niet.

Hij zei dat ie verliesloos (pixel voor pixel) een film weer kon laten zien

Dit fenomeen houdt me al bezig sinds 1994/95. Pas dit jaar heb ik van iemand die ik slechts één dag kende voor het eerst gehoord dat er nog iemand was die dit ook daadwerkelijk uitgevonden had, maar dat de broncode zoek was. Roel Pieper was in het spel. Sinds slechts enkele weken weet ik dat datgene waar ik al jaren over zit te piekeren, wellicht is uitgevonden door een zekere Jan Sloot. In al die jaren heb ik één ding altijd zeker geweten; de algoritme is kinderljk eenvoudig, maar je moet net weten hoe het in elkaar steekt. Toen ik de verhalen las over Jan Sloot ben ik best wel geschrokken van de overeenkomsten. Ook hij was als de dood over het feit dat zijn algoritme uit zou lekken, voordat deze beschermd was, omdat deze kinderlijk eenvoudig is. Bovendien heeft Jan Sloot een electro achtergrond, net als ik. En laat ik nu tijdens mijn MTS periode (1994/95 dus) tijdens de les op het zelfde idee gekomen zijn om getallen reeksen te reduceren, toen een leraar een bepaalde techniek aan het uitleggen was. Hmmm.

Vreemd toch, dat meedere mensen hetzelfde proberen uit te vinden en dan tot de ontdekking komen dat iemand anders wellicht de uitvinding gedaan heeft die jij hebt willen doen. De overeenkomsten zijn zo sterk, waardoor ik zeker weet dat Jan Sloot's algoritme werkt. Wat het is weet ik ook niet, maar ik weet in welke richting ik zoeken moet.

quote:

Op zaterdag 23 juli 2005 13:07 schreef Pietverdriet het volgende:
Maar goed, ik zie eigenlijk alleen maar het herkauwen van de dingen die in de vorige topics al uitvoerig herkauwt zijn.

quote:

Op dinsdag 26 juli 2005 00:36 schreef -erwin- het volgende:
lossy compression

Mja zodra iedereen het hier over eens is kunnen we verder. Dat het wiskundig anders niet kan is al 10.000 keer geschreven op tig manieren. Met lossy compression is wel de vraag hoe de kwaliteit was van de demo.

quote:

Op dinsdag 26 juli 2005 05:34 schreef ACT-F het volgende:
Dit fenomeen houdt me al bezig sinds 1994/95. Pas dit jaar heb ik van iemand die ik slechts één dag kende voor het eerst gehoord dat er nog iemand was die dit ook daadwerkelijk uitgevonden had, maar dat de broncode zoek was. Roel Pieper was in het spel. Sinds slechts enkele weken weet ik dat datgene waar ik al jaren over zit te piekeren, wellicht is uitgevonden door een zekere Jan Sloot. In al die jaren heb ik één ding altijd zeker geweten; de algoritme is kinderljk eenvoudig, maar je moet net weten hoe het in elkaar steekt. Toen ik de verhalen las over Jan Sloot ben ik best wel geschrokken van de overeenkomsten. Ook hij was als de dood over het feit dat zijn algoritme uit zou lekken, voordat deze beschermd was, omdat deze kinderlijk eenvoudig is. Bovendien heeft Jan Sloot een electro achtergrond, net als ik. En laat ik nu tijdens mijn MTS periode (1994/95 dus) tijdens de les op het zelfde idee gekomen zijn om getallen reeksen te reduceren, toen een leraar een bepaalde techniek aan het uitleggen was. Hmmm.

Vreemd toch, dat meedere mensen hetzelfde proberen uit te vinden en dan tot de ontdekking komen dat iemand anders wellicht de uitvinding gedaan heeft die jij hebt willen doen. De overeenkomsten zijn zo sterk, waardoor ik zeker weet dat Jan Sloot's algoritme werkt. Wat het is weet ik ook niet, maar ik weet in welke richting ik zoeken moet.

Interessant, maar hoe verklaar jij dan dat het wiskundig gezien onmogelijk is om films verliesloos op te slaan in een sleutel met zo'n kleine opslagcapaciteit?
En in welke richting zouden we dan moeten denken wat betreft de werking van dat algoritme?

quote:

Op dinsdag 26 juli 2005 10:43 schreef DirtyHarry het volgende:

[..]

Interessant, maar hoe verklaar jij dan dat het wiskundig gezien onmogelijk is om films verliesloos op te slaan in een sleutel met zo'n kleine opslagcapaciteit?
En in welke richting zouden we dan moeten denken wat betreft de werking van dat algoritme?

Je bewijs is een beetje dubieus. Met hetzelfde bewijs kun je namelijk wiskundig aantonen dat 700 MB niet genoeg is, terwijl we allemaal weten dat dat wél zo is.

Theoretisch is het mogelijk, aangezien het aantal mogelijke permutaties dat je kunt maken met 32768 bits hoger is dan het aantal films dat ooit gemaakt zal worden. Praktisch haalbaar is een ander verhaal.

quote:

Op dinsdag 26 juli 2005 11:00 schreef BUG80 het volgende:

[..]

Je bewijs is een beetje dubieus. Met hetzelfde bewijs kun je namelijk wiskundig aantonen dat 700 MB niet genoeg is, terwijl we allemaal weten dat dat wél zo is.

Er is daarna al gezegd dat dat komt omdat er enorm veel lossy compressie is om een film naar 700MB te comprimeren. De clue is volgens mij nog altijd dat sloot beweerde het verliesloos te kunnen.

quote:

Theoretisch is het mogelijk, aangezien het aantal mogelijke permutaties dat je kunt maken met 32768 bits hoger is dan het aantal films dat ooit gemaakt zal worden. Praktisch haalbaar is een ander verhaal.

Het aantal mogelijke films is zo ontzettend veel groter dan het aantal mogelijke permutaties dat je kunt maken met die 32768 bits. Niet dat er zoveel films zullen worden gemaakt, maar in principe zouden alle mogelijke films die kunnen worden gemaakt met zijn algoritme in zo'n sleutel moeten passen. Nou dat past dus never nooit niet.

quote:

Op dinsdag 26 juli 2005 11:11 schreef DirtyHarry het volgende:

[..]

Er is daarna al gezegd dat dat komt omdat er enorm veel lossy compressie is om een film naar 700MB te comprimeren. De clue is volgens mij nog altijd dat sloot beweerde het verliesloos te kunnen.

Ik bedoel alleen maar dat je bewijs geen bewijs is. Je zegt het volgende:

2^2663552000000 >> 2^32768, dus het is niet mogelijk.

Dan zeg ik, in 700 MB zitten 5872025600 bits.

2^2663552000000 >> 2^5872025600, dus ook niet mogelijk.

Je bewijs is niet sluitend. Het is intuitief, maar niet wiskundig. edit: Of het lossy of lossless is maakt niet uit.

quote:

Het aantal mogelijke films is zo ontzettend veel groter dan het aantal mogelijke permutaties dat je kunt maken met die 32768 bits. Niet dat er zoveel films zullen worden gemaakt, maar in principe zouden alle mogelijke films die kunnen worden gemaakt met zijn algoritme in zo'n sleutel moeten passen. Nou dat past dus never nooit niet.

2^32768 is megagroot, probeer het maar eens te berekenen. Zoveel films zullen er in het bestaan van het heelal nooit gemaakt worden. Het enige probleem is, dat je op een gegeven moment 1 mogelijke permutatie per film krijgt. Dat is praktisch onmogelijk te realiseren. Het is alleen niet te bewijzen dat het niet kan.

Oja, nog een kleine toevoeging. Met jouw bewijs kun je ook aantonen dat je met WinZip nooit een bestand kunt verkleinen.

Immers, met 1024 bits kun je 2^1024 mogelijke bestanden maken, dat kun je dus nooit verkleinen naar 512 bits, bijvoorbeeld.

Snap je nu mijn probleem met jouw verhaal?

Het probleem met het sloot verhaal is niet zozeer of het wel of niet mogelijk is maar dat ie het deed op een Pentium 2 laptop.

Ik heb trouwens een keer een gastcollege gehad van Roel Pieper, waarin hij maar bleef hameren op het feit dat je als ondernemer risico's moet durven nemen om verder te komen. Ik geloof dat hij zoiets zei als "9 op de 10 investeringen worden een grote flop, maar het gaat om die ene die wél een succes wordt".

Het zou heel goed kunnen dat Pieper ook sceptisch was over de vinding van Sloot, maar in het kader van zijn investeringstheorie nam hij het risico om er een paar miljoen in te steken.

quote:

Op dinsdag 26 juli 2005 11:37 schreef Pinobot het volgende:
Het probleem met het sloot verhaal is niet zozeer of het wel of niet mogelijk is maar dat ie het deed op een Pentium 2 laptop.

Neuh

BUG80
Gegeven de volgende simpele situatie:
Een plaatje van 2x2 pixels met voor elke pixel de waarde zwart of wit. Het totaal aantal mogelijke plaatjes wat je in dit geval kan creeeren is 2^2x2 = 2⁴, mee eens?
Nou mag jij voor mij vertellen wat de kortst mogelijke sleutel is waarmee je alle mogelijke plaatjes mee weet te katalogiseren. (ik heb het nog niet eens over het genereren van het plaatje uit een unieke sleutel)

Ik ga ondertussen drinken

quote:

Op dinsdag 26 juli 2005 13:36 schreef DirtyHarry het volgende:
BUG80
Gegeven de volgende simpele situatie:
Een plaatje van 2x2 pixels met voor elke pixel de waarde zwart of wit. Het totaal aantal mogelijke plaatjes wat je in dit geval kan creeeren is 2^2x2 = 2⁴, mee eens?
Nou mag jij voor mij vertellen wat de kortst mogelijke sleutel is waarmee je alle mogelijke plaatjes mee weet te katalogiseren. (ik heb het nog niet eens over het genereren van het plaatje uit een unieke sleutel)

Ik ga ondertussen drinken

Ja ik snap wel wat je bedoelt. Je gaat er in je redenering alleen van uit dat je eventuele redundantie niet uit de data kunt halen. Nogmaals, hoe denk je dat WinZip werkt? Dat gaat toch ook tegen jouw principe in, dat je minstens het aantal bits nodig hebt dat elke mogelijke combinatie kan representeren?

Laat ik het dan nog eens anders formuleren.

Zolang niet alle mogelijke combinaties gemaakt kunnen worden binnen het bestaan van het heelal, heb je ook niet alle bits nodig die dat kunnen representeren.

Stel dat er uiteindelijk in de hele geschiedenis maar vier films gemaakt worden:

0001
1010
1111
1010

Om deze ongecomprimeerd op te slaan heb je 4 bits nodig. Echter, er is vast wel een algoritme te verzinnen waarmee deze reeksen in maar 2 bits op te slaan zijn (want: er zijn maar 4 mogelijke films gemaakt).

quote:

Op dinsdag 26 juli 2005 13:46 schreef BUG80 het volgende:
Laat ik het dan nog eens anders formuleren.

Zolang niet alle mogelijke combinaties gemaakt kunnen worden binnen het bestaan van het heelal, heb je ook niet alle bits nodig die dat kunnen representeren.

Stel dat er uiteindelijk in de hele geschiedenis maar vier films gemaakt worden:

0001
1010
1111
1010

Om deze ongecomprimeerd op te slaan heb je 4 bits nodig. Echter, er is vast wel een algoritme te verzinnen waarmee deze reeksen in maar 2 bits op te slaan zijn (want: er zijn maar 4 mogelijke films gemaakt).

Ja ok dat klopt Alle mogelijke films zullen kwa aantal makkelijk in die 128 kilobyte passen. Maar dan moet je op de een of andere manier dat algoritme wijs maken welke combinaties niet bestaan en welke wel. En dat lijkt me praktisch gezien vrij lastig

quote:

Op dinsdag 26 juli 2005 14:19 schreef DirtyHarry het volgende:

[..]

Ja ok dat klopt Alle mogelijke films zullen kwa aantal makkelijk in die 128 kilobyte passen. Maar dan moet je op de een of andere manier dat algoritme wijs maken welke combinaties niet bestaan en welke wel. En dat lijkt me praktisch gezien vrij lastig

Inderdaad, zoniet onmogelijk. Dat betekent dat hij één of ander patroon had moeten vinden dat voor alle films geldt.

Ik ben het dus met je eens hoor, ik geloof er niet in, maar wiskundig bewijzen dat het onmogelijk is gaat niet volgens mij.

quote:

Op dinsdag 26 juli 2005 11:11 schreef DirtyHarry het volgende:

[..]

Er is daarna al gezegd dat dat komt omdat er enorm veel lossy compressie is om een film naar 700MB te comprimeren. De clue is volgens mij nog altijd dat sloot beweerde het verliesloos te kunnen.
[..]

Het aantal mogelijke films is zo ontzettend veel groter dan het aantal mogelijke permutaties dat je kunt maken met die 32768 bits. Niet dat er zoveel films zullen worden gemaakt, maar in principe zouden alle mogelijke films die kunnen worden gemaakt met zijn algoritme in zo'n sleutel moeten passen. Nou dat past dus never nooit niet.

Compressie is eigenlijk het verkeerde woord, je noteert de getallen op een andere manier en het is van toepassing op elke bitstroom. Meer zeg ik niet

Ik heb het eerste deel van de Netwerk uitzending inmiddels gezien. Jammer dat ze geen sceptici aan het woord laten, het is wel erg eenzijdig zo.

Ik vraag me trouwens al een tijdje af waarom deze vermeende techniek alleen op films werd toegepast door Sloot.

1) Was het een algoritme dat optimaal of alleen maar voor films werkt?
2) Is het omdat dat makkelijker te demonstreren valt (spreekt tot de verbeelding)?
3) Is het omdat je dan makkelijker mensen kan bedriegen? (als je "gewone" of willekeurige bestanden gebruikt, zullen mensen als snel vragen of je ook andere bestande wilt proberen)

quote:

Op dinsdag 26 juli 2005 11:23 schreef BUG80 het volgende:
Oja, nog een kleine toevoeging. Met jouw bewijs kun je ook aantonen dat je met WinZip nooit een bestand kunt verkleinen.

Immers, met 1024 bits kun je 2^1024 mogelijke bestanden maken, dat kun je dus nooit verkleinen naar 512 bits, bijvoorbeeld.

Snap je nu mijn probleem met jouw verhaal?

Er is een verschil tussen nooit een bestand kunnen verkleinen = geen enkel bestand kunnen verkleinen, en niet alle bestanden kunnen verkleinen.
Als je een bestand neemt van bvb 2000 bits, en winzip comprimeert dit tot een bestand van 1024 bits, dan zal winzip dat bestand van 1024 bits niet meer kunnen comprimeren.
Tekstbestanden bijvoorbeeld comprimeren goed omdat tekst veel redundantie bevat.

Nu lijkt het misschien dat je de toch winst maakt met winzip over het totaal van de 2^1024 mogelijke files, omdat je een deel kleiner kunt maken. MAAR: er zullen ook files groter worden!!

vb: ik heb een bitmap X gecromprimeerd met winzip, het resultaat is een file Y van 1.325.093 bytes.
Nu ga ik deze file nog eens comprimeren, resultaat:file Z van 1.325.300 bytes
Waarom is deze file groter geworden? Winzip kan hem niet verder comprimeren, maar hij kan hem ook niet onveranderd laten, want als ik hem dan zou unzippen zou ik de oorspronkelijke bitmap X terugkrijgen en niet file Y.

Nu is winzip niet geoptimaliseerd voor het verwerken van reeds gecomprimeerde files, men zou het algoritme kunnen aanpassen zodat files hoogstens 1 bit groter kunnen worden. Die ene bit zou dan aangeven of het bestand gecomprimeerd is, of het origineel bevat. Blijkt compressie het bestand groter te maken,dan voeg je enkel deze bit toe aan het bestand (je zet een 0 ervoor), in het andere geval zet je een 1 voor het resultaat. Merk op dat hierdoor alle gecomprimeerde bestanden een bit groter worden.

Uiteindelijk, als je alle mogelijke files van 1024 bits comprimeert, dus 1024 * 2^1024 bits aan data, dan zal je als resultaat opnieuw 1024 * 2^1024 bits aan data krijgen. De compressie van een deel van de bestanden wordt gecompenseerd door de extra bit die een ander deel van de bestanden krijgen. (in werkelikheid zal je meer data krijgen dan waar je mee begonnen zijn, omdat winzip oa een CRC waarde toevoegd)

quote:

Op dinsdag 26 juli 2005 13:46 schreef BUG80 het volgende:
Laat ik het dan nog eens anders formuleren.

Zolang niet alle mogelijke combinaties gemaakt kunnen worden binnen het bestaan van het heelal, heb je ook niet alle bits nodig die dat kunnen representeren.

Stel dat er uiteindelijk in de hele geschiedenis maar vier films gemaakt worden:

0001
1010
1111
1010

Om deze ongecomprimeerd op te slaan heb je 4 bits nodig. Echter, er is vast wel een algoritme te verzinnen waarmee deze reeksen in maar 2 bits op te slaan zijn (want: er zijn maar 4 mogelijke films gemaakt).

Als er maar 4 films gemaakt zijn heb je inderdaad maar twee bits nodig om ze op te slaan, ongeacht de grootte van de films. Dit algoritme is eenvoudig, MAAR het data-gedeelte moet de volledige films bevatten!

Als je een compressie-algoritme ontwerpt voor een bepaald type files, dan kan je de compressie verhogen door het algoritme meer data te geven. Voor nederlandse teksten kan je bijv. heel de nederlandse woordenlijst gebruiken, en de woorden volgens een frequentietabel te nummeren. vb: de=001 een=010 het=011 met=1000 van=1001 op=1010 enzovoort. Je bekijkt een hoop texten om de frequentie van elk woord te bepalen, en dan geef je elk woord een unieke code, hoe frequenter het woord voorkomt, hoe korter de code.

Deze methode zal niet werken als je bestanden met willekeurige letterreeksen wil comprimeren, omdat elke combinatie van een gegeven aantal letters even vaak zal voorkomen.

quote:

Op donderdag 28 juli 2005 21:48 schreef Doderok het volgende:
Deze methode zal niet werken als je bestanden met willekeurige letterreeksen wil comprimeren, omdat elke combinatie van een gegeven aantal letters even vaak zal voorkomen.

Klopt, helemaal mee eens, net als je theorie over WinZip in je andere reactie.

Maar stel nou dat films, net als tekst, geen willekeurige tekenreeksen zijn en daadwerkelijk een bepaalde "magische" redundantie bevatten die toch in één algoritme te vangen is.

Het is allemaal hypothetisch, dat is waar. Nogmaals, het enige dat ik probeer aan te tonen, is dat het in mijn ogen niet *wiskundig* te bewijzen is dat de compressie van Sloot onmogelijk is, ook al is het intuitief nog zo onwaarschijnlijk.

quote:

Op dinsdag 26 juli 2005 16:11 schreef ACT-F het volgende:
Compressie is eigenlijk het verkeerde woord, je noteert de getallen op een andere manier en het is van toepassing op elke bitstroom. Meer zeg ik niet

Je hoeft geen verdere details te verklappen, maar het klinkt alsof je iets essentieels over het hoofd ziet. Even om duidelijk te krijgen waar we het over hebben:

- een manier om meer data in dezelfde hoeveelheid bits te kunnen vastleggen, dus dat je bijvoorbeeld een film die uncompressed 150 GB is, kwijt kunt op een flash kaartje van 128 MB? (of zelfs nog kleiner)

- of een manier om fysiek gezien efficiënter data op te slaan, dus een één of ander zelfbedacht opslagmedium met een hogere datadichtheid (meer bits/cm²) dan de huidige harddisks/dvd's/enz ?

Is het lossy of lossless?

En werkt het alleen voor bepaalde soorten data, bijvoorbeeld audiovisuele data (zoals films), of ook voor random data?

Is de methode ook van toepassing op zichzelf? M.a.w. kun je de kleinere bitstream die je volgens jouw idee krijgt (als het resultaat weer een bitstream is althans) zelf ook weer als een normale bitstream interpreteren en die op dezelfde manier "anders noteren"? Zodat je dus dubbele winst krijgt.