WFL Wetenschap, Filosofie, Levensbeschouwing
Discussieer hier over alle aspecten van de wetenschap, filosofische problemen en zaken van levensbeschouwelijke aard.
Dat is geen eerlijke vergelijking.quote:Op vrijdag 22 juli 2005 17:01 schreef BUG80 het volgende:
Weet je wat, ik geef even een voorbeeld. Het volgende is een willekeurig bestand van 10 bytes:
[..]
Als ik dit omzet naar (ASCII) getallen wordt het:
[..]
In getallen 0-9 heeft het dus een lengte van 27 bytes. Jouw applet geeft:
[..]
Kortom, hij vergroot het bestand van 10 naar 21 bytes!!
In je eerste stap, als je het omzet naar ASCII, zeg je "dit getal heeft een lengte van 27 bytes". Maar op die manier hangt het van de data af, als er veel bytes met ascii waarde onder de 100 in zitten worden het veelal getallen van 2 decimalen, en veel boven de 100, dan 3.
Je moet het hele bestand als één groot getal zien: 78 + 256*139 + 2562*39 + ... enz
Vervolgens, als hij een getal van 27 decimalen comprimeert naar 21 decimalen, kun je niet zeggen "dat zijn 21 bytes, en da's groter dan 10". Dat getal van 21 decimalen moet je dan weer splitsen in ASCII waarden en die bytes schrijf je weg. Dat zijn er dan veel minder dan 21. Zo begon je tenslotte ook met je oorspronkelijke bestand.
Dus je schrijft een byte weg met de waarde (getal mod 256), en vervolgens deel je het getal door 256 (afronden naar beneden). Dit herhaal je tot je nul overhoudt.
Overigens heeft deze methode van het interpreteren van een bestand als getal nog het probleem dat je geen verschil kunt zien tussen een bestand bestaande uit twee nul-bytes of uit tweehonderd nul-bytes.
Birthdays are good for you: the more you have, the longer you live.
Er is geen restant...quote:Op vrijdag 22 juli 2005 17:37 schreef gnomaat het volgende:
[..]
Maar wat heeft dat voor zin, dan kun je alleen data (getallen) van precies die vorm compressen, of anders maakt het restant wat je ook nog moet compressen het totaal groter dan het origineel.
Ik heb dit met een random generator gedaan, het viel toevallig hoog uit. De verwachtingswaarde voor de lengte van een ASCII getal is (100*1 + 100*2 + 56*3)/256 = 1,82 decimalen.quote:Op vrijdag 22 juli 2005 17:45 schreef gnomaat het volgende:
[..]
Dat is geen eerlijke vergelijking.
In je eerste stap, als je het omzet naar ASCII, zeg je "dit getal heeft een lengte van 27 bytes". Maar op die manier hangt het van de data af, als er veel bytes met ascii waarde onder de 100 in zitten worden het veelal getallen van 2 decimalen, en veel boven de 100, dan 3.
Dat doet het applet van Gelly ook precies, dus volgens mij is dit wel een eerlijke vergelijking.quote:Vervolgens, als hij een getal van 27 decimalen comprimeert naar 21 decimalen, kun je niet zeggen "dat zijn 21 bytes, en da's groter dan 10". Dat getal van 21 decimalen moet je dan weer splitsen in ASCII waarden en die bytes schrijf je weg. Dat zijn er dan veel minder dan 21. Zo begon je tenslotte ook met je oorspronkelijke bestand.
edit: Het applet van Gelly schrijft '186' dus weg als 1 ASCII byte i.p.v. "1", "8" en "6".
Mijn mixtape: labtones.com/listener/JSP
Hij bedoelt met restant: alles wat niet in de range 0-9 valt.quote:
Mijn mixtape: labtones.com/listener/JSP
Dat kan omdat dat 'karakter' onderdeel is van een groter getal.quote:Op vrijdag 22 juli 2005 17:50 schreef BUG80 het volgende:
[..]
edit: Het applet van Gelly schrijft '186' dus weg als 1 ASCII byte i.p.v. "1", "8" en "6".
Snap je wat ik bedoel met mijn getallenvoorbeeld? Dat bestand van 10 bytes?quote:Op vrijdag 22 juli 2005 17:56 schreef gelly het volgende:
[..]
Dat kan omdat dat 'karakter' onderdeel is van een groter getal.
Mijn mixtape: labtones.com/listener/JSP
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 donderdag 21 juli 2005 15:48 schreef Danny het volgende:
[..]
Veel getallen die je niet in 1 notatie samen kunt vatten kun je wellicht wel in meerdere wiskundige notaties samenvatten waar je dan na bewerking (optellen bv) WEL het juiste getal uitkrijgt.
Zelfs al zou je een getal van 20 miljoen cijfers dan moeten opdelen is 10.000 van die korte notaties heb je alsnog van 20Mb 100Kb gemaakt.
fotoboek.fok.nl/-erwin-
Ik heb geen respect voor gelovigen en hun geloof.
Mijn posts reflecteren niet noodzakelijkerwijs mijn mening.
Ik heb geen respect voor gelovigen en hun geloof.
Mijn posts reflecteren niet noodzakelijkerwijs mijn mening.
Klopt. Echter is 4kb daarvoor veel en veel te klein. Zelfs met 1 film kun je door alle scenes in andere volgordes te zetten al bijna genoeg verschillende mogelijkheden produceren om 4kb vol te krijgen. Laat staan dat je alle mogelijke films zou kunnen opslaan op die manier.quote:Op vrijdag 22 juli 2005 15:02 schreef BUG80 het volgende:
[..]
Wat dat betreft ben ik het helemaal met je eens, maar ben jij het met mij eens dat als je in het bezit bent van een soort super database/Huffman tree (die niet bestaat denk ik), het dan wel mogelijk moet zijn om veel verder te comprimeren dan dat, zolang je die database maar apart opslaat.
Voor mij staan een aantal zaken als een paal boven water.
1. Het is een lossy compressie.
2. 4kb is onmogelijk. Ordes in de tientallen danwel honderden megabytes lijken aannemelijker.
3. De grootte van de data ligt niet vast. Langere film betekent meer data.
4. Het systeem heeft waarschijnlijk nooit bestaan.
fotoboek.fok.nl/-erwin-
Ik heb geen respect voor gelovigen en hun geloof.
Mijn posts reflecteren niet noodzakelijkerwijs mijn mening.
Ik heb geen respect voor gelovigen en hun geloof.
Mijn posts reflecteren niet noodzakelijkerwijs mijn mening.
Okee, dan heb ik twee briljante manieren om files te compressen:quote:Op vrijdag 22 juli 2005 17:50 schreef BUG80 het volgende:
Ik heb dit met een random generator gedaan, het viel toevallig hoog uit. De verwachtingswaarde voor de lengte van een ASCII getal is (100*1 + 100*2 + 56*3)/256 = 1,82 decimalen.
1. Schrijf een bestand 1000 bytes uit als decimalen zoals bovenstaand. Naar verwachting krijg je dan zo'n 1828 decimalen (hangt natuurlijk van je bestand af, maar gemiddeld).
Aangezien je makkelijk 2 decimalen per byte kunt opslaan (dat worden bytes met ascii waarden 0 t/m 99) heb je dus 914 bytes nodig om die decimalen weer op te slaan. Blijft over: 914/1000 = 91%. Dit is recursief toepasbaar.
2. Voordat je dit doet tel je eerst de frequentie van alle bytes. Vervolgens verwissel je de bytes zodat de meest veelvoorkomende bytes de laagste ascii waarden krijgen. Op die manier heb je zoveel mogelijk bytes die zo min mogelijk decimalen kosten. Het verwisselen kost enkel een re-map tabel van 256 bytes, ongeacht hoe groot het bestand.
En, zie je al waar de fout zit?
Birthdays are good for you: the more you have, the longer you live.
Gelly, om inzicht te krijgen in het feit dat je methode niet doet wat je claimt stel ik voor dat je een willekeurig inputbestand genereert dat je vervolgens comprimeert met jou methode waarna je het decomprimeert en vergelijkt met het origineel. Kijk dan eens naar de compressie ratio.
Alleen als het precies een groot priemgetal is.quote:Op vrijdag 22 juli 2005 17:49 schreef gelly het volgende:
Er is geen restant...
Als de input data bijvoorbeeld 618970019642690137449562111 is, dan kun je volstaan met "89" (omdat 289-1 = dat getal), of zelfs "9" (omdat 289-1 het tiende Mersenne priemgetal is en je begint te tellen vanaf 0).
Maar dat is een zeer uitzonderlijke input. Wat nu als de input bijvoorbeeld 761825315945362690850838009 is?
Birthdays are good for you: the more you have, the longer you live.
Oh ja dit klopt trouwens ook niet helemaal:
Maar dat was niet eens de grootste fout in mijn "briljante" nieuwe compressiemethode van hierboven
Moet zijn (10*1 + 90*2 + 156*3)/256 = 2.57 decimalen gemiddeld per byte.quote:Op vrijdag 22 juli 2005 17:50 schreef BUG80 het volgende:
Ik heb dit met een random generator gedaan, het viel toevallig hoog uit. De verwachtingswaarde voor de lengte van een ASCII getal is (100*1 + 100*2 + 56*3)/256 = 1,82 decimalen.
Maar dat was niet eens de grootste fout in mijn "briljante" nieuwe compressiemethode van hierboven
Birthdays are good for you: the more you have, the longer you live.
Ehh nee. Volgens mij heb je zojuist gewoon een eerste opzet voor een Huffman tree ontworpen, alleen dan met behulp van bytes ipv bits of ik mis ietsquote:Op vrijdag 22 juli 2005 18:30 schreef gnomaat het volgende:
[..]
Okee, dan heb ik twee briljante manieren om files te compressen:
1. Schrijf een bestand 1000 bytes uit als decimalen zoals bovenstaand. Naar verwachting krijg je dan zo'n 1828 decimalen (hangt natuurlijk van je bestand af, maar gemiddeld).
Aangezien je makkelijk 2 decimalen per byte kunt opslaan (dat worden bytes met ascii waarden 0 t/m 99) heb je dus 914 bytes nodig om die decimalen weer op te slaan. Blijft over: 914/1000 = 91%. Dit is recursief toepasbaar.
2. Voordat je dit doet tel je eerst de frequentie van alle bytes. Vervolgens verwissel je de bytes zodat de meest veelvoorkomende bytes de laagste ascii waarden krijgen. Op die manier heb je zoveel mogelijk bytes die zo min mogelijk decimalen kosten. Het verwisselen kost enkel een re-map tabel van 256 bytes, ongeacht hoe groot het bestand.
En, zie je al waar de fout zit?
of ik mis ietsEn inderdaad de verwachtingswaarde voor de lengte in decimalen van een ASCII waarde is 2.57, mijn fout, sorry
[edit]Methode 1 vervalt dus al, aangezien gemiddeld genomen je bestanden groter worden met deze methode. Je bestand van 1000 bytes worden 2570 decimalen. Dit gedeeld door 2 = 1285[/edit]
Waar het verhaal van Gelly fout gaat is het volgende: hij comprimeert decimalen terug naar bytes met behulp van ontbinding in priemgetallen, in plaats van bytes naar bytes, wat veel eerlijker zou zijn. Dat is wat ik probeer duidelijk te maken.
[ Bericht 5% gewijzigd door BUG80 op 22-07-2005 19:13:49 ]
Mijn mixtape: labtones.com/listener/JSP
Probeer anders eens het volgende bestand te comprimeren met behulp van de methode van Gelly, je zult zien dat het groter wordt:
Ik heb expres 'leesbare' karakters gebruikt. Succes.quote:x6YNsgK#mJ
Mijn mixtape: labtones.com/listener/JSP
Nogmaals, volgens mij bedoelde hij niet restant als in "modulo", maar het restant als je alleen de decimalen in een bestand comprimeert. Een gemiddeld bestand bestaat namelijk uit veel meer dan alleen decimalen.quote:Op vrijdag 22 juli 2005 18:45 schreef gnomaat het volgende:
[..]
Alleen als het precies een groot priemgetal is.
Als de input data bijvoorbeeld 618970019642690137449562111 is, dan kun je volstaan met "89" (omdat 289-1 = dat getal), of zelfs "9" (omdat 289-1 het tiende Mersenne priemgetal is en je begint te tellen vanaf 0).
Maar dat is een zeer uitzonderlijke input. Wat nu als de input bijvoorbeeld 761825315945362690850838009 is?
Mijn mixtape: labtones.com/listener/JSP
Dit is ook een ruwe opzet hoor, ben nog druk bezig te kijken wat het beste werkt. Je kunt je voorstellen dat je door het scannen van datareeksen getallen tegenkomt die je door een veel kortere notatie kunt vervangen. Een combinatie van verschillende logaritmen moet zeker een forse compressie oplever mijns inziens.quote:Op vrijdag 22 juli 2005 18:45 schreef gnomaat het volgende:
[..]
Alleen als het precies een groot priemgetal is.
Als de input data bijvoorbeeld 618970019642690137449562111 is, dan kun je volstaan met "89" (omdat 289-1 = dat getal), of zelfs "9" (omdat 289-1 het tiende Mersenne priemgetal is en je begint te tellen vanaf 0).
Maar dat is een zeer uitzonderlijke input. Wat nu als de input bijvoorbeeld 761825315945362690850838009 is?
Gelly, please
Je vergelijkt appels met peren. Je begint met decimalen met een bandbreedte van 0-9, die je vervolgens ontbindt in priemgetallen, die je opslaat als bytes in bandbreedte 0-255. Vind je het gek dat je compressie bereikt.
Neem het volgende getal (lengte 22 decimalen):
179 28 73 102 92 83 38 39 238 2
Nou zijn het er ineens nog maar 10! Kortom met de hand bereik ik meer compressie dan met jouw methode!
Je vergelijkt appels met peren. Je begint met decimalen met een bandbreedte van 0-9, die je vervolgens ontbindt in priemgetallen, die je opslaat als bytes in bandbreedte 0-255. Vind je het gek dat je compressie bereikt.
Neem het volgende getal (lengte 22 decimalen):
Jouw applet maakt daar 16 priemgetallen van, die je opslaat als bytes met waarde 0-255. Met de hand kan ik er echter ook bytes van maken:quote:1792873102928338392382
179 28 73 102 92 83 38 39 238 2
Nou zijn het er ineens nog maar 10! Kortom met de hand bereik ik meer compressie dan met jouw methode!
Mijn mixtape: labtones.com/listener/JSP
Gemiddeld levert dat minder winst op dan de extra ruimte die het je kost om de metadata voor zo'n notatie op te slaan. Ongeacht je methode of het type korte notatie dat je gebruikt.quote:Op vrijdag 22 juli 2005 19:35 schreef gelly het volgende:
Dit is ook een ruwe opzet hoor, ben nog druk bezig te kijken wat het beste werkt. Je kunt je voorstellen dat je door het scannen van datareeksen getallen tegenkomt die je door een veel kortere notatie kunt vervangen. Een combinatie van verschillende logaritmen moet zeker een forse compressie oplever mijns inziens.
Maar goed, mijn challenge staat nog steeds, werk je idee gerust uit. Als je een appje weet te bakken dat mijn 10KB bestand onder de 9 KB krijgt (dus een file van maximaal 9216 bytes) dan
Birthdays are good for you: the more you have, the longer you live.
gnomaat, kun je deze vraag nog even beantwoorden?quote:Op vrijdag 22 juli 2005 18:30 schreef gnomaat het volgende:
En, zie je al waar de fout zit?
Mijn mixtape: labtones.com/listener/JSP
Hint: als het decimale getal 112131032202120121 is, van welke ascii waardes komt dat dan? (m.a.w. welke originele file hoort hierbij?)quote:Op vrijdag 22 juli 2005 20:22 schreef BUG80 het volgende:
gnomaat, kun je deze vraag nog even beantwoorden?
Birthdays are good for you: the more you have, the longer you live.
Bedoel je dat één getallenreeks kan staan voor meerdere ASCII files?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?)
Ok, dan moet je dus inderdaad werken met A0 + 256*A1 + 2562*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 ]
Mijn mixtape: labtones.com/listener/JSP
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.
Dit figuur is met een paar regels code te maken, het opgeslagen plaatje kost veel meer ruimte dan de broncode.
[ alle babes op 1 pagina via fok!wiki -bijgewerkt tot 20/10/2015 ]
Leve Kim , Leve Maduro , Leve Castro
#freeTarik #freeDemon_from_heaven
Leve Kim , Leve Maduro , Leve Castro
#freeTarik #freeDemon_from_heaven
Nog langer dan iets wat niet werkt ja, dus je moet welquote: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 + 2562*A3, enz.., met Ai de ASCII waarde van karakter 'i', maar dat maakt het uiteindelijke getal toch alleen maar nog langer?
Birthdays are good for you: the more you have, the longer you live.
Ja, dat is waar.quote:Op zaterdag 23 juli 2005 00:10 schreef gnomaat het volgende:
[..]
Nog langer dan iets wat niet werkt ja, dus je moet wel
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.
Mijn mixtape: labtones.com/listener/JSP
jaja, maar, dat zegt niet zoveel.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.
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.
In Baden-Badener Badeseen kann man Baden-Badener baden sehen.
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: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.
fotoboek.fok.nl/-erwin-
Ik heb geen respect voor gelovigen en hun geloof.
Mijn posts reflecteren niet noodzakelijkerwijs mijn mening.
Ik heb geen respect voor gelovigen en hun geloof.
Mijn posts reflecteren niet noodzakelijkerwijs mijn mening.
Ehm, meer dan 232768 films. En dat zijn er heel wat meer dan er ooit gemaakt zullen wordenquote: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.
Birthdays are good for you: the more you have, the longer you live.
Natuurlijk, die priemgetallen zijn hetzelfde als "onze" priemgetallen.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?
Het priem zijn van getallen hangt niet af van het talstelsel waarin je ze noteert.
Ik weet het wel zekerquote:Alleen ben ik bang dat de volgende stelling geldig is: Ontbinding van een getal in andere getallen zal gemiddeld genomen niet tot compressie leiden.
Birthdays are good for you: the more you have, the longer you live.
ahum. mijn fout ik zal hem maar niet editen, anders lijkt het zo raar. goede morgenquote:Op zaterdag 23 juli 2005 12:45 schreef gnomaat het volgende:
[..]
Ehm, meer dan 232768 films. En dat zijn er heel wat meer dan er ooit gemaakt zullen worden
fotoboek.fok.nl/-erwin-
Ik heb geen respect voor gelovigen en hun geloof.
Mijn posts reflecteren niet noodzakelijkerwijs mijn mening.
Ik heb geen respect voor gelovigen en hun geloof.
Mijn posts reflecteren niet noodzakelijkerwijs mijn mening.
Neem een bakkie koffie zou ik zeggenquote: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
Mijn mixtape: labtones.com/listener/JSP
Stel dat de code bestaat, alsnog had geen enkele laptop in die tijd de benodigde rekenkrecht voorhet direct afspelen van 16 filmen simultaan
gezellig!
Ja ik ook, gevoelsmatig. Heb je toevallig een link naar een wiskundig bewijs?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
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.
Mijn mixtape: labtones.com/listener/JSP
Als zowel beeld als geluid ongecomprimeerd zijn zou het wel moeten kunnen, toch? Maarja, ze waren wel gecomprimeerd, dat is juist het punt.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
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.
Mijn mixtape: labtones.com/listener/JSP
en dan heb je 1 0 bit´s per filmquote:Op zaterdag 23 juli 2005 12:45 schreef gnomaat het volgende:
[..]
Ehm, meer dan 232768 films. En dat zijn er heel wat meer dan er ooit gemaakt zullen worden
De 232768 posities zijn dan alleen maar het catalogusnummer, je hebt niets meer over om informatie van de film op te slaan
In Baden-Badener Badeseen kann man Baden-Badener baden sehen.
Maar goed, ik zie eigenlijk alleen maar het herkauwen van de dingen die in de vorige topics al uitvoerig herkauwt zijn.
In Baden-Badener Badeseen kann man Baden-Badener baden sehen.
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 13:03 schreef Pietverdriet het volgende:
en dan heb je 1 0 bit´s per film
De 232768 posities zijn dan alleen maar het catalogusnummer, je hebt niets meer over om informatie van de film op te slaan
Birthdays are good for you: the more you have, the longer you live.
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: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.
Birthdays are good for you: the more you have, the longer you live.
Nee zo niet, maar moet niet al te moeilijk zijn.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?
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?
Birthdays are good for you: the more you have, the longer you live.
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: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?
Mijn mixtape: labtones.com/listener/JSP
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: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?
In Baden-Badener Badeseen kann man Baden-Badener baden sehen.
Say what! Was het NEP?!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.
Ik weet het, maar ik bedoelde: wat werd er gesuggereerd door Jan Sloot
Birthdays are good for you: the more you have, the longer you live.
Ik heb wiskundig bewijs dat Sloots verhaal niet kan kloppen.
Een sleutel van 128 kilobyte kan 2128*1024*8 = 21048576 verschillende waarden aannemen. Ik ga er even vanuit dat Sloot zijn algoritme volledig optimaal werkt, dus met die sleutel kan hij 21048576 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 23 = 8
Voor een plaatje van x pixels en y kleurwaarden per pixel is het aantal mogelijkheden yx
Voor een plaatje van 640x480 = 307200 pixels met 216 = 65536 mogelijke kleurwaarden is het aantal mogelijkheden dus 65536307200 = (216)307200 = 24915200
Zoals je kan zien zijn er 24915200/21048576 = 23866624 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
216 mogelijkheden per pixel
Totaal: (216)41472000000 = 2663552000000 mogelijkheden.
Wat Sloot dus al die tijd heeft beweerd is dat 128kilobyte alle 2663552000000 mogelijke films zou kunnen bevatten. Sure...
Een sleutel van 128 kilobyte kan 2128*1024*8 = 21048576 verschillende waarden aannemen. Ik ga er even vanuit dat Sloot zijn algoritme volledig optimaal werkt, dus met die sleutel kan hij 21048576 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 23 = 8
Voor een plaatje van x pixels en y kleurwaarden per pixel is het aantal mogelijkheden yx
Voor een plaatje van 640x480 = 307200 pixels met 216 = 65536 mogelijke kleurwaarden is het aantal mogelijkheden dus 65536307200 = (216)307200 = 24915200
Zoals je kan zien zijn er 24915200/21048576 = 23866624 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
216 mogelijkheden per pixel
Totaal: (216)41472000000 = 2663552000000 mogelijkheden.
Wat Sloot dus al die tijd heeft beweerd is dat 128kilobyte alle 2663552000000 mogelijke films zou kunnen bevatten. Sure...
dat is evident.quote:Op dinsdag 26 juli 2005 00:31 schreef DirtyHarry het volgende:
Ik heb wiskundig bewijs dat Sloots verhaal niet kan kloppen.
fotoboek.fok.nl/-erwin-
Ik heb geen respect voor gelovigen en hun geloof.
Mijn posts reflecteren niet noodzakelijkerwijs mijn mening.
Ik heb geen respect voor gelovigen en hun geloof.
Mijn posts reflecteren niet noodzakelijkerwijs mijn mening.
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: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
216 mogelijkheden per pixel
Totaal: (216)41472000000 = 2663552000000 mogelijkheden.
So this is how liberty dies... with thunderous applause.
Truth? What's so great about the truth? Try lying for a change, it's the currency of the world
Truth? What's so great about the truth? Try lying for a change, it's the currency of the world
lossy compressionquote: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...
fotoboek.fok.nl/-erwin-
Ik heb geen respect voor gelovigen en hun geloof.
Mijn posts reflecteren niet noodzakelijkerwijs mijn mening.
Ik heb geen respect voor gelovigen en hun geloof.
Mijn posts reflecteren niet noodzakelijkerwijs mijn mening.
Maar ik geloof dat uit Sloot zijn "paper" ( ) niet te destilleren valt of hij nu wel of geen lossy compressie gebruikt of niet.quote:
) niet te destilleren valt of hij nu wel of geen lossy compressie gebruikt of niet.
So this is how liberty dies... with thunderous applause.
Truth? What's so great about the truth? Try lying for a change, it's the currency of the world
Truth? What's so great about the truth? Try lying for a change, it's the currency of the world
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: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...
Hij zei dat ie verliesloos (pixel voor pixel) een film weer kon laten zienquote: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.
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.
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.
Op zaterdag 7 oktober 2006 14:56 schreef Friek_ het volgende:
Nu kon ik het niet laten om even snel op je Fotoboek te kijken en ik zag wat ik al dacht: een onzeker beta-studentje.
Nu kon ik het niet laten om even snel op je Fotoboek te kijken en ik zag wat ik al dacht: een onzeker beta-studentje.
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 00:36 schreef -erwin- het volgende:
lossy compression
Op zaterdag 7 oktober 2006 14:56 schreef Friek_ het volgende:
Nu kon ik het niet laten om even snel op je Fotoboek te kijken en ik zag wat ik al dacht: een onzeker beta-studentje.
Nu kon ik het niet laten om even snel op je Fotoboek te kijken en ik zag wat ik al dacht: een onzeker beta-studentje.
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?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.
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.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?
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.
Mijn mixtape: labtones.com/listener/JSP
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: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.
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: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.
Ik bedoel alleen maar dat je bewijs geen bewijs is. Je zegt het volgende: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.
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.
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.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.
Mijn mixtape: labtones.com/listener/JSP
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?
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?
Mijn mixtape: labtones.com/listener/JSP
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.
Het leven is als een pisvlek in de zwarte pantalon van de eeuwigheid.
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.
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.
Mijn mixtape: labtones.com/listener/JSP
Neuhquote: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.
Op zaterdag 7 oktober 2006 14:56 schreef Friek_ het volgende:
Nu kon ik het niet laten om even snel op je Fotoboek te kijken en ik zag wat ik al dacht: een onzeker beta-studentje.
Nu kon ik het niet laten om even snel op je Fotoboek te kijken en ik zag wat ik al dacht: een onzeker beta-studentje.
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 22x2 = 24, 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
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 22x2 = 24, 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
|
|
