quote:Game onOp dinsdag 19 juli 2005 00:36 schreef Danny het volgende:
even voor de duidelijkheid, de man [Jan Sloot] had een uitvinding waarmee hij een bestand van welk formaat dan ook kon terugbrengen tot 64Kb én in real-time kon uitpakken zonder verlies ! Hij stierf de dag voordat hij miljardair werd en zijn uitvinding zou verkopen en nam 'de broncode' mee het graf in.
quote:Wie weet. De man was hartpatient, en officieel is hij aan een hartaanval overleden. Of hij een handje geholpen is daarbij valt ook niet uit te sluiten - je wekt er nog geen argwaan mee ook.Op donderdag 21 juli 2005 00:29 schreef SunChaser het volgende:
Ik wil nog steeds de uitzending zien of t boek lezen. Wat ik er tot nu toe van begreep is dat ie is geliquedeerd door Phillips omdat hun mediadragers dan in 1 klap overbodig zouden worden
.Ook is opvallend te noemen dat vlak na zijn dood, zijn hele werkkamer (wat normaal gesproken een teringbende was) compleet was opgeruimd en geen spoor meer van de uitvinding zelf of zijn notities.
quote:In het vorige topic had iemand erover dat ie door de makers van WinZip is vermoord!Op donderdag 21 juli 2005 00:29 schreef SunChaser het volgende:
Ik wil nog steeds de uitzending zien of t boek lezen. Wat ik er tot nu toe van begreep is dat ie is geliquedeerd door Phillips omdat hun mediadragers dan in 1 klap overbodig zouden worden
.)Vandaar ook dat compressie (uberhaupt, alle vormen van datareductie, of Sloot het nu wel of geen compressie noemt is irrelevant) gebaseerd is op het principe: we reduceren sommige bestanden van X bytes tot een grootte die kleiner is dan X bytes, ten koste van de minder waarschijnlijke bestanden, die meer dan X bytes zullen moeten innemen.
Deze reductie staat of valt met de hoeveelheid informatie die in zo'n bestand is opgeslagen, de zgn. Entropie (bedacht door Shannon). En de entropie hangt af van de mate van voorspelbaarheid van deze gegevens. Hoge voorspelbaarheid -> lage entropie -> grote compressie. Lage voorspelbaarheid of onwaarschijnlijke combinatie gegevens -> hoge entropie -> expansie.
Gegeven de kansverdeling op het aantal mogelijke bestanden, kan men de bijbehorende entropie uitrekenen en, voor een bepaald bestand een zekere compressie bereiken.
Het feit dat deze maat van informatie, entropie, ook echt een absolute ondergrens bepaalt volgt uit inductie: stel dat elk bestand van X bytes teruggebracht kan worden tot een bestand van X-1 bytes. Wat let je om hetzelde algoritme nog een keer toe te passen op dat bestand van X-1 bytes om het te comprimeren tot X-2 bytes? Niks. En dan kan je dat nog een keer doen tot X-3 bytes, etc.
Net zolang totdat de bestandsgrootte 0 nadert. Iets wat pertinent onmogelijk is, omdat er zeker meer dan 256 films / bestanden bestaan.
Ergo: er moet wel een harde ondergrens bestaan aan de mate waarin je bestanden kunt comprimeren.
Misschien interessant: http://nl.wikipedia.org/wiki/Illegaal_priemgetal
quote:Sterker nog, daar is ooit een product van op de markt geweest. Als alternatief voor de computer tape recorder voor backups. Van wat ik met herinner van de test in de computer!totaal werkte het niet helemaal denderend.Dat idee had ik jaren geleden al in een andere vorm. Dataopslag op videobanden, en dan niet het magnetische spoor uitlezen, maar de pixels op het beeldscherm. 256 kleuren * bepaalde intensiteit * resolutie van opname. Dat is nogal wat data per frame.
quote:What's the fucking difference, hebben we het nu over een film die in 4Kb past ja of nee!Op donderdag 21 juli 2005 00:51 schreef Lynx666 het volgende:
*hamer* coderen *hamer*
quote:Inderdaad. Al sluit dit de mogelijkheid van het comprimeren van films tot 4 Kb nog niet direct uit: het aantal mogelijke sleutels van 32768 bits is veel groter dan alle films die ooit gemaakt zijn of de komende paar honderd jaar gemaakt zullen worden.Op donderdag 21 juli 2005 00:47 schreef HenryHill het volgende:
Ergo: er moet wel een harde ondergrens bestaan aan de mate waarin je bestanden kunt comprimeren.
Dus wat betreft kun je in de praktijk iedere film wel coderen als (of liever gezegd identificeren met) een unieke sleutel van 4 Kb. Ten koste van 10biljarden theoretische "films" met random noise of wat voor niet bestaande content dan ook, die je hiermee niet zou kunnen coderen of alleen groter kunt maken.
quote:Wil je een beetje in de buurt komen van wat ie gefabriceerd heeft, zul je toch op zijn manier moeten denken. Van het volgen van bekende denkwijzen is nog nooit iemand uitvinder geworden.Op donderdag 21 juli 2005 00:54 schreef gnomaat het volgende:
[..]
What's the fucking difference, hebben we het nu over een film die in 4Kb past ja of nee!
.k*256211+99
da's toch geen onaardige compressiefactor lijkt me
quote:Zoiets denk ik ja.Op donderdag 21 juli 2005 01:01 schreef SunChaser het volgende:
Maar leg eens uit in N00b-taal. Een complete film wordt compleet uit elkaar gehaald en door een sleutel weer in elkaar gezet? Net zoals Star Trek? Dat je een lichaam upbeamt, dus molecuul voor molecuul afbreekt en door een unieke steutel elders weer in elkaar zet?
Volgens mij moet je het zo zien:
A = B * C
Als je A (de uiteindelijke) wilt berekenen, en * C is een vaste waarde (het algoritme ofzo) dan moet je B invullen (de 'gezipte' film). Andersom kan dat dus ook als je B wilt berekenen door A in te vullen. Het algoritme C blijft natuurlijk hetzelfde.
Ik hoop dat dat simpel genoeg was, en dat ikzelf geen foute dingen verkondig
[ Bericht 4% gewijzigd door Boes-Poes op 21-07-2005 01:10:58 ]
quote:In dat geval zou je dus eigenlijk vrij simpel (met ENORM veel rekenkracht) ELK ge-gzipt bestand kunnen omrekenen naar een priemgetal en deze weergeven in slechts een paar bytes.Op donderdag 21 juli 2005 01:02 schreef Danny het volgende:
Dus de complete ge-gzipte DeCSS code kun je samenvatten met
k*256211+99
da's toch geen onaardige compressiefactor lijkt me
Met een de-priem programma zou je het priemgetal weer kunnen omzetten in de nullen en enen waarna je datzelfde bestand in g-zip formaat hebt. Uitpakken en je film, filmcollectie, complete harddisk etc is weer compleet.
quote:Natuurwetten zijn nog nooit gebroken. Hooguit is het model van de natuurwetten aangepast aan de nieuwste bevindingen (zoals tegenwoordig bekend is dat atomen ook weer zijn samengesteld uit iets van 6 sub-atomaire deeltjes. Geloof ik).Op donderdag 21 juli 2005 00:59 schreef Lynx666 het volgende:
[..]
Wil je een beetje in de buurt komen van wat ie gefabriceerd heeft, zul je toch op zijn manier moeten denken. Van het volgen van bekende denkwijzen is nog nooit iemand uitvinder geworden.
Echter, compressie is een wiskundig gedefinieerd probleem. En de wetten van wiskunde zijn ook nog nooit gebroken, maar er bestaat geen enkele uitbreiding die de basisprincipes van de wiskunde ongedaan kunnen maken of er op een andere manier langsheen kunnen glippen. Dat komt omdat wiskunde, in tegenstelling tot natuurkunde, niet berust op een model maar op pure logica.
quote:Simpel gezegd codeert de uitvinding van Sloot een willekeurige film via bepaalde algoritmen (hij maakt gebruik van 5 algoritme-blokken van elk 74MB) naar een sleutel van 64KB, ongeacht de lengte van de film. Die sleutel biedt ie aan aan het decoderingsprogramma en hij kan razendsnel de oorspronkelijke video laten afspelen, en ook razendsnel voor- en achteruit spelen zonder vertragingen of kwaliteitsverlies.Op donderdag 21 juli 2005 01:01 schreef SunChaser het volgende:
Maar leg eens uit in N00b-taal. Een complete film wordt compleet uit elkaar gehaald en door een sleutel weer in elkaar gezet? Net zoals Star Trek? Dat je een lichaam upbeamt, dus molecuul voor molecuul afbreekt en door een unieke steutel elders weer in elkaar zet?
Het klinkt allemaal onmogelijk, maar wat mij dwars zit is dat hij de grootste technische bazen over de wereld versteld doet staan, niemand heeft 'm op oplichting kunnen betrappen- zijn kastje wèrkt. Hij is gestorven met de eerste miljoen al in de pocket.
quote:Dat zou moeten inhouden dat elk priemgetal die er tot nu toe gevonden is vastzit aan een vaststaande reeks enen en nullen om steeds hetzelfde bestand er weer uit te krijgen. Dit klinkt erg tegenstrijdig.Op donderdag 21 juli 2005 01:05 schreef Danny het volgende:
[..]
In dat geval zou je dus eigenlijk vrij simpel (met ENORM veel rekenkracht) ELK ge-gzipt bestand kunnen omrekenen naar een priemgetal en deze weergeven in slechts een paar bytes.
Met een de-priem programma zou je het priemgetal weer kunnen omzetten in de nullen en enen waarna je datzelfde bestand in g-zip formaat hebt. Uitpakken en je film, filmcollectie, complete harddisk etc is weer compleet.
quote:Breng eens een bugfix uit voor het programma, waarvoor 1 instructie (1 a 2 bytes) veranderd moeten worden. En weg is je wiskundige expressie voor dat programma - en dus ook de bijbehorende compressie.Op donderdag 21 juli 2005 01:02 schreef Danny het volgende:
Dus de complete ge-gzipte DeCSS code kun je samenvatten met
k*256211+99
da's toch geen onaardige compressiefactor lijkt me
Dat is het hele idee achter compressie: sommige bestanden kunnen belachelijk klein worden gemaakt, ten koste van een hele hoop andere bestanden die onvermijdelijk groter zullen moeten worden.
quote:Algoritmes zijn methodes. Bepaalde regeltjes en volgorde hiervan voor bijvoorbeeld het berekenen van dingen. Dus ik denk wel dat ze algoritmes gaan gebruiken ja.Op donderdag 21 juli 2005 01:11 schreef SunChaser het volgende:
Gaan ze algoritmes ook niet gebruiken om aan de hand van foto's en afbeeldingen op het internet te kunnen zoeken?
quote:Zoals ik al eerder zei:Op donderdag 21 juli 2005 01:05 schreef Danny het volgende:
[..]
In dat geval zou je dus eigenlijk vrij simpel (met ENORM veel rekenkracht) ELK ge-gzipt bestand kunnen omrekenen naar een priemgetal en deze weergeven in slechts een paar bytes.
Met een de-priem programma zou je het priemgetal weer kunnen omzetten in de nullen en enen waarna je datzelfde bestand in g-zip formaat hebt. Uitpakken en je film, filmcollectie, complete harddisk etc is weer compleet.
Niet ieder priemgetal is samen te vatten in een simpele formule als 2^n-1.. De theorie is inderdaad dat elk natuurlijk getal opgebouwd kan worden uit vermenigvuldigingen van priemgetallen, maar als die priemgetallen niet kort 'samen te vatten' zijn levert dat geen compressie op.
En nu is t tijd om te
quote:Maar als je dan aangeeft dat er van een bepaald priemgetal een samenvatting moet zijn tot een bepaald aantal cijfers. Dus er komt 101010 uit, en je geeft aan dat hij maximaal 4 cijfers mag geven. Dus word het 1010.Op donderdag 21 juli 2005 01:32 schreef Ravage het volgende:
[..]
... maar als die priemgetallen niet kort 'samen te vatten' zijn levert dat geen compressie op...
Dan behaal je over het algemeen nog steeds compressie volgens mij. Tenzij je dingen probeert te comprimeren die kleiner zijn dan de notatie voor het aangeven van het gewenste priemgetal met de hoeveelheid cijfers.
quote:Comprimeren betekend gewoon samenpersen of compact maken. Jan sloot kan wel vinden dat zijn techniek geen compressie is, maar zijn methode voldoet aan de betekenis van het woord en we kunnen hier dus gewoon spreken van compressie.Op donderdag 21 juli 2005 00:51 schreef Lynx666 het volgende:
*hamer* coderen *hamer*
Het meest verbaast het me nog dat mensen maar blijven denken dat het mogelijk is dat het systeem van sloot werkt zonder in te gaan op een simpel wiskundig tegenargument (hier al meerdere keren genoemd overigens). Sloot heeft het zelf over sleutelgroottes uitgedrukt in bits. Een bit is per definitie de kleinst mogelijke informatieeenheid. Als je gelooft dat het systeem werkt dan zul je moeten geloven dat je met n bits meer dan 2^n verschillende bitstrings kunt representeren. Misschien kunnen de aanhangers van Sloot hier iets over zeggen.
Een andere optie is dat Sloot simpelweg een ordinaire oplichter was. Of hij heeft een compressie uitgevonden met kwaliteits verlies voor films. Een compressie systeem met kwaliteits verlies voor alle formaten lijkt me tenminste niet mogelijk aangezien je moet weten wat weggegooid kan worden.
quote:Ik weet niet of je mij daaronder rekent, maar ik kan je zeggen dat ik de laatste zal zijn die zegt dat via compressie een winst van 99,999% gehaald kan worden. Ik denk dat we voor compressie van beeld en geluid niet veel winst meer zullen boeken dat met de huidige divx/xvid formaten (en dat is nog lossy ook).Op donderdag 21 juli 2005 07:44 schreef Barati het volgende:
[..]
Het meest verbaast het me nog dat mensen maar blijven denken dat het mogelijk is dat het systeem van sloot werkt zonder in te gaan op een simpel wiskundig tegenargument (hier al meerdere keren genoemd overigens). Sloot heeft het zelf over sleutelgroottes uitgedrukt in bits. Een bit is per definitie de kleinst mogelijke informatieeenheid. Als je gelooft dat het systeem werkt dan zul je moeten geloven dat je met n bits meer dan 2^n verschillende bitstrings kunt representeren. Misschien kunnen de aanhangers van Sloot hier iets over zeggen.
Maar zoals ik al eerder zei; ik kan dit niet als 100% hoax afdoen, simpelweg omdat het kastje wèrkte. Hij liet dingen zien die toen zeker nog niet haalbaar waren. En hij is nooit ontmaskerd.
quote:Ik had de uitzending gezie op internet, weet alleen niet meer waar.Op donderdag 21 juli 2005 00:29 schreef SunChaser het volgende:
Ik wil nog steeds de uitzending zien of t boek lezen. Wat ik er tot nu toe van begreep is dat ie is geliquedeerd door Phillips omdat hun mediadragers dan in 1 klap overbodig zouden worden
Ik blijf het een mooi verhaal vinden, ben alleen benieuwd waar dat kastje en de broncode is gebleven.
quote:http://www.debroncode.nl/?section=audiovideo&lang=NLOp donderdag 21 juli 2005 11:09 schreef whosvegas het volgende:
[..]
Ik had de uitzending gezie op internet, weet alleen niet meer waar.
Ik blijf het een mooi verhaal vinden, ben alleen benieuwd waar dat kastje en de broncode is gebleven.
http://www.debroncode.nl/(...)0geen%20broncode.doc
quote:Die bedoel ik, mischien ga ik ze van het weekend nog eens bekijken.Op donderdag 21 juli 2005 11:13 schreef -Dominator- het volgende:
[..]
http://www.debroncode.nl/?section=audiovideo&lang=NL
quote:Wat Sloot liet zien is inderdaad verbazingwekkend. Maar hetgeen hij beweerde strookt niet met simpele wiskundige logica.Op donderdag 21 juli 2005 10:48 schreef Lynx666 het volgende:
[..]
Ik weet niet of je mij daaronder rekent, maar ik kan je zeggen dat ik de laatste zal zijn die zegt dat via compressie een winst van 99,999% gehaald kan worden. Ik denk dat we voor compressie van beeld en geluid niet veel winst meer zullen boeken dat met de huidige divx/xvid formaten (en dat is nog lossy ook).
Maar zoals ik al eerder zei; ik kan dit niet als 100% hoax afdoen, simpelweg omdat het kastje wèrkte. Hij liet dingen zien die toen zeker nog niet haalbaar waren. En hij is nooit ontmaskerd.
Sloot had ook hetzelfde kasje kunnen laten zien met de bewering dat een film in 1 bit gecodeerd zou kunnen worden. Zou je hem dan geloven?
De waarheid kan overigens ook nog in het midden liggen: Sloot was misschien geen oplichter maar hij vergiste zich en met zijn uitvinding kon hij comprimeren, maar niet in de verhouding die hij claimde . Voor een beter inzicht in zijn claims kun je kijken wat de consequenties ervan zijn. B.v. Alle data ter wereld is te comprimeren tot 1 sleutel.
quote:Inderdaad. Zien is niet altijd geloven. En als het klopt dat niemand behalve Sloot zelf het kastje van binnen heeft gezien tijdens de presentatie, kan hij van alles beweren.Op donderdag 21 juli 2005 11:29 schreef Barati het volgende:
[..]
Wat Sloot liet zien is inderdaad verbazingwekkend. Maar hetgeen hij beweerde strookt niet met simpele wiskundige logica.
Sloot had ook hetzelfde kasje kunnen laten zien met de bewering dat een film in 1 bit gecodeerd zou kunnen worden. Zou je hem dan geloven?
De waarheid kan overigens ook nog in het midden liggen: Sloot was misschien geen oplichter maar hij vergiste zich en met zijn uitvinding kon hij comprimeren, maar niet in de verhouding die hij claimde . Voor een beter inzicht in zijn claims kun je kijken wat de consequenties ervan zijn. B.v. Alle data ter wereld is te comprimeren tot 1 sleutel.
quote:Inderdaad.Op donderdag 21 juli 2005 12:27 schreef Pinobot het volgende:
Kan niet bestaat niet.
Het kan niet en het bestaat niet.
quote:"kan niet" kan niet?Op donderdag 21 juli 2005 12:27 schreef Pinobot het volgende:
Kan niet bestaat niet.
quote:Haha, dat is dus precies waar ik mee bezig benOp donderdag 21 juli 2005 00:50 schreef Boes-Poes het volgende:
Vreselijk veel vat ik er niet van hoor, maar dat priemgetallen idee is best slim eigenlijk. Je zou dus als de dictionary de priemgetallen moeten gebruiken? Te kleine stukjes code zou je dan kunnen weergeven door het priemgetal en het aantal binaire cijfers dat er gelezen moet worden.
Misschien interessant: http://nl.wikipedia.org/wiki/Illegaal_priemgetal
Maar het zal geen efficient compressiemechanisme worden. Je kunt nooit álle getallen kleiner weergeven, de getallen die kleiner worden, zullen gecompenseerd worden door getallen die veel groter worden.
quote: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.Op donderdag 21 juli 2005 15:45 schreef Pie.er het volgende:
gelly: veel succes. Een interessante oefening.
Maar het zal geen efficient compressiemechanisme worden. Je kunt nooit álle getallen kleiner weergeven, de getallen die kleiner worden, zullen gecompenseerd worden door getallen die veel groter worden.
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.
quote:Zoals eerder gezegd kun je alle natuurlijke getallen (een bestand is in principe 1 groot getal) ontleden in meerdere priemgetallen. De kunst is om zo groot mogelijke priemgetallen te gebruiken, de notatie blijft immers altijd gelijk. Het vergt alleen enorm veel rekenkracht om een grote compressie te behalen. Voor het decoderen volstaat echter een pentium 100.Op donderdag 21 juli 2005 15:45 schreef Pie.er het volgende:
gelly: veel succes. Een interessante oefening.
Maar het zal geen efficient compressiemechanisme worden. Je kunt nooit álle getallen kleiner weergeven, de getallen die kleiner worden, zullen gecompenseerd worden door getallen die veel groter worden.
quote:Waarom toch telkens die priemgetallen? Hoe kan je een code omrekenen naar een priemgetal? De code 10111000111001111000101001011100011 is waarschijnlijk geen priemgetal en dus onmogleijk om te zetten naar een priemgetal.Op donderdag 21 juli 2005 01:05 schreef Danny het volgende:
[..]
In dat geval zou je dus eigenlijk vrij simpel (met ENORM veel rekenkracht) ELK ge-gzipt bestand kunnen omrekenen naar een priemgetal en deze weergeven in slechts een paar bytes.
Met een de-priem programma zou je het priemgetal weer kunnen omzetten in de nullen en enen waarna je datzelfde bestand in g-zip formaat hebt. Uitpakken en je film, filmcollectie, complete harddisk etc is weer compleet.
quote:O wacht, je zoekt gewoon het dichtsbijzijnde priemgetal, doet dat -n et voila. En priemgetallen zijn heel makkelijk kleiner te maken?Op donderdag 21 juli 2005 15:55 schreef yootje het volgende:
[..]
Waarom toch telkens die priemgetallen? Hoe kan je een code omrekenen naar een priemgetal? De code 10111000111001111000101001011100011 is waarschijnlijk geen priemgetal en dus onmogleijk om te zetten naar een priemgetal.
quote:Elk getal is te schrijven als een vermenigvuldiging van priemgetallen.Op donderdag 21 juli 2005 15:55 schreef yootje het volgende:
Waarom toch telkens die priemgetallen? Hoe kan je een code omrekenen naar een priemgetal? De code 10111000111001111000101001011100011 is waarschijnlijk geen priemgetal en dus onmogleijk om te zetten naar een priemgetal.
quote:Ieder getal is slechts op 1 manier te schrijven als het product van priemgetallen. Wat bedoel je met "De kunst is om zo groot mogelijke priemgetallen te gebruiken"?Op donderdag 21 juli 2005 15:50 schreef gelly het volgende:
[..]
Zoals eerder gezegd kun je alle natuurlijke getallen (een bestand is in principe 1 groot getal) ontleden in meerdere priemgetallen. De kunst is om zo groot mogelijke priemgetallen te gebruiken, de notatie blijft immers altijd gelijk. Het vergt alleen enorm veel rekenkracht om een grote compressie te behalen. Voor het decoderen volstaat echter een pentium 100.
Beweer je een methode gevonden te hebben die iedere mogelijke bitstring comprimeert?
Het Jan Sloot mysterie.
Het Jan Sloot (Digital Coding) Mistery #2
Het Jan Sloot Digital Coding mysterie, deel 3
Het Jan Sloot Digital Coding mysterie, deel 4
Het Jan Sloot Digital Coding mysterie, deel 5
en in Dig
Het Sloot Digital Coding System (SDCS)
[ Bericht 15% gewijzigd door Pietverdriet op 21-07-2005 16:08:08 ]
quote:niet iedere. hoe kleiner de bitstring hoe lager de compressiefactor (en in sommige gevallen wordt het bestand zelfs groter).Op donderdag 21 juli 2005 16:01 schreef Barati het volgende:
[..]
Ieder getal is slechts op 1 manier te schrijven als het product van priemgetallen. Wat bedoel je met "De kunst is om zo groot mogelijke priemgetallen te gebruiken"?
Beweer je een methode gevonden te hebben die iedere mogelijke bitstring comprimeert?
Het mooie is overigens dat je uiteindelijke produkt een simpel tekstbestand zou kunnen zijn, en die kun je met een beetje zip programma nog aardig stukje verder comprimeren
quote:je vergeet deel 6 (nog open)Op donderdag 21 juli 2005 16:02 schreef Pietverdriet het volgende:
Over de onzin van Sloot zijn verhaal en het hele technische verhaal achter compressie in in truth een serie topics geweest.
Het Jan Sloot mysterie.
Het Jan Sloot (Digital Coding) Mistery #2
Het Jan Sloot Digital Coding mysterie, deel 3
Het Jan Sloot Digital Coding mysterie, deel 4
Het Jan Sloot Digital Coding mysterie, deel 5
en in Dig
Het Sloot Digital Coding System (SDCS)
Het Jan Sloot Digital Coding mysterie, deel 6
quote:Ik vind het ook maar een vreemd verhaal. Tenzij hij zoiets als quantumbits gebruikte, maar die ontwikkeling is nog helemaal niet zover, laat staan dat het werkt op kamertemperatuur.Op donderdag 21 juli 2005 16:15 schreef Pietverdriet het volgende:
Ik snap eerlijk gezegt niet dat mensen die behoorlijk technisch onderlegt zijn geloven dat die uitvinding van sloot werkelijk 16 films op 64Kbit passen. Maar goed, da was in die vorige topics al een eindeloze discussie.
quote:sja, alsof uitvindingen waar normaal gesproken hele groepen mensen in laboratoria aan deelproblemen werkt even worden gedaan door iemand op een zolderkamer.Op donderdag 21 juli 2005 16:22 schreef BUG80 het volgende:
[..]
Ik vind het ook maar een vreemd verhaal. Tenzij hij zoiets als quantumbits gebruikte, maar die ontwikkeling is nog helemaal niet zover, laat staan dat het werkt op kamertemperatuur.
Maar zelfs al had hij een revolutionaire opslag methode uitgedacht, een soort super quantumchip, dan was het nog geen supercompressie geweest, maar eenvoudigweg meer opslagcapaciteit.
Met moderne harde schijven is het ook geen probleem een paar duizend films in een sigarenkistje te krijgen.
quote:Even advocaat van de duivel spelen: het zou ook een combinatie van beide kunnen zijn.Op donderdag 21 juli 2005 16:27 schreef Pietverdriet het volgende:
Maar zelfs al had hij een revolutionaire opslag methode uitgedacht, een soort super quantumchip, dan was het nog geen supercompressie geweest, maar eenvoudigweg meer opslagcapaciteit.
Dit onderwerp is inmiddels wel versplinterd over erg veel topics
quote:geen mod die in een Danny topic roep, Dubbel, slotje!Op donderdag 21 juli 2005 16:32 schreef BUG80 het volgende:
Dit onderwerp is inmiddels wel versplinterd over erg veel topics
quote:Ik vraag me af hoe je daar bij komt ? Stel dat je een bestand hebt van 1 Mb. Je zoekt het grootste priemgetal dat in die 1 Mb past. Met de restwaarde doe je hetzelfde weer.Op donderdag 21 juli 2005 16:20 schreef Barati het volgende:
Het aantal bits dat nodig is om de priemfactoren van een getal te representeren is minstens even groot als het aantal bits dat nodig is om dit getal zelf te representeren.
Priemgetal1 + priemgetal2 + priemgetal3 etc...
Het enige dat je op hoeft te slaan zijn de priemgetallen, zelfs alleen het hoeveelste priemgetal het is en een eventuele restwaarde. Overigens hoeven het niet alleen priemgetallen te zijn, de truc is om met een zo klein mogelijke formule het hele getal te beschrijven. Grote priemgetallen zijn echter al bekend en daarom makkelijk te gebruiken.
quote:volgens de firma list en bedrog, ja.Op donderdag 21 juli 2005 17:06 schreef SunChaser het volgende:
Maar waar wordt die film dan uit opgebouwd? Uit die standaard 350 mb?
quote:Euh, nee dat kan niet, maar dat is nu juist de discussie.Daar kan dus elke film uit worden opgebouwd?
quote:heel simpel uitgelegd:Op donderdag 21 juli 2005 17:06 schreef SunChaser het volgende:
Maar waar wordt die film dan uit opgebouwd? Uit die standaard 350 mb? Daar kan dus elke film uit worden opgebouwd?
een bestand zet je om in een getal. dit kan gewoon het bestand in binaire stand zijn (nullen en enen), maar ook het bestand in decimale waarden (000-255).
Dat getal is vele miljoenen tot miljarden tekens lang, maar het blijft één enkel getal.
Dat getal ga je vervolgens omzetten in een optelsom van priemgetallen, welke je wiskundig noteert (een paar bytes per priemgetal).
voila, je hebt het bestand gereduceerd tot een paar honderd Kb.
Probleem is dat er enorm veel rekenkracht nodig is om de juiste priemgetallen en formules te vinden.
Heb je dat eenmaal gedaan dan is de omschakeling naar het oorspronkelijke bestand relatief eenvoudig.
De wiskundige notaties worden gewoon voluit neergezet, de optelsommen worden gemaakt en je hebt je bestand weer in binaire/decimale notatie en dus je oorspronkelijke bestand.
(heel simpel gezegd, niet zo makkelijk uit te voeren)
quote:Hehe. Nou ja, het onderwerp is hier in WFL geloof ik nog niet eerder voorbij gekomen, dus het is wel es interessant om te kijken hoe het WFL-volk daar tegenaan kijktOp donderdag 21 juli 2005 16:36 schreef Pietverdriet het volgende:
[..]
geen mod die in een Danny topic roep, Dubbel, slotje!
Logisch dat ze hem hebben vermoord, ook al loog Sloot misschien, ze hebben t zekere voor het onzekere genomen.
quote:overigens kun je ook in plaats van de wiskunde notatie van de priemgetallen kiezen voor het nummer. bv 3+5 = optelsom van het 3e en 5e priemgetal.Op donderdag 21 juli 2005 17:18 schreef Danny het volgende:
[..]
heel simpel uitgelegd:
een bestand zet je om in een getal. dit kan gewoon het bestand in binaire stand zijn (nullen en enen), maar ook het bestand in decimale waarden (000-255).
Dat getal is vele miljoenen tot miljarden tekens lang, maar het blijft één enkel getal.
Dat getal ga je vervolgens omzetten in een optelsom van priemgetallen, welke je wiskundig noteert (een paar bytes per priemgetal).
voila, je hebt het bestand gereduceerd tot een paar honderd Kb.
Probleem is dat er enorm veel rekenkracht nodig is om de juiste priemgetallen en formules te vinden.
Heb je dat eenmaal gedaan dan is de omschakeling naar het oorspronkelijke bestand relatief eenvoudig.
De wiskundige notaties worden gewoon voluit neergezet, de optelsommen worden gemaakt en je hebt je bestand weer in binaire/decimale notatie en dus je oorspronkelijke bestand.
(heel simpel gezegd, niet zo makkelijk uit te voeren)
3+5 = 10 dus.
quote:Inderdaad, maar of dat echt winst op levert? Neem het getal 12 = 5 + 7, het 3e en 4e priemgetal. Voor het opslaan van het getal "12" heb je 5 bits nodig. Voor "3" + "4" heb je in totaal 7 bits nodig. Rekenfoutjes daargelatenOp donderdag 21 juli 2005 17:22 schreef Danny het volgende:
[..]
overigens kun je ook in plaats van de wiskunde notatie van de priemgetallen kiezen voor het nummer. bv 3+5 = optelsom van het 3e en 5e priemgetal.
3+5 = 10 dus.
[edit]die foutjes waren er dus
[/edit][ Bericht 5% gewijzigd door BUG80 op 21-07-2005 17:36:11 ]
quote:Bij priemgetallen van 100.000 tekens levert het wel degelijk een enorme winst op natuurlijkOp donderdag 21 juli 2005 17:29 schreef BUG80 het volgende:
[..]
Inderdaad, maar of dat echt winst op levert? Neem het getal 12 = 1 + 3 + 7, het 1e, 2e en 4e priemgetal. Voor het opslaan van het getal "12" heb je 4 bits nodig. Voor "1" + "2" + "4" heb je in totaal 6 bits nodig. Rekenfoutjes daargelaten
quote:Kan niet. Want dat andere bitsysteem kan dan 1:1 vertaald worden naar het bestande bitsysteem. Waardoor je met dat andere systeem aan dezelfde beperkingen vastzit als nu.Op donderdag 21 juli 2005 17:35 schreef BUG80 het volgende:
Ik ga er nog steeds van uit, dat mócht deze techniek werkelijk bestaan, deze uitgaat van een ander bitsysteem dan dat wat we nu gebruiken. Dat het dus neerkomt op het opslaan van data op minder "geheugenplekken" ipv nullen en enen.
quote:Het maakt helemaal niet uit met welke mooie woorden hij denk zichzelf ertussenuit te kunnen kletsen. Feit is dat elk alfabet / codering te vertalen is naar een binaire codering (en vice versa). En dus gelden ook dezelfde beperkingen als bij een binaire codering.Op donderdag 21 juli 2005 17:50 schreef DjMark het volgende:
Sloot heeft ook gezegd dat hij een ander digitaal alfabet gebruikte, en dus niet het gangbare binaire stelsel.
quote:Hoe wou jij dan een quantumbit die waarde "1" heeft met kans 0,7 vertalen naar het huidige systeem?Op donderdag 21 juli 2005 17:48 schreef HenryHill het volgende:
[..]
Kan niet. Want dat andere bitsysteem kan dan 1:1 vertaald worden naar het bestande bitsysteem. Waardoor je met dat andere systeem aan dezelfde beperkingen vastzit als nu.
Wat ik bedoel is, stel dat hij werkt met LEDjes die 1000 verschillende lichtsterkten aan kunnen nemen, ik noem maar wat. Lichtsterkte 0 staat voor bitreeks 00000100, sterkte 1 staat voor 10010100, een beetje zoals een Huffman tree. In dat geval kun je veel meer informatie kwijt op een geheugenplaats.
Het feit dat hij een apart apparaatje moest bouwen geeft al aan dat het met de conventionele technieken niet lukte.
Bovenstaande gaat er wel nog steeds van uit dat het kan, waar ik sterk aan twijfel.
quote:De vraag is eerder, hoe wil jij de onzekerheid uit die quantumbits halen zodat je ze kunt gebruiken voor opslag van statische data?Op donderdag 21 juli 2005 18:08 schreef BUG80 het volgende:
[..]
Hoe wou jij dan een quantumbit die waarde "1" heeft met kans 0,7 vertalen naar het huidige systeem?
quote:Gefeliciteerd, je hebt zojuist een geheugenwoord van (nog net geen) 10 bits uitgevonden. Denk je dat het veel zal helpen in vergelijking met de huidige vormen van 8, 16, 32 of 64 bits?Wat ik bedoel is, stel dat hij werkt met LEDjes die 1000 verschillende lichtsterkten aan kunnen nemen, ik noem maar wat. Lichtsterkte 0 staat voor bitreeks 00000100, sterkte 1 staat voor 10010100, een beetje zoals een Huffman tree. In dat geval kun je veel meer informatie kwijt op een geheugenplaats.
quote:Een echte illusionist dus. Die leiden ook de aandacht af van hetgene wat je niet mag snappen door je aandacht ergens anders op te vestigen.Het feit dat hij een apart apparaatje moest bouwen geeft al aan dat het met de conventionele technieken niet lukte.
quote:Joh.Op donderdag 21 juli 2005 17:20 schreef SunChaser het volgende:
Maar goed, als t zou kunnen hoef je alleen maar die 350 mb te downloaden en kun je via gsm, kabel of wat dan ook in 1 sec een compete film kunnen downloaden en uitwisselen. En als t met films kan, kan t met alles en dan is in 1 klap alle netwerken, dvd-spelers, videozaken, etc etc overbodig. Kun je weer internetten met een 28-modem en past de hele videotheek op 1 usb-stick.
Logisch dat ze hem hebben vermoord, ook al loog Sloot misschien, ze hebben t zekere voor het onzekere genomen.
quote:Er kleeft bloed aan de handen van Frits Phillips
quote:Dat is niet mijn taak (gelukkig), maar dat quantum computing voordelen op kan leveren staat vast. Hoe het precies allemaal werkt weet ik niet, maar als het binnen redelijke grenzen 1:1 te vertalen zou zijn naar het binaire stelsel zou het redelijk nutteloos zijn.Op donderdag 21 juli 2005 18:44 schreef HenryHill het volgende:
De vraag is eerder, hoe wil jij de onzekerheid uit die quantumbits halen zodat je ze kunt gebruiken voor opslag van statische data?
quote:Het was maar een voorbeeld van hoe je meer data in één geheugenplaats op kunt slaan. Ik had langere reeksen kunnen gebruiken maar dat had het er ook niet overzichtelijker op gemaakt.Gefeliciteerd, je hebt zojuist een geheugenwoord van (nog net geen) 10 bits uitgevonden. Denk je dat het veel zal helpen in vergelijking met de huidige vormen van 8, 16, 32 of 64 bits?
quote:Ik gooi het op twee mogelijkheden:Een echte illusionist dus. Die leiden ook de aandacht af van hetgene wat je niet mag snappen door je aandacht ergens anders op te vestigen.
1) Hij had echt een nieuw systeem bedacht en hij gebruikte de term "bit" om het te kunnen verkopen
2) Hij belazerde de boel (en kennelijk op een hele goede manier, gezien het geld dat er door anderen is ingepompt).
In beide gevallen is er sprake van misleiding.
quote:En t kostte m zn levenOp donderdag 21 juli 2005 19:24 schreef BUG80 het volgende:
In beide gevallen is er sprake van misleiding.
quote:Ja, als we uitgaan van moord, of een hartaanval door stress.
Zelfmoord is ook nog mogelijk in het geval van bedrog, misschien had hij zichzelf wel te erg in de nesten gewerkt door al die mensen die (financieel) in 'm geloofden.
quote:Neuh, zijn eerste miljoenen stroomden op zn rekening, en was euforisch dat ie "eindelijk erkenning" kreeg.Op donderdag 21 juli 2005 19:29 schreef BUG80 het volgende:
[..]
Ja, als we uitgaan van moord, of een hartaanval door stress.
Zelfmoord is ook nog mogelijk in het geval van bedrog, misschien had hij zichzelf wel te erg in de nesten gewerkt door al die mensen die (financieel) in 'm geloofden.
quote:In eerste instantie was dat misschien onderdeel van zijn bedrog?Op donderdag 21 juli 2005 19:39 schreef Lynx666 het volgende:
[..]
Neuh, zijn eerste miljoenen stroomden op zn rekening, en was euforisch dat ie "eindelijk erkenning" kreeg.
Ach ja, het blijft speculatie.
Een ander systeem? Daar kom ik zo op terug.
Feit is dat hij een geheugenkaartje gebruikte dat in de winkel te koop is. Dat geheugenkaartje had 64KB=524288 bits. Op dat kaartje paste 16 films (32768 bits per film dus)
Met een film van 90 minuten (=5400 sec) en een framerate van 25 fps kom je op 135.000 frames uit. Er zouden dus ruim 4* zoveel frames als bits zijn, geluid zit nog niet eens bij deze berekening.
Een ander systeem:
Een oude computer werkt altijd beter dan een emulator op een computer die 1000* zo goed is. Dit komt omdat oa de beeldchip een eigen processor heeft die het beeldsignaal verzorgt. Een emulator moet elke beeldpunt zelf aan het scherm doorgeven. Als er iets in het kastje zat dan was het een systeem dat een instroom van bits kon vertalen in een veel lagere uitstroom van bits. Toch is het te sterk dat je hoge kwaliteit beeld en geluid krijgt met maar 6 bits per seconde.
Sloot was een oplichter. Als hij zijn systeem een factor 1000 minder goed had gepresenteerd had ik hem nog wel geloofd.
quote:Jij moet dan welhaast slimmer zijn dan al die techneuten die enorm onder de indruk waren. Die lui waren echt dóm man.Op donderdag 21 juli 2005 21:26 schreef BabeWatcher het volgende:
Het is bedrog.
Een ander systeem? Daar kom ik zo op terug.
Feit is dat hij een geheugenkaartje gebruikte dat in de winkel te koop is. Dat geheugenkaartje had 64KB=524288 bits. Op dat kaartje paste 16 films (32768 bits per film dus)
Met een film van 90 minuten (=5400 sec) en een framerate van 25 fps kom je op 135.000 frames uit. Er zouden dus ruim 4* zoveel frames als bits zijn, geluid zit nog niet eens bij deze berekening.
Een ander systeem:
Een oude computer werkt altijd beter dan een emulator op een computer die 1000* zo goed is. Dit komt omdat oa de beeldchip een eigen processor heeft die het beeldsignaal verzorgt. Een emulator moet elke beeldpunt zelf aan het scherm doorgeven. Als er iets in het kastje zat dan was het een systeem dat een instroom van bits kon vertalen in een veel lagere uitstroom van bits. Toch is het te sterk dat je hoge kwaliteit beeld en geluid krijgt met maar 6 bits per seconde.
Sloot was een oplichter. Als hij zijn systeem een factor 1000 minder goed had gepresenteerd had ik hem nog wel geloofd.
quote:Helemaal mee eens, het gekke is alleen dat hij andere mensen die er ook verstand van hadden kennelijk kon overtuigen met zijn presentaties. Zelfs zo ver dat er miljoenen in investeerden. Ik zou zelf toch voor 99% overtuigd moeten zijn dat het menens is voordat ik er zoveel geld in stop.Op donderdag 21 juli 2005 21:26 schreef BabeWatcher het volgende:
Het is bedrog.
Een ander systeem? Daar kom ik zo op terug.
Feit is dat hij een geheugenkaartje gebruikte dat in de winkel te koop is. Dat geheugenkaartje had 64KB=524288 bits. Op dat kaartje paste 16 films (32768 bits per film dus)
Met een film van 90 minuten (=5400 sec) en een framerate van 25 fps kom je op 135.000 frames uit. Er zouden dus ruim 4* zoveel frames als bits zijn, geluid zit nog niet eens bij deze berekening.
Een ander systeem:
Een oude computer werkt altijd beter dan een emulator op een computer die 1000* zo goed is. Dit komt omdat oa de beeldchip een eigen processor heeft die het beeldsignaal verzorgt. Een emulator moet elke beeldpunt zelf aan het scherm doorgeven. Als er iets in het kastje zat dan was het een systeem dat een instroom van bits kon vertalen in een veel lagere uitstroom van bits. Toch is het te sterk dat je hoge kwaliteit beeld en geluid krijgt met maar 6 bits per seconde.
Sloot was een oplichter. Als hij zijn systeem een factor 1000 minder goed had gepresenteerd had ik hem nog wel geloofd.
quote:Op donderdag 21 juli 2005 21:26 schreef BabeWatcher het volgende:
Het is bedrog.
Een ander systeem? Daar kom ik zo op terug.
Feit is dat hij een geheugenkaartje gebruikte dat in de winkel te koop is. Dat geheugenkaartje had 64KB=524288 bits. Op dat kaartje paste 16 films (32768 bits per film dus)
Met een film van 90 minuten (=5400 sec) en een framerate van 25 fps kom je op 135.000 frames uit. Er zouden dus ruim 4* zoveel frames als bits zijn, geluid zit nog niet eens bij deze berekening.
Een ander systeem:
Een oude computer werkt altijd beter dan een emulator op een computer die 1000* zo goed is. Dit komt omdat oa de beeldchip een eigen processor heeft die het beeldsignaal verzorgt. Een emulator moet elke beeldpunt zelf aan het scherm doorgeven. Als er iets in het kastje zat dan was het een systeem dat een instroom van bits kon vertalen in een veel lagere uitstroom van bits. Toch is het te sterk dat je hoge kwaliteit beeld en geluid krijgt met maar 6 bits per seconde.
Sloot was een oplichter. Als hij zijn systeem een factor 1000 minder goed had gepresenteerd had ik hem nog wel geloofd.
De winnaar krijgt een retourreis naar de maan uitgekeerd door ondergetekende.
quote:Mee eensOp donderdag 21 juli 2005 21:37 schreef Danny het volgende:
[..]
Jij moet dan welhaast slimmer zijn dan al die techneuten die enorm onder de indruk waren. Die lui waren echt dóm man.
Plus dat het ook de tijdsgeest was he... de (virtuele) bomen groeiden tot aan de hemel... iedereen met een bedrijfsplan dat er ook maar een beetje voortvarend uitzag kon financierders krijgen. Kan je nagaan wat er gebeurt als je de volgende revolutie belooft...
quote:Ik krijg een beetje hoofdpijn nu ik dit allemaal leesOp donderdag 21 juli 2005 00:54 schreef SunChaser het volgende:
Ik snap er echt geen reet van, maar intrigerend vind ik het wel
Maar tis wel erg interessant
quote:Simpel:Op donderdag 21 juli 2005 23:10 schreef Kaalhei het volgende:
Laat ik de ondergrens van compressie met het volgende vraagstuk aantonen. Wie vertelt mijn welke videobestanden ik bedoel met welke onderstaande getallen?
768 = Svend Dyrings hus
127 = Les Tribulations d'un concierge
0 = (geen geldige codering)
65521 = Les Caprices de Marie
128 = Un lycée de jeunes filles
1111 = Ambrosius
quote:Mag ik iemand meenemen of moet ik alleen?De winnaar krijgt een retourreis naar de maan uitgekeerd door ondergetekende.
quote:a.) FoutOp donderdag 21 juli 2005 23:32 schreef gnomaat het volgende:
[..]
Simpel:
768 = Svend Dyrings hus
127 = Les Tribulations d'un concierge
0 = (geen geldige codering)
65521 = Les Caprices de Marie
128 = Un lycée de jeunes filles
1111 = Ambrosius
[..]
Mag ik iemand meenemen of moet ik alleen?
b.) je mag zoveel mensen meenemen als je zelf wilt.
quote:Fout. Een priemgetal van dat formaat sla je niet op in een paar bytes.Op donderdag 21 juli 2005 17:18 schreef Danny het volgende:
heel simpel uitgelegd:
een bestand zet je om in een getal. dit kan gewoon het bestand in binaire stand zijn (nullen en enen), maar ook het bestand in decimale waarden (000-255).
Dat getal is vele miljoenen tot miljarden tekens lang, maar het blijft één enkel getal.
Dat getal ga je vervolgens omzetten in een optelsom van priemgetallen, welke je wiskundig noteert (een paar bytes per priemgetal).
Een priemgetal van N cijfers lang is ongeveer het (10N/(N*ln(10)))-ste priemgetal. Je zult dus een getal van orde van grootte (10N/(N*ln(10))) moeten opslaan om dat priemgetal mee te identificeren. Dat zijn zo'n N-10log(N)-ln(10) cijfers. Als N vele miljoenen of miljarden is, is N-10log(N)-ln(10) dat ook, dat scheelt niet zoveel.
En wat je gemiddeld nog aan restpriemgetallen nodig hebt om tot je oorspronkelijke getal te komen, is alleen maar groter dan je originele data.
quote:Nee dusBij priemgetallen van 100.000 tekens levert het wel degelijk een enorme winst op natuurlijk
quote:Onmogelijk.voila, je hebt het bestand gereduceerd tot een paar honderd Kb.
Als dat zou kunnen, kun je dezelfde grap ook weer uithalen met die paar honderd KB, waardoor je nog maar een paar KB overhoudt. Dus kun je ineens een bestand van miljoenen bytes in een paar KB opslaan?
En daarmee kun je dan vervolgens... enzovoort.
Ieder idee waarmee je denkt data gegarandeerd kleiner te kunnen maken is natuurlijk bij voorbaat kansloos, zoals al heel vaak is uitgelegd.
Maar voor wie het nog steeds gelooft: als iemand een compressiemethode gaat maken, bijvoorbeeld op basis van priemgetallen of quantumcryptografie of tertiaire printplaten of wat voor wilde fratsen dan ook, kan ik je van te voren een stel bestanden geven waar je met jouw nog te ontwikkelen methode gegerandeerd nog geen 10% vanaf krijgt.
Dus ik hoef nog niet eens naar het algoritme te kijken, de zwakte te ontdekken en daar dan een slecht te comprimeren bestand bij te construeren, ik geef de bestanden al bij voorbaat.
En daar durf ik ook geld op te zetten, zonder dat er een tegenprestatie tegenover hoeft te staan!
Je algoritme mag willekeurig groot zijn - als het gebruik maakt van een database van veertig terrabyte, geen probleem. Wie wil een poging wagen?
quote:Denk het niet, want met zijn techniek zou je die bestanden ook via internet moeten kunnen verspreiden. En internet werkt vooralsnog met 'ouderwetse' 1-en en 0-en. Dus wat hij ook gebruikt, de dataopslag moet plaatsvinden op een binair systeem.Op donderdag 21 juli 2005 17:35 schreef BUG80 het volgende:
Ik ga er nog steeds van uit, dat mócht deze techniek werkelijk bestaan, deze uitgaat van een ander bitsysteem dan dat wat we nu gebruiken. Dat het dus neerkomt op het opslaan van data op minder "geheugenplekken" ipv nullen en enen.
quote:onder deze voorwaarden wel.Op vrijdag 22 juli 2005 00:16 schreef gnomaat het volgende:
Je algoritme mag willekeurig groot zijn - als het gebruik maakt van een database van veertig terrabyte, geen probleem. Wie wil een poging wagen?
De database wordt dan het bestand dat je stuurde. Moet toch lukken om in minder dan 90% van de bestandsgrootte iets te maken dat dat bestand uit de database leest.
Hoeveel krijg ik nou ?
quote:Ik stuur het bestand in een password protected zipfile. Dan heb je het bestand van te voren, zodat is uitgesloten dat ik dat bestand niet speciaal op jouw compressiealgoritme heb afgestemd. Het password geef ik achteraf, als je algoritme klaar isOp vrijdag 22 juli 2005 01:27 schreef Danny het volgende:
onder deze voorwaarden wel.
De database wordt dan het bestand dat je stuurde. Moet toch lukken om in minder dan 90% van de bestandsgrootte iets te maken dat dat bestand uit de database leest.
Hoeveel krijg ik nou ?
de code hoeft alleen maar een commando uit te voeren et voila.
hoeveel krijg ik nou ?
Ik zou logischerwijs verwachten dat er toch wel een paar mensen zijn die denken dat dat wel kan
.quote:Omdat je geen tijdslimiet hebt aangegeven, en aangenomen dat de pitten in de appels levensvatbaar zijn, kan dit natuurlijk wel.Op vrijdag 22 juli 2005 07:34 schreef Wolfje het volgende:
Stel je hebt 5 appels. Kan je daarmee elke Fok!ker een (hele) appel geven?
Ik zou logischerwijs verwachten dat er toch wel een paar mensen zijn die denken dat dat wel kan
quote:Hoe wil je dat programma van te voren zo bouwen dat hij die zipfile uitpakt, als je het password nog niet hebt?Op vrijdag 22 juli 2005 01:39 schreef Danny het volgende:
dus in de database staan zowel winzip als jouw beveiligde bestand.
de code hoeft alleen maar een commando uit te voeren et voila.
hoeveel krijg ik nou ?
Het idee is dat je een algoritme of programma maakt, of eigenlijk twee programma's: eentje waar ik een bestand in kan voeren en waar hij een kleiner bestand (max 90%) van maakt, en een ander prog waar ik dat kleinere bestand in kan voeren en die het origineel er weer uithaalt.
Nu geef ik je het bestand van te voren, zodat ik niet het bestand kan afstemmen op jouw compressie, maar ik geef hem je in een protected zip en het password pas als het programma af is, zodat jij niet je compressie speciaal op mijn ene bestand kan afstemmen.
Je mag fratsen uithalen met winzip of die beveiligde zip in je database stoppen of whatever, maar de info om het originele bestand uit te pakken krijg je pas achteraf
(mocht trouwens blijken dat de gezipte versie van mijn bestand zelf al kleiner dan 90% is, dan rename je gewoon winzip.exe naar mijncompressie.exe en ben je meteen klaar
)quote:We dwalen afOp vrijdag 22 juli 2005 08:05 schreef XoxIx het volgende:
[..]
Omdat je geen tijdslimiet hebt aangegeven, en aangenomen dat de pitten in de appels levensvatbaar zijn, kan dit natuurlijk wel.
Het aantal permutaties dat je kunt maken met 4 kB is extreem hoog. 4192_P_256 is niet te berekenen met een normale PC in elk geval, dus we kunnen er in elk geval vanuit gaan dat alle films die er ooit gemaakt zijn en gemaakt zullen worden in het bestaan van het heelal theoretisch gezien stuk voor stuk opgeslagen kunnen worden in 4 kB. Maar dan heb je wel een magische sleutel nodig, een soort super Huffman tree.
quote:Geen "magische sleutel", die 4 KB aan data dient dan gewoon als index in een supergrote database met alle films.Op vrijdag 22 juli 2005 10:19 schreef BUG80 het volgende:
Het aantal permutaties dat je kunt maken met 4 kB is extreem hoog. 4192_P_256 is niet te berekenen met een normale PC in elk geval, dus we kunnen er in elk geval vanuit gaan dat alle films die er ooit gemaakt zijn en gemaakt zullen worden in het bestaan van het heelal theoretisch gezien stuk voor stuk opgeslagen kunnen worden in 4 kB. Maar dan heb je wel een magische sleutel nodig, een soort super Huffman tree.
Dat is theoretisch te doen omdat, zoals je al aangaf en in deel 1 ook al ergens is genoemd, het aantal mogelijke reeksen van 32768 bits groter is dan het aantal films die ooit gemaakt zijn of gemaakt zullen worden (in ieder geval de komende eeuwen).
In de praktijk heb je er natuurlijk geen reet aan, want je kunt niet van te voren een database samenstellen met films die nog uitgebracht gaan worden. En bovendien komt het er in feite op neer dat je hier helemaal geen ruimte mee wint (waar deze hele uitvinding om ging), want iemand die een film van 4KB kan "decoderen" heeft dus de database, en daarmee al de hele film, ook zonder die 4KB data.
quote:Je hebt helemaal gelijk, maar ik was meer theoretisch aan het denken. Het is theoretisch mogelijk dat er één sleutel of Huffman tree bestaat waarmee alle films tot 4 kB gereduceerd kunnen worden. Alleen geloof ik niet dat er zoveel redundantie tussen de films bestaat, dat er één tree gemaakt van kan worden (die ook nog eens niet extreem groot is).Op vrijdag 22 juli 2005 10:31 schreef gnomaat het volgende:
knip
quote:Die supergrote database is het hele getallenstelsel. Elke film (of bestand) is uniek, een unieke opeenvolging van 1 en 0, of decimaal, van 0 tot x. Als je dat unieke getal in een relatief kleine formule kunt samenvatten ben je d'r. Een voorbeeld is al gegeven in dit topic, een programma is samengevat in 1 priemgetal + een restwaarde. Bewezen, het werkt.Op vrijdag 22 juli 2005 10:31 schreef gnomaat het volgende:
[..]
Geen "magische sleutel", die 4 KB aan data dient dan gewoon als index in een supergrote database met alle films.
http://primes.utm.edu/glossary/page.php?sort=Illegal
Voor deze test gebruik ik enkel de eerste 20 priemgetallen omdat het om kleinschalige gegevens gaat. Geen idee of de compressie dan ook redelijk is, de vorige keer gebruikte ik grotere priemgetallen en toen was de ratio 70%.quote:Da's één hele onwaarschijnlijke toevalstreffer. En bovendien volgt hier niet uit dat er iets valt te winnen t.o.v. bestaande compressietechnieken, want dat illegale priemgetal is letterlijk de data van een .zip file met nog wat dummy data erachteraan zodat het resultaat priem is. Dus de zip zelf was al een betere compressie dan dat priemgetal.Op vrijdag 22 juli 2005 10:42 schreef gelly het volgende:
Die supergrote database is het hele getallenstelsel. Elke film (of bestand) is uniek, een unieke opeenvolging van 1 en 0, of decimaal, van 0 tot x. Als je dat unieke getal in een relatief kleine formule kunt samenvatten ben je d'r. Een voorbeeld is al gegeven in dit topic, een programma is samengevat in 1 priemgetal + een restwaarde. Bewezen, het werkt.
http://primes.utm.edu/glossary/page.php?sort=Illegal
Als je toch denkt dat dit praktisch toepasbaar is: http://forum.fok.nl/topic/730278/1/141#29026669
Ik wed er zo ¤100 om dat je op deze manier (of welke andere manier dan ook) nog geen 10% van mijn bestand af krijgt.
quote:Op vrijdag 22 juli 2005 10:45 schreef gelly het volgende:
Ik ben trouwens druk bezig mn progsel af te krijgen
quote:Uh, je ziet toch dat die zip samengevat is in iets van 10 characters ? En het was ook niet echt een toevalstreffer, dergelijke priemgetallen zijn bekend en je kunt dus makkelijk kijken of je data kunt samenvatten in zo'n priemgetal. Waarom zou dat niet voor andere bestanden gelden ? Ieder getal is een samenraapsel van 1 of meerdere priemgetallen, en ieder bestand is 1 groot getal.Op vrijdag 22 juli 2005 10:54 schreef gnomaat het volgende:
[..]
Dus de zip zelf was al een betere compressie dan dat priemgetal.
quote:Ik ben druk bezig en hoop je binnenkort het resultaat te laten zien.Als je toch denkt dat dit praktisch toepasbaar is: mega-compressie - deel 2 -
Ik wed er zo ¤100 om dat je op deze manier (of welke andere manier dan ook) nog geen 10% van mijn bestand af krijgt.
[ Bericht 2% gewijzigd door #ANONIEM op 22-07-2005 10:59:47 ]
quote:Misschien zie ik iets over het hoofd, maar het priemgetal dat wordt genoemd is toch k*256211+99 waarbij k de binaire representatie van de zip file is? Dat is toch meer data dan alleen k?Op vrijdag 22 juli 2005 10:58 schreef gelly het volgende:
Uh, je ziet toch dat die zip samengevat is in iets van 10 characters?
quote:Ja, als ik het zo vlug lees gaat dit verhaal ook niet over compressie maar over codering volgens mij. Beejte lullige compressie als je het het originele bestand er ook bij nodig hebt.Op vrijdag 22 juli 2005 11:05 schreef gnomaat het volgende:
[..]
Misschien zie ik iets over het hoofd, maar het priemgetal dat wordt genoemd is toch k*256211+99 waarbij k de binaire representatie van de zip file is? Dat is toch meer data dan alleen k?
quote:Ze gebruiken in dat voorbeeld het priemgetal om er extra informatie in te versleutelen om zo "legaal" bestanden te verspreiden. Als je het priemgetal uit de data filtert heb je het orginele bestand.Op vrijdag 22 juli 2005 11:05 schreef gnomaat het volgende:
[..]
Misschien zie ik iets over het hoofd, maar het priemgetal dat wordt genoemd is toch k*256211+99 waarbij k de binaire representatie van de zip file is? Dat is toch meer data dan alleen k?
quote:Ja dat snap ik, maar dat heeft toch niks met compressie te maken? Het priemgetal is in binaire vorm toch al groter dan de .zip die je ermee probeert te versleutelen?Op vrijdag 22 juli 2005 11:12 schreef gelly het volgende:
Ze gebruiken in dat voorbeeld het priemgetal om er extra informatie in te versleutelen om zo "legaal" bestanden te verspreiden. Als je het priemgetal uit de data filtert heb je het orginele bestand.
En je kunt dit priemgetal ook niet op een hele korte manier (korter dan k zelf) opschrijven, zoals bij sommige grote priemgetallen wel kan.
quote:Sja Danny, kijk naar je zelf, jij bent techneut, zwaar onder de indruk, maar begrijp de wiskundige problemen met deze jan sloot compressie, en de onmogelijkheid ervan ook niet....Op donderdag 21 juli 2005 21:37 schreef Danny het volgende:
[..]
Jij moet dan welhaast slimmer zijn dan al die techneuten die enorm onder de indruk waren. Die lui waren echt dóm man.
quote:Ik ben ook sceptisch Pietverdriet, maar pas op met dit soort termen.Op vrijdag 22 juli 2005 12:01 schreef Pietverdriet het volgende:
onmogelijkheid
quote:Denk dat het in de vorige topics wiskundig is aangetoont dat het niet kan.Op vrijdag 22 juli 2005 12:22 schreef BUG80 het volgende:
[..]
Ik ben ook sceptisch Pietverdriet, maar pas op met dit soort termen.
quote:Probeer maar antwoord te geven op mijn vraagstuk, dan begrijp je de onmogelijkheid.Op vrijdag 22 juli 2005 12:22 schreef BUG80 het volgende:
[..]
Ik ben ook sceptisch Pietverdriet, maar pas op met dit soort termen.
quote:Je bedoelt deze? Zoals ik al zei, is het in mijn ogen niet mogelijk om een film te comprimeren naar 4 kB zonder sleutel of tree. Kortom ik kan je vraagstuk niet oplossen zonder dat je die sleutel erbij geeftOp donderdag 21 juli 2005 23:10 schreef Kaalhei het volgende:
Laat ik de ondergrens van compressie met het volgende vraagstuk aantonen. Wie vertelt mijn welke videobestanden ik bedoel met welke onderstaande getallen?768 127 0 65521 128 1111
De winnaar krijgt een retourreis naar de maan uitgekeerd door ondergetekende.
quote:In de vergelijking met Jan Sloots vermeende coderingstechniek, zijn die getallen de sleutels.Op vrijdag 22 juli 2005 12:51 schreef BUG80 het volgende:
Je bedoelt deze? Zoals ik al zei, is het in mijn ogen niet mogelijk om een film te comprimeren naar 4 kB zonder sleutel of tree. Kortom ik kan je vraagstuk niet oplossen zonder dat je die sleutel erbij geeft
quote:Is dat zo? Dus Sloot beweerde geen gebruik te maken van iets dat vergelijkbaar is met een Huffman tree?Op vrijdag 22 juli 2005 12:56 schreef gnomaat het volgende:
[..]
In de vergelijking met Jan Sloots vermeende coderingstechniek, zijn die getallen de sleutels.
Trouwens kaalhei, je hebt het over een ondergrens, maar in een paar posts boven je leg ik al uit dat het aantal permutaties dat je kunt maken met 32768 bits zo goed als oneindig is. Of bedoel je dat niet?
[edit]Net zoals het aantal permutaties dat je met 750 MB kunt maken eigenlijk eindig is, en toch kunnen we er alle mogelijke films praktisch gezien in kwijt[/edit]
quote:Nee hoor, bijna geen enkele film. Wel zo goed als alle films in de praktijk, maar van alle mogelijke films bijna geen.Op vrijdag 22 juli 2005 13:00 schreef BUG80 het volgende:
Net zoals het aantal permutaties dat je met 750 MB kunt maken eigenlijk eindig is, en toch kunnen we er alle mogelijke films praktisch gezien in kwijt[/edit]
Neem maar 90 minuten aan gekleurde ruis of random patronen. Dat krijg je niet in 750 MB zonder dat het zó lossy wordt dat de originele film in de verste verte er niet meer uit gehaald kan worden.
quote:Maar het aantal versies dat je kan maken van slechts 1 film is ook bijna oneindig. Er zijn wel iets meer dan 32768 dichotomieen die ik kan bedenken. Je hebt een paar duizend frames, die kan je allemaal spiegelen, in een zeker 360 verschillende hoeken laten zien, miljoenen verschillende kleursettings laten zien. Vervolgens kan je op sommige frames de hoofdrolspeler een andere kleur haar geven, geen haar, duizenden verschillende soorten hoeden, uiteraard in alle kleuren en in alle hoeken. Dan kan je er ineens een andere acteur bij bedenken en hier de truuk ook uithalen. Vervolgens ga je deze opties verdelen over de duizenden frames. Die je weer allemaal in een andere volgorde kan zetten. Nu ga je soortgelijke truuks uithalen met het geluid, etc. etc. De mogelijkheden zijn gewoon bijna oneindig.Op vrijdag 22 juli 2005 13:00 schreef BUG80 het volgende:
[..]
Is dat zo? Dus Sloot beweerde geen gebruik te maken van iets dat vergelijkbaar is met een Huffman tree?
Trouwens kaalhei, je hebt het over een ondergrens, maar in een paar posts boven je leg ik al uit dat het aantal permutaties dat je kunt maken met 32768 bits zo goed als oneindig is. Of bedoel je dat niet?
[edit]Net zoals het aantal permutaties dat je met 750 MB kunt maken eigenlijk eindig is, en toch kunnen we er alle mogelijke films praktisch gezien in kwijt[/edit]
quote:Jazeker, maar dat geldt ook voor 750 MB. Waar ligt dan precies de grens?Op vrijdag 22 juli 2005 13:14 schreef Kaalhei het volgende:
[..]
Maar het aantal versies dat je kan maken van slechts 1 film is ook bijna oneindig. Er zijn wel iets meer dan 32768 dichotomieen die ik kan bedenken. Je hebt een paar duizend frames, die kan je allemaal spiegelen, in een zeker 360 verschillende hoeken laten zien, miljoenen verschillende kleursettings laten zien. Vervolgens kan je op sommige frames de hoofdrolspeler een andere kleur haar geven, geen haar, duizenden verschillende soorten hoeden, uiteraard in alle kleuren en in alle hoeken. Dan kan je er ineens een andere acteur bij bedenken en hier de truuk ook uithalen. Vervolgens ga je deze opties verdelen over de duizenden frames. Die je weer allemaal in een andere volgorde kan zetten. Nu ga je soortgelijke truuks uithalen met het geluid, etc. etc. De mogelijkheden zijn gewoon bijna oneindig.
Laat ik het zo zeggen, het aantal verschillende songs dat je in een MP3 van 3 MB kwijt kunt is ook eindig en toch is niemand bang dat binnenkort de liedjes op zijn.
quote:Dat zou een interessant experiment zijn. Jammer dat die box niet meer te vinden is.Op vrijdag 22 juli 2005 13:18 schreef Pietverdriet het volgende:
Als JS zijn machine reeel was, hoefde je geen films meer te draaien. Je kan eenvoudig weg een random sleutel getal ingeven er er komt een nieuwe film uit de box.
Ik speel nog steeds advocaat van de duivel hoor jongens
quote:Uiteraard. Maar een DivX film is feitelijk ook een sleutel voor de codec. Als ik dus 750 MB aan random data aan een DivX decoder voer zou daar ook nieuwe film uit moeten komen. Of het ergens op lijkt is een tweede.Op vrijdag 22 juli 2005 14:00 schreef Pietverdriet het volgende:
Dat is het logisch gevolg van het verhaal, BUG80, als de sleutels allleen een nummer zijn voor een fim, een sleutel, en de databank universeel is.
quote:Nee, want die 750MB bevat een hoeveelheid data die voldoende is om informatie voor ieder frame te beschrijven.Op vrijdag 22 juli 2005 14:02 schreef BUG80 het volgende:
[..]
Uiteraard. Maar een DivX film is feitelijk ook een sleutel voor de codec. Als ik dus 750 MB aan random data aan een DivX decoder voer zou daar ook nieuwe film uit moeten komen. Of het ergens op lijkt is een tweede.
1/16 van 64 K niet.
De vraag is alleen: is het mogelijk om een algoritme te maken dat een willekeurige stroom data omzet naar zoiets kleins als 4 kB.
quote:Ik zeg toch ook niet dat er geen ondergrens is? De vraag is alleen waar die ligt.Op vrijdag 22 juli 2005 14:09 schreef Kaalhei het volgende:
Waarom is het zo moeilijk te begrijpen dat je iets niet kunt blijven comprimeren zonder verlies. Dan is altijd alles 0 in het oneindige. Dan kan je alle informatie in het heelal opslaan in een schakelaar, die altijd uit staat.
quote:D'r is toch ook niemand die beweert dat je tot de 0 grens kunt gaan. De vraag tot hoever je iets kunt comprimeren (of coderen) is wel interessant lijkt me. En of dat nou 4K of 1 Mb is...Op vrijdag 22 juli 2005 14:09 schreef Kaalhei het volgende:
Waarom is het zo moeilijk te begrijpen dat je iets niet kunt blijven comprimeren zonder verlies. Dan is altijd alles 0 in het oneindige. Dan kan je alle informatie in het heelal opslaan in een schakelaar, die altijd uit staat.
quote:Het zou kunnen, maar alleen als een bepaalde sequentie van bijvoorbeeld 3 bits via de "database" omgezet kan worden naar meerdere frames. Maar dat geloof ik dus niet, dat zou zo'n grote database betekenen...Op vrijdag 22 juli 2005 14:12 schreef Pietverdriet het volgende:
[..]
Nee, want die 750MB bevat een hoeveelheid data die voldoende is om informatie voor ieder frame te beschrijven.
1/16 van 64 K niet.
quote:Ja, alleen met zoveel verlies dat het alle informatie verliest.Op vrijdag 22 juli 2005 14:12 schreef BUG80 het volgende:
Kijk, ik zie het verschil tussen 750 MB en 4 kB niet zo, of desnoods de 7 GB van een DVD. De grootte mag nog zoveel verschillen, het aantal de mogelijke permutaties is in alledrie de gevallen vrijwel oneindig (probeer het maar eens te berekenen).
De vraag is alleen: is het mogelijk om een algoritme te maken dat een willekeurige stroom data omzet naar zoiets kleins als 4 kB.
quote:Natuurlijk niet. Elke film is uniek, zo ook de code om een film te beschrijven. Natuurlijk kun je een random sleutel invoeren, de kans is dan vrij klein (zo niet verwaarloosbaar) dat je meer dan een hoop ruis ziet.Op vrijdag 22 juli 2005 13:18 schreef Pietverdriet het volgende:
Als JS zijn machine reeel was, hoefde je geen films meer te draaien. Je kan eenvoudig weg een random sleutel getal ingeven er er komt een nieuwe film uit de box.
quote:Hoe meer je comprimeert, hoe meer info je verliest.Op vrijdag 22 juli 2005 14:16 schreef gelly het volgende:
[..]
D'r is toch ook niemand die beweert dat je tot de 0 grens kunt gaan. De vraag tot hoever je iets kunt comprimeren (of coderen) is wel interessant lijkt me. En of dat nou 4K of 1 Mb is...
quote:Ergo, je moet een hoeveelheid informatie hebben, en die informatie hoeveelheid van 4KB is veel te klein daarvoor.Op vrijdag 22 juli 2005 14:18 schreef gelly het volgende:
[..]
Natuurlijk niet. Elke film is uniek, zo ook de code om een film te beschrijven. Natuurlijk kun je een random sleutel invoeren, de kans is dan vrij klein (zo niet verwaarloosbaar) dat je meer dan een hoop ruis ziet.
quote:Niet per se. Ik kan wel degelijk een film comprimeren naar 4 kB door met een gigantische Huffman tree te werken (Sterker nog, als ik de tree net zo groot maak als de film heb ik genoeg aan 1 bit).Op vrijdag 22 juli 2005 14:19 schreef Pietverdriet het volgende:
[..]
Hoe meer je comprimeert, hoe meer info je verliest.
Het lijkt me alleen heel erg sterk dat ik dezelfde tree vervolgens kan gebruiken om een tweede film eveneens terug te brengen naar 4 kB. Dan komt er een gebrek aan redundantie de hoek om kijken.
quote:Je weet toch niet of Sloot een algoritme had bedacht dat in 4k pastte maar dat 700 Mb aan data kon genereren ?Op vrijdag 22 juli 2005 14:21 schreef Pietverdriet het volgende:
[..]
Ergo, je moet een hoeveelheid informatie hebben, en die informatie hoeveelheid van 4KB is veel te klein daarvoor.
quote:dat is dan eigenlijk geen compressie maar de informatie ergens anders neerleggen.Op vrijdag 22 juli 2005 14:21 schreef BUG80 het volgende:
[..]
Niet per se. Ik kan wel degelijk een film comprimeren naar 4 kB door met een gigantische Huffman tree te werken (Sterker nog, als ik de tree net zo groot maak als de film heb ik genoeg aan 1 bit).
Het lijkt me alleen heel erg sterk dat ik dezelfde tree vervolgens kan gebruiken om een tweede film eveneens terug te brengen naar 4 kB. Dan komt er een gebrek aan redundantie de hoek om kijken.
quote:Als dat zo is, en logischer wijze volgt dat uit de aanname dat sloot´s uitvinding echt was, dan zou je uit een random 4 K string een film moeten kunnen genereren. De hoeveelheid data in 4 K is niet voldoende voor informatie, maar alleen maar voor een catalogus nummer.Op vrijdag 22 juli 2005 14:23 schreef gelly het volgende:
[..]
Je weet toch niet of Sloot een algoritme had bedacht dat in 4k pastte maar dat 700 Mb aan data kon genereren ?
quote:Ja inderdaad. Zip doet dat natuurlijk ook, maar die slaat de tree op bij de data, omdat elk bestand zijn eigen optimale tree heeft. Maar stel nu dat Sloot een tree heeft gevonden van bijvoorbeeld 1 GB die voor alle films goed werkt. Onwaarschijnlijk, maar stel.Op vrijdag 22 juli 2005 14:31 schreef Pietverdriet het volgende:
[..]
dat is dan eigenlijk geen compressie maar de informatie ergens anders neerleggen.
quote:Dat is net zo waarschijnlijk als in kladblok wat letters neerplempen, het door een compiler halen en dan windows XP nagemaakt hebben.Op vrijdag 22 juli 2005 14:33 schreef Pietverdriet het volgende:
[..]
Als dat zo is, en logischer wijze volgt dat uit de aanname dat sloot´s uitvinding echt was, dan zou je uit een random 4 K string een film moeten kunnen genereren.
quote:Je hoeft de data enkel te omschrijven, niet te comprimeren. 2^256 Geeft een enorm groot getal, maar is dus ook met 5 chars te beschrijven.De hoeveelheid data in 4 K is niet voldoende voor informatie, maar alleen maar voor een catalogus nummer.
quote:Een film is niet hetzelfde als een willekeurig bestand. Ongecomprimeerde films, die echt bestaan uit compleet opgeslagen frames zijn inderdaad gemakkelijk behoorlijk veel kleiner te krijgen. Net als dat je ongecomprimeerde BMPs kleiner kunt krijgen door het om te zetten naar GIF.Op vrijdag 22 juli 2005 14:34 schreef BUG80 het volgende:
[..]
Ja inderdaad. Zip doet dat natuurlijk ook, maar die slaat de tree op bij de data, omdat elk bestand zijn eigen optimale tree heeft. Maar stel nu dat Sloot een tree heeft gevonden van bijvoorbeeld 1 GB die voor alle films goed werkt. Onwaarschijnlijk, maar stel.
quote:Waar je naar moet kijken is de entropie of het data "gewicht" van een bestand. Een uncompressed film is een dikke 150 GB. Hier zit natuurlijk ontzettend vele redundancy in, zodat je de essentie van die content ook wel in 700 MB (minder dan een half % van het origineel) kwijt kunt. Maar daar zit natuurlijk een grens aan.Op vrijdag 22 juli 2005 14:12 schreef BUG80 het volgende:
Kijk, ik zie het verschil tussen 750 MB en 4 kB niet zo
Waar die grens ligt hangt van de film af (en wat je nog als acceptabele losses beschouwt), maar voor een normale gemiddelde speelfilm zal die grens onder de 700 MB maar ver boven de 4 KB liggen. 4KB gewoon te weinig. Het is vast wel wiskundig te bewijzen met Shannon ondergrenzen e.d. maar bovendien voel je gewoon op je klompen aan dat 4096 bytes gewoon te weinig zijn om een film te representeren (ik wel althans).
Het hele verhaal rammelt sowieso aan alle kanten omdat er wordt gesteld dat iedere film (of zelfs iedere data) in een sleutel van dezelfde grootte past. Terwijl een film die twee keer zo lang duurt als een andere, met vergelijkbare content, natuurlijk ook twee keer zoveel entropie omvat.
quote:Windows XP is geen 4Kb grootOp vrijdag 22 juli 2005 14:42 schreef gelly het volgende:
Dat is net zo waarschijnlijk als in kladblok wat letters neerplempen, het door een compiler halen en dan windows XP nagemaakt hebben.
quote:Maar niet elk willekeurig getal is te schrijven als 2^n met n een natuurlijk getal.Je hoeft de data enkel te omschrijven, niet te comprimeren. 2^256 Geeft een enorm groot getal, maar is dus ook met 5 chars te beschrijven.
quote:Je hebt ook lossless comprimeren, WinZip bv.Op vrijdag 22 juli 2005 14:19 schreef Pietverdriet het volgende:
[..]
Hoe meer je comprimeert, hoe meer info je verliest.
quote:Dan heb je maar 1 bit nodig voor de Matrix op I-max. Staat de bit op 0 dan gebeurt er niets, zet je de bit op 1 dan kijk je naar de sleutel. De sleutel is dan vervolgens de film van een paar gigabyte.Op vrijdag 22 juli 2005 14:31 schreef Pietverdriet het volgende:
[..]
dat is dan eigenlijk geen compressie maar de informatie ergens anders neerleggen.
quote: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. Het blijft natuurlijk theoretisch gewauwel, maar 60 jaar geleden geloofde ook niemand dat je muziek op kon slaan op 1/7 van de grootte, zonder perceptioneel verlies. Zeg nooit nooit!Op vrijdag 22 juli 2005 14:51 schreef gnomaat het volgende:
[..]
Waar je naar moet kijken is de entropie of het data "gewicht" van een bestand. Een uncompressed film is een dikke 150 GB. Hier zit natuurlijk ontzettend vele redundancy in, zodat je de essentie van die content ook wel in 700 MB (minder dan een half % van het origineel) kwijt kunt. Maar daar zit natuurlijk een grens aan.
Waar die grens ligt hangt van de film af (en wat je nog als acceptabele losses beschouwt), maar voor een normale gemiddelde speelfilm zal die grens onder de 700 MB maar ver boven de 4 KB liggen. 4KB gewoon te weinig. Het is vast wel wiskundig te bewijzen met Shannon ondergrenzen e.d. maar bovendien voel je gewoon op je klompen aan dat 4096 bytes gewoon te weinig zijn om een film te representeren (ik wel althans).
quote:Dat is het idee ja. En als je die "tree" nou wat kleiner maakt dan een paar gigabyte gebruik je vervolgens niet 1 bit, maar 32768 bits. En wie weet, misschien kan je met diezelfde tree The Matrix Reloaded ook wel comprimeren.Op vrijdag 22 juli 2005 14:57 schreef Kaalhei het volgende:
[..]
Dan heb je maar 1 bit nodig voor de Matrix op I-max. Staat de bit op 0 dan gebeurt er niets, zet je de bit op 1 dan kijk je naar de sleutel. De sleutel is dan vervolgens de film van een paar gigabyte.
Zelf geloof ik er ook niet zo in hoor
In mijn tijd kregen we gewoon economie en geschiedenis over Willem van Oranje op school 
quote:De wet van Shannon is uit 1948..Op vrijdag 22 juli 2005 15:02 schreef BUG80 het volgende:
Het blijft natuurlijk theoretisch gewauwel, maar 60 jaar geleden geloofde ook niemand dat je muziek op kon slaan op 1/7 van de grootte, zonder perceptioneel verlies. Zeg nooit nooit!
quote:Das best pittig voor de kappersschool, niet?Op vrijdag 22 juli 2005 15:05 schreef SunChaser het volgende:
Waar hebben jullie allemaal gestudeerd
quote:Dat ging niet over perceptioneel coderen, toch. De werking van het oor is pas halverwege de jaren '50 in detail onderzocht.Op vrijdag 22 juli 2005 15:06 schreef Pietverdriet het volgende:
[..]
De wet van Shannon is uit 1948..
We dwalen weer af
quote:Och... Je hebt soms mensen die een Balthazar Gerards kapsel willenOp vrijdag 22 juli 2005 15:08 schreef Pietverdriet het volgende:
[..]
Das best pittig voor de kappersschool, niet?
quote:Zet je onduleerijzers maar aan...Op vrijdag 22 juli 2005 15:13 schreef SunChaser het volgende:
[..]
Och... Je hebt soms mensen die een Balthazar Gerards kapsel willen
quote:Mooi!Op vrijdag 22 juli 2005 15:20 schreef gelly het volgende:
Overigens heb ik nu even 'snel' een applet geschreven die mijn compressiemethode simpel laat zien, ik zal hem even ergens parkeren.
Ik heb hier vast een voorbeeldbestandje neergezet:
http://www.free-space.us/gnomaat/compression_test.zip (zit een file van 10 KB in)
Deze zip is nog niet password protected ofzo, maar kun je vast kijken of het een beetje werkt.
quote:Hold your horsesOp vrijdag 22 juli 2005 15:46 schreef gnomaat het volgende:
[..]
Mooi!
Ik heb hier vast een voorbeeldbestandje neergezet:
http://www.free-space.us/gnomaat/compression_test.zip (zit een file van 10 KB in)
Deze zip is nog niet password protected ofzo, maar kun je vast kijken of het een beetje werkt.
Het is een applet om te laten zien dat compressie van meer dan 50% mogelijk is en dat die compressie toeneemt naarmate het te coderen getal groter wordt... Ik zoek alleen even een webspace om de boel te dumpen, ben het wachtwoord van de mijne kwijt...
quote:* yootje biedt webspace aan.Op vrijdag 22 juli 2005 15:54 schreef gelly het volgende:
[..]
Hold your horses
Ik zoek alleen even een webspace om de boel te dumpen, ben het wachtwoord van de mijne kwijt...
Je kunt deze applet beter in een standalone viewer bekijken, zowel firefox als IE zweten nogal als het ingegeven getal erg groot wordt. Het loopt niet vast, al lijkt het wel zo.
Compression is 88 %
Used primes : 0 for 1024 decimals
Compression is 0 %
Used primes : 0 for 1024 decimals
Compression is 0 %
quote:Beweert die applet nu dat het zulke grote priemgetallen in 1 byte codeert?Op vrijdag 22 juli 2005 16:15 schreef gelly het volgende:
http://www.free-space.us/primer/Applet1.html
Je kunt deze applet beter in een standalone viewer bekijken, zowel firefox als IE zweten nogal als het ingegeven getal erg groot wordt. Het loopt niet vast, al lijkt het wel zo.
quote:Ja, ik sla namelijk niet de priemgetallen zelf op, alleen het hoeveelste Mersenne priemgetal het is.Op vrijdag 22 juli 2005 16:25 schreef XoxIx het volgende:
[..]
Beweert die applet nu dat het zulke grote priemgetallen in 1 byte codeert?
Compression is 54 %
quote:Dan kan je dus nog theoretisch veel meer compressie halen door hierna nog eens Huffman compressie er overheen te halen (de zip-methode).Op vrijdag 22 juli 2005 16:27 schreef gelly het volgende:
[..]
Ja, ik sla namelijk niet de priemgetallen zelf op, alleen het hoeveelste Mersenne priemgetal het is.
quote:Je rekent niet correct. Je input mag maar 10 verschillende waarden hebben (0..9), maar het rangnummer van je priemgetal kan best 1.000.000 zijn (dus 1 miljoen verschillende waarden).Op vrijdag 22 juli 2005 16:27 schreef gelly het volgende:
[..]
Ja, ik sla namelijk niet de priemgetallen zelf op, alleen het hoeveelste Mersenne priemgetal het is.
Als je het goed wilt doen moet je dus berekenen hoe lang de decimale representatie is van je priemgetallen. Bijvoorbeeld:
121 = 101 + 19 + 2
Dat wordt niet: 3 voor 3 met geen compressie, maar 6 voor 3 is 100% verlies.
Zelfs nu wordt er nog wat gesjoemeld, maar niet meer zo erg als dat in het applet gebeurt.
quote:Klopt, daarom werkt het ook niet bij kleine getallen, nou ja het werkt wel maar er is verlies. Ik gebruik enorm grote priemgetallen die in kleine notatie worden weergegeven. Test het maar in de applet, je zal zien dat hoe groter de getallen worden hoe groter de compressie wordt.Op vrijdag 22 juli 2005 16:37 schreef XoxIx het volgende:
[..]
Je rekent niet correct. Je input mag maar 10 verschillende waarden hebben (0..9), maar het rangnummer van je priemgetal kan best 1.000.000 zijn (dus 1 miljoen verschillende waarden).
Als je het goed wilt doen moet je dus berekenen hoe lang de decimale representatie is van je priemgetallen. Bijvoorbeeld:
121 = 101 + 19 + 2
Dat wordt niet: 3 voor 3 met geen compressie, maar 6 voor 3 is 100% verlies.
Zelfs nu wordt er nog wat gesjoemeld, maar niet meer zo erg als dat in het applet gebeurt.
quote:Als je je applet hebt aangepast. Je telt het aantal priemgetallen dat je gebruikt, niet het aantal tekens dat je gebruikt, terwijl je bij de input kijkt naar het aantal tekens.Op vrijdag 22 juli 2005 16:42 schreef gelly het volgende:
[..]
Klopt, daarom werkt het ook niet bij kleine getallen, nou ja het werkt wel maar er is verlies. Ik gebruik enorm grote priemgetallen die in kleine notatie worden weergegeven. Test het maar in de applet, je zal zien dat hoe groter de getallen worden hoe groter de compressie wordt.
quote:Hij heeft gelijk, ja. Als je het goed wil doen moet je alle 256 mogelijke karakters die je kunt maken met een byte accepteren. Het getal '121' kun je namelijk makkelijk in 1 byte kwijt, terwijl jij het in 3 stopt en er vervolgens weer 3 van maakt.Op vrijdag 22 juli 2005 16:37 schreef XoxIx het volgende:
[..]
Je rekent niet correct. Je input mag maar 10 verschillende waarden hebben (0..9), maar het rangnummer van je priemgetal kan best 1.000.000 zijn (dus 1 miljoen verschillende waarden).
Als je het goed wilt doen moet je dus berekenen hoe lang de decimale representatie is van je priemgetallen. Bijvoorbeeld:
121 = 101 + 19 + 2
Dat wordt niet: 3 voor 3 met geen compressie, maar 6 voor 3 is 100% verlies.
Zelfs nu wordt er nog wat gesjoemeld, maar niet meer zo erg als dat in het applet gebeurt.
quote:Ik kan elk gebruikt priemgetal opslaan in 1 byte, dus waarom zou ik daar rekening mee moeten houden ? Het integere getal dat je ingeeft is in feite de integere weergave van data. Het is niet zo dat dat getal in een bestand komt te staan.Op vrijdag 22 juli 2005 16:44 schreef XoxIx het volgende:
[..]
Als je je applet hebt aangepast. Je telt het aantal priemgetallen dat je gebruikt, niet het aantal tekens dat je gebruikt, terwijl je bij de input kijkt naar het aantal tekens.
quote:Zie mijn post. Je telt getallen tot 256 als 3 karakters/bytes in plaats van 1.Op vrijdag 22 juli 2005 16:48 schreef gelly het volgende:
[..]
Ik kan elk gebruikt priemgetal opslaan in 1 byte, dus waarom zou ik daar rekening mee moeten houden ? Het integere getal dat je ingeeft is in feite de integere weergave van data. Het is niet zo dat dat getal in een bestand komt te staan.
quote:Uhm nee. Ik kan met een byte aangeven welke plaats het priemgetal heeft in de index van Mesenne priemgetallen. Je moet die getallen niet als karakters zien maar als de integere weergave van bytes.Op vrijdag 22 juli 2005 16:49 schreef BUG80 het volgende:
[..]
Zie mijn post. Je telt getallen tot 256 als 3 karakters/bytes in plaats van 1.
quote:Juist. Maar in de invoer doe je dat niet en dat is niet eerlijk. De volgende invoer sequentie:Op vrijdag 22 juli 2005 16:51 schreef gelly het volgende:
[..]
Uhm nee. Ik kan met een byte aangeven welke plaats het priemgetal heeft in de index van Mesenne priemgetallen. Je moet die getallen niet als karakters zien maar als de integere weergave van bytes.
100 255 8 1 3
is niet 9 bytes waard zoals jouw applet zou zeggen, maar 5. Vergeet niet dat een willekeurig bestand niet alleen bestaat uit de getallen 0-9 maar het complete ASCII alfabet. Als je dat omzet naar getallen kom je op sequenties als hierboven.
Kortom, je compressie is (helaas) niet zo goed als het lijkt.
quote:Als ik dit omzet naar (ASCII) getallen wordt het:N‹'³aÜÛ˜æ
quote:In getallen 0-9 heeft het dus een lengte van 27 bytes. Jouw applet geeft:78 139 39 179 97 220 219 152 127 230
quote:Kortom, hij vergroot het bestand van 10 naar 21 bytes!!Used primes : 21 for 27 decimals
Compression is 77 %
quote: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.Op vrijdag 22 juli 2005 16:27 schreef gelly het volgende:
Ja, ik sla namelijk niet de priemgetallen zelf op, alleen het hoeveelste Mersenne priemgetal het is.
quote:Zie mijn voorbeeld.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.
Het idee is mooi, dat wel.
quote:Dat is geen eerlijke vergelijking.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.
quote:Er is geen restant...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.
quote: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.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.
quote:Dat doet het applet van Gelly ook precies, dus volgens mij is dit wel een eerlijke vergelijking.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".
quote:Hij bedoelt met restant: alles wat niet in de range 0-9 valt.
quote:Dat kan omdat dat 'karakter' onderdeel is van een groter getal.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".
quote:Snap je wat ik bedoel met mijn getallenvoorbeeld? Dat bestand van 10 bytes?Op vrijdag 22 juli 2005 17:56 schreef gelly het volgende:
[..]
Dat kan omdat dat 'karakter' onderdeel is van een groter getal.
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.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.
quote: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.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.
quote:Okee, dan heb ik twee briljante manieren om files te compressen: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?
quote:Alleen als het precies een groot priemgetal is.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?
quote:Moet zijn (10*1 + 90*2 + 156*3)/256 = 2.57 decimalen gemiddeld per byte.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
quote:Ehh nee. Volgens mij heb je zojuist gewoon een eerste opzet voor een Huffman tree ontworpen, alleen dan met behulp van bytes ipv bitsOp 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 ]
quote:Ik heb expres 'leesbare' karakters gebruikt. Succes.x6YNsgK#mJ
quote: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.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?
quote: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.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?
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):
quote: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: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!
quote: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.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
quote:gnomaat, kun je deze vraag nog even beantwoorden?
quote:Hint: als het decimale getal 112131032202120121 is, van welke ascii waardes komt dat dan? (m.a.w. welke originele file hoort hierbij?)Op vrijdag 22 juli 2005 20:22 schreef BUG80 het volgende:
gnomaat, kun je deze vraag nog even beantwoorden?
quote:Bedoel je dat één getallenreeks kan staan voor meerdere ASCII files?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 ]
Dit figuur is met een paar regels code te maken, het opgeslagen plaatje kost veel meer ruimte dan de broncode.
quote:Nog langer dan iets wat niet werkt ja, dus je moet welOp 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?
quote:Ja, dat is waar.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.
quote:jaja, maar, dat zegt niet zoveel.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.
quote: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.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.
quote:Ehm, meer dan 232768 films. En dat zijn er heel wat meer dan er ooit gemaakt zullen wordenOp 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.
quote:Natuurlijk, die priemgetallen zijn hetzelfde als "onze" priemgetallen.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.
quote:Ik weet het wel zekerAlleen ben ik bang dat de volgende stelling geldig is: Ontbinding van een getal in andere getallen zal gemiddeld genomen niet tot compressie leiden.
quote:ahum. mijn foutOp 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
ik zal hem maar niet editen, anders lijkt het zo raar. goede morgen 
quote:Neem een bakkie koffie zou ik zeggenOp zaterdag 23 juli 2005 12:48 schreef -erwin- het volgende:
[..]
ahum. mijn fout
quote:Ja ik ook, gevoelsmatig. Heb je toevallig een link naar een wiskundig bewijs?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.
quote:Als zowel beeld als geluid ongecomprimeerd zijn zou het wel moeten kunnen, toch? Maarja, ze waren wel gecomprimeerd, dat is juist het punt.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.
quote:en dan heb jeOp 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
quote: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.Op zaterdag 23 juli 2005 13:03 schreef Pietverdriet het volgende:
en dan heb je10 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
quote: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?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.
quote:Nee zo niet, maar moet niet al te moeilijk zijn.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?
quote: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?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?
quote:Als je de vorige topics doorleest zal je zien dat de uitvinding geen van beide deed, omdat het helemaal niet kan.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?
quote:Say what! Was het NEP?!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
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...
quote:dat is evident.Op dinsdag 26 juli 2005 00:31 schreef DirtyHarry het volgende:
Ik heb wiskundig bewijs dat Sloots verhaal niet kan kloppen.
quote: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...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.
quote:lossy compressionOp 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...
quote:Maar ik geloof dat uit Sloot zijn "paper" (
) niet te destilleren valt of hij nu wel of geen lossy compressie gebruikt of niet.quote: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.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...
quote:Hij zei dat ie verliesloos (pixel voor pixel) een film weer kon laten zienOp dinsdag 26 juli 2005 00:39 schreef HenryHill het volgende:
[..]
Maar ik geloof dat uit Sloot zijn "paper" (
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: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.Op dinsdag 26 juli 2005 00:36 schreef -erwin- het volgende:
lossy compression
quote: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?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?
quote: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.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.
quote: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.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.
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.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:Ik bedoel alleen maar dat je bewijs geen bewijs is. Je zegt het volgende: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.
quote: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.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.
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 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:NeuhOp 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.
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
drinkenquote: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?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 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
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:Ja ok dat kloptOp 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).
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 lastigquote:Inderdaad, zoniet onmogelijk. Dat betekent dat hij één of ander patroon had moeten vinden dat voor alle films geldt.Op dinsdag 26 juli 2005 14:19 schreef DirtyHarry het volgende:
[..]
Ja ok dat klopt
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: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 nietOp 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.
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:Er is een verschil tussen nooit een bestand kunnen verkleinen = geen enkel bestand kunnen verkleinen, en niet alle bestanden kunnen verkleinen.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?
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: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!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 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:Klopt, helemaal mee eens, net als je theorie over WinZip in je andere reactie.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.
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: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: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
- 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/cm2) 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.
quote:Lees de vorige topics eens door.Op donderdag 28 juli 2005 21:56 schreef BUG80 het volgende:
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:Het is gemakkelijk in te zien dat de verzameling mogelijke films groter is dan de verzameling "sleutels" van 64 kB. Je kunt (in theorie) bijvoorbeeld alle mogelijke reeksen van 65 kB op papier uitschrijven en van iedere reeks een film maken. Of iedere mogelijk plaatje genereren met een resolutie van 1000x1000 en van iedere plaatje een film maken. Met een sleutelgrootte van 64 kB worden verschillende films in deze voorbeelden op dezelfde sleutel afgebeeld.Op donderdag 28 juli 2005 21:56 schreef BUG80 het volgende:
[..]
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:(bron)Theorem:
No program can compress without loss *all* files of size >= N bits, for
any given integer N >= 0.
Proof:
Assume that the program can compress without loss all files of size >= N
bits. Compress with this program all the 2^N files which have exactly N
bits. All compressed files have at most N-1 bits, so there are at most
(2^N)-1 different compressed files [2^(N-1) files of size N-1, 2^(N-2) of
size N-2, and so on, down to 1 file of size 0]. So at least two different
input files must compress to the same output file. Hence the compression
program cannot be lossless.
[...]
Note that no assumption is made about the compression algorithm. The proof applies to
*any* algorithm, including those using an external dictionary, or repeated
application of another algorithm, or combination of different algorithms, or
representation of the data as formulas, etc... All schemes are subject to the
counting argument. There is no need to use information theory to provide a
proof, just very basic mathematics.
quote:Tekst is vooral niet willekeurig omdat het vooral afhankelijk is van ongeveer 50 tekens (letters, cijfers en speciale tekens), terwijl er in een byte 256 kunnen worden gerepresenteerd. Films bestaan inderdaad al uit een heleboel redundantie, daarom kun je een enorme film met DivX of een gelijkwaardig compressie-algoritme al behoorlijk verkleinen. De ongeloofwaardigheid komt niet voort uit het kunnen comprimeren van films, maar het hebben van een chipknip met daarop 32 volledige films.Op donderdag 28 juli 2005 21:56 schreef BUG80 het volgende:
[..]
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.
quote:Ja dat klopt.Op vrijdag 29 juli 2005 09:50 schreef Barati het volgende:
[..]
Het is gemakkelijk in te zien dat de verzameling mogelijke films groter is dan de verzameling "sleutels" van 64 kB. Je kunt (in theorie) bijvoorbeeld alle mogelijke reeksen van 65 kB op papier uitschrijven en van iedere reeks een film maken. Of iedere mogelijk plaatje genereren met een resolutie van 1000x1000 en van iedere plaatje een film maken. Met een sleutelgrootte van 64 kB worden verschillende films in deze voorbeelden op dezelfde sleutel afgebeeld.
[..]
(bron)
Maar. Er zijn zeker reeksen te verzinnen die zeker niet voor zullen komen, of onwaarschijnlijk. Bijvoorbeeld: films met alleen maar zwarte frames, of films die voor 50% uit ruis bestaan. Of films waarin in elk frame het complete mogelijke kleurenpallet voorkomt. En zo kun je nog wel even doorgaan. Het zou kunnen, dat het algoritme van Sloot "normale" films verkleint en "onwaarschijnlijke" films vergroot, net als WinZip.
Ergens moet er een ondergrens zijn van wat mogelijk is qua compressie van films en die ligt niet bij 80 GigaByte, lijkt me.
Ik kan het niet vaak genoeg zeggen: ik geloof er ook niet in. En als Sloot had gezegd dat zijn algoritme werkt op alle mogelijke bestanden viel dat ook wiskundig te bewijzen.
Je zou een random generator een film kunnen laten generen. Laat de generator 1,5 uur * 3600 sec * 25 frames * (720 * 480) pixels * 24 bits per pixel uitrekenen.
Hoe groot is de kans dat hier een film uitkomt die ook echt kijkbaar is? Ik denk verwaarloosbaar klein.
Kortom, kennelijk voldoet de data in films aan bepaalde conventies / patronen.
[edit]
Als je die generator alle mogelijke films van 1,5 uur zou laten berekenen (een onmogelijke klus, maar goed), dan zou je na afloop 99,999999999999999999..% weg kunnen gooien als zijnde waardeloos. Misschien is Sloot's algoritme daarop gebaseerd.
[/edit]
[ Bericht 10% gewijzigd door BUG80 op 29-07-2005 10:58:41 ]
quote:Nee, das volledige onzin.Op vrijdag 29 juli 2005 10:53 schreef BUG80 het volgende:
Ik kan het ook anders formuleren:
Je zou een random generator een film kunnen laten generen. Laat de generator 1,5 uur * 3600 sec * 25 frames * (720 * 480) pixels * 24 bits per pixel uitrekenen.
Hoe groot is de kans dat hier een film uitkomt die ook echt kijkbaar is? Ik denk verwaarloosbaar klein.
Kortom, kennelijk voldoet de data in films aan bepaalde conventies / patronen.
[edit]
Als je die generator alle mogelijke films van 1,5 uur zou laten berekenen (een onmogelijke klus, maar goed), dan zou je na afloop 99,999999999999999999..% weg kunnen gooien als zijnde waardeloos. Misschien is Sloot's algoritme daarop gebaseerd.
[/edit]
quote:Dit kan ook niet anders. Zie bewijs hierboven.Op vrijdag 29 juli 2005 10:41 schreef BUG80 het volgende:
[..]
Ja dat klopt.
Maar. Er zijn zeker reeksen te verzinnen die zeker niet voor zullen komen, of onwaarschijnlijk. Bijvoorbeeld: films met alleen maar zwarte frames, of films die voor 50% uit ruis bestaan. Of films waarin in elk frame het complete mogelijke kleurenpallet voorkomt. En zo kun je nog wel even doorgaan. Het zou kunnen, dat het algoritme van Sloot "normale" films verkleint en "onwaarschijnlijke" films vergroot, net als WinZip.
quote:Sloot beweerde dat een film ongeacht de lengte verkleind kon worden tot een sleutel van 64 kB.Ergens moet er een ondergrens zijn van wat mogelijk is qua compressie van films en die ligt niet bij 80 GigaByte, lijkt me.
Ik kan het niet vaak genoeg zeggen: ik geloof er ook niet in. En als Sloot had gezegd dat zijn algoritme werkt op alle mogelijke bestanden viel dat ook wiskundig te bewijzen.
quote:Kun je ook uitleggen waarom?
Laten we zeggen dat voor een complete ongecomprimeerde film 80 GB nodig is. Ik durf te wedden dat elke film kleiner te maken is dan dat.
Kun jij dan bewijzen waar de ondergrens dan wel ligt?
quote:Het genereren van random films en dan bijna alles weggooien is volledige onzin, dat hoef ik je toch niet uit te leggen, wel?
quote:We moeten eerst afspreken wat we bedoelen met een film. Als iedere mogelijke bitstring in aanmerking komt bestaat er geen algoritme dat iedere film lossless verkleint.Op vrijdag 29 juli 2005 11:26 schreef BUG80 het volgende:
[..]
Kun je ook uitleggen waarom?
Laten we zeggen dat voor een complete ongecomprimeerde film 80 GB nodig is. Ik durf te wedden dat elke film kleiner te maken is dan dat.
Kun jij dan bewijzen waar de ondergrens dan wel ligt?
Als je slecht specifieke bitstrings wilt rekenen tot de verzameling films dan zult je precies moeten definiëren welke dit zijn.
quote:Ik gebruikte dit gedachtenexperiment om aan te geven dat er kennelijk reeksen zijn te verzinnen die onwaarschijnlijk zijn, net als dat WinZip gebruik maakt van het feit dat er een hele hoop teksten zijn die onwaarschijnlijk zijn. Waar ga ik de fout in?Op vrijdag 29 juli 2005 11:28 schreef Pietverdriet het volgende:
[..]
Het genereren van random films en dan bijna alles weggooien is volledige onzin, dat hoef ik je toch niet uit te leggen, wel?
quote:Dat is precies wat ik bedoel! En wie gaat er bewijzen dat het niet mogelijk is om te voorspellen welke bitstrings wel en niet waarschijnlijk zijn?Op vrijdag 29 juli 2005 11:34 schreef Barati het volgende:
Als je slecht specifieke bitstrings wilt rekenen tot de verzameling films dan zult je precies moeten definiëren welke dit zijn.
quote:Er zijn een enorme hoeveelheid films "kijkbaar". Neem een willekeurige film. Alleen al door films in verschillende talen na te synchroniseren en/of te ondertitelen groeit het al enorm. Daarnaast kun je alle mogelijke scenes toevoegen en weglaten of kleding, cast, bewoording, geluidseffecten en/of muziek aanpassen in elke wilekeurige combinatie. Zoals al eerder is opgemerkt is het aantal variaties op een enkele film al bijna eindeloos.Op vrijdag 29 juli 2005 10:53 schreef BUG80 het volgende:
Ik kan het ook anders formuleren:
Je zou een random generator een film kunnen laten generen. Laat de generator 1,5 uur * 3600 sec * 25 frames * (720 * 480) pixels * 24 bits per pixel uitrekenen.
Hoe groot is de kans dat hier een film uitkomt die ook echt kijkbaar is? Ik denk verwaarloosbaar klein.
Kortom, kennelijk voldoet de data in films aan bepaalde conventies / patronen.
[edit]
Als je die generator alle mogelijke films van 1,5 uur zou laten berekenen (een onmogelijke klus, maar goed), dan zou je na afloop 99,999999999999999999..% weg kunnen gooien als zijnde waardeloos. Misschien is Sloot's algoritme daarop gebaseerd.
[/edit]
quote:Zeker, maar draai het eens om: het aantal realisaties dat je kunt maken in 80 GB waar je niks aan hebt is nog veel groter.Op vrijdag 29 juli 2005 11:46 schreef XoxIx het volgende:
[..]
Er zijn een enorme hoeveelheid films "kijkbaar". Neem een willekeurige film. Alleen al door films in verschillende talen na te synchroniseren en/of te ondertitelen groeit het al enorm. Daarnaast kun je alle mogelijke scenes toevoegen en weglaten of kleding, cast, bewoording, geluidseffecten en/of muziek aanpassen in elke wilekeurige combinatie. Zoals al eerder is opgemerkt is het aantal variaties op een enkele film al bijna eindeloos.
quote:Dan draai ik het gewoon nog een keer om. Het aantal combinaties dat je kunt maken met 64 KB is veel kleiner.Op vrijdag 29 juli 2005 11:49 schreef BUG80 het volgende:
[..]
Zeker, maar draai het eens om: het aantal realisaties dat je kunt maken in 80 GB waar je niks aan hebt is nog veel groter.
quote:En?Op vrijdag 29 juli 2005 11:49 schreef BUG80 het volgende:
[..]
Zeker, maar draai het eens om: het aantal realisaties dat je kunt maken in 80 GB waar je niks aan hebt is nog veel groter.
quote:Ok voorbeeld: Neem een willekeurige film. Door eindeloos te variëren met acteurs, talen, scenes, enz kun je, zeg, 1010 verschillende versies maken.
Echter, door de film aan te passen zodat je er niks meer aan hebt, door bijvoorbeeld door elk 3e frame zwart te maken, of elk 4e, of de helft eruit te knippen, enz zijn er, zeg 10100 versies te maken waar je niets aan hebt.
Net als met tekst, is het aantal films dat niet voor zal komen vele malen groter dan het aantal dat wel voor zal komen, dat is alles wat ik probeer te zeggen.
quote:Inderdaad, maar nog steeds zo goed als oneindig (2^(64*1024*8) is heel, heel groot). Dus waar ligt de ondergrens nou echt?Op vrijdag 29 juli 2005 11:51 schreef XoxIx het volgende:
[..]
Dan draai ik het gewoon nog een keer om. Het aantal combinaties dat je kunt maken met 64 KB is veel kleiner.
quote:Ja, dat begrijp ik, maar wat heeft dat er mee te maken?Op vrijdag 29 juli 2005 11:55 schreef BUG80 het volgende:
[..]
Ok voorbeeld: Neem een willekeurige film. Door eindeloos te variëren met acteurs, talen, scenes, enz kun je, zeg, 1010 verschillende versies maken.
Echter, door de film aan te passen zodat je er niks meer aan hebt, door bijvoorbeeld door elk 3e frame zwart te maken, of elk 4e, of de helft eruit te knippen, enz zijn er, zeg 10100 versies te maken waar je niets aan hebt.
Net als met tekst, is het aantal films dat niet voor zal komen vele malen groter dan het aantal dat wel voor zal komen, dat is alles wat ik probeer te zeggen.
quote:Ik probeer de link te leggen met het comprimeren van andere typen bestanden, zoals tekst. Zodra je aan kunt geven dat er realisaties zijn die waarschijnlijker zijn dan andere, kun je gemiddeld genomen compressie bereiken.Op vrijdag 29 juli 2005 12:00 schreef Pietverdriet het volgende:
[..]
Ja, dat begrijp ik, maar wat heeft dat er mee te maken?
Hoe kleiner de groep waarschijnlijke realisaties, hoe groter de maximaal haalbare compressie.
quote:Welke ondergrens?Op vrijdag 29 juli 2005 11:57 schreef BUG80 het volgende:
[..]
Inderdaad, maar nog steeds zo goed als oneindig (2^(64*1024*8) is heel, heel groot). Dus waar ligt de ondergrens nou echt?
Waarom denk je dat ie hard zou zijn?
Als je een film als Patton op DVD (MPEG 2) zet van Film, heb je verlies, in oplossend vermogen, in kleur, etc.
Als je die MPEG 2 nog verder comprimeerd naar DIVX, XVID, MPEG4, MJPG whatever heb je nog meer verlies.
is je file dan 750 Mb is ie te groot voor een normale CD, ah, dan haal je wat resolutie weg, en dan past ie wel.
Zo kan je doorgaan, maar de kwaliteit wordt steeds minder.
Dus die ondergrens ligt daar waar je de minimale kwaliteit legt.
quote:Ja, maar wat is nu je punt wat je daar mee wilt zeggen? Dat is allang en uitvoerig behandeld in de vorige topics. Dat je een database kan nemen met de filmbouwsteentjes, en een sleutel die ze achter elkaar plakt.Op vrijdag 29 juli 2005 12:04 schreef BUG80 het volgende:
[..]
Ik probeer de link te leggen met het comprimeren van andere typen bestanden, zoals tekst. Zodra je aan kunt geven dat er realisaties zijn die waarschijnlijker zijn dan andere, kun je gemiddeld genomen compressie bereiken.
Hoe kleiner de groep waarschijnlijke realisaties, hoe groter de maximaal haalbare compressie.
quote:Ja in het geval van lossy compressie. In het geval van lossless compressie ligt de ondergrens daar waar het uiteindelijke bestand minimale redundantie heeft.Op vrijdag 29 juli 2005 12:05 schreef Pietverdriet het volgende:
[..]
Welke ondergrens?
Waarom denk je dat ie hard zou zijn?
Als je een film als Patton op DVD (MPEG 2) zet van Film, heb je verlies, in oplossend vermogen, in kleur, etc.
Als je die MPEG 2 nog verder comprimeerd naar DIVX, XVID, MPEG4, MJPG whatever heb je nog meer verlies.
is je file dan 750 Mb is ie te groot voor een normale CD, ah, dan haal je wat resolutie weg, en dan past ie wel.
Zo kan je doorgaan, maar de kwaliteit wordt steeds minder.
Dus die ondergrens ligt daar waar je de minimale kwaliteit legt.
quote:Ok, mijn fout, ik zal het allemaal nog eens aandachtig gaan lezen. Ik probeer alleen aan te ontkrachten dat er een wiskundig bewijs zou zijn dat de onmogelijkheid aantoont van deze compressie.Op vrijdag 29 juli 2005 12:08 schreef Pietverdriet het volgende:
[..]
Ja, maar wat is nu je punt wat je daar mee wilt zeggen? Dat is allang en uitvoerig behandeld in de vorige topics. Dat je een database kan nemen met de filmbouwsteentjes, en een sleutel die ze achter elkaar plakt.
quote:Definieer nu eerst eens wat je bedoelt met een film. Dan kunnen we verder.Op vrijdag 29 juli 2005 12:10 schreef BUG80 het volgende:
[..]
Ok, mijn fout, ik zal het allemaal nog eens aandachtig gaan lezen. Ik probeer alleen aan te ontkrachten dat er een wiskundig bewijs zou zijn dat de onmogelijkheid aantoont van deze compressie.
quote:Mijn definitie van film: één realisatie uit de verzameling mogelijke bitstrings van rond de 80 GB (klopt die grootte ongeveer) die bovendien kijkbaar is.Op vrijdag 29 juli 2005 13:03 schreef Barati het volgende:
[..]
Definieer nu eerst eens wat je bedoelt met een film. Dan kunnen we verder.
Met kijkbaar bedoel ik dat het om echte beelden gaat, geen ruis-achtige verschijnselen. Een wiskundige definitie van kijkbaar is een Nobelprijs waard denk ik.
quote:Zelfs in theorie niet, want de hoeveelheid papiermoleculen die je daarvoor nodig hebt is veel groter dan het aantal deeltjes in het heelal (dat laatste wordt geloof ik geschat op 1080).Op vrijdag 29 juli 2005 09:50 schreef Barati het volgende:
Het is gemakkelijk in te zien dat de verzameling mogelijke films groter is dan de verzameling "sleutels" van 64 kB. Je kunt (in theorie) bijvoorbeeld alle mogelijke reeksen van 65 kB op papier uitschrijven en van iedere reeks een film maken.
In de praktijk is het aantal films dat er bestaat en ooit in de toekomst gemaakt kan worden, veel kleiner dan het aantal combinaties dat je in 64 KB (of ook al in 4 KB) kwijt kunt.
quote:kijkbaar := comprimeerbaar tot +/- 700 MBOp vrijdag 29 juli 2005 13:07 schreef BUG80 het volgende:
Met kijkbaar bedoel ik dat het om echte beelden gaat, geen ruis-achtige verschijnselen. Een wiskundige definitie van kijkbaar is een Nobelprijs waard denk ik.
quote:Met de huidige technieken, ja.Op vrijdag 29 juli 2005 13:40 schreef gnomaat het volgende:
[..]
kijkbaar := comprimeerbaar tot +/- 700 MB
Ik kan trouwens een hoop niet-kijkbare films maken die comprimeerbaar zijn tot 700 MB, dus dat gaat ook niet helemaal op.
quote:Vandaar mijn toevoeging "in theorie". Ik denk dat je mijn voorbeeld met het papier wel begrijpt...Op vrijdag 29 juli 2005 13:40 schreef gnomaat het volgende:
[..]
Zelfs in theorie niet, want de hoeveelheid papiermoleculen die je daarvoor nodig hebt is veel groter dan het aantal deeltjes in het heelal (dat laatste wordt geloof ik geschat op 1080).
In de praktijk is het aantal films dat er bestaat en ooit in de toekomst gemaakt kan worden, veel kleiner dan het aantal combinaties dat je in 64 KB (of ook al in 4 KB) kwijt kunt.
De verzameling van mogelijke films is vele male groter dan het aantal combinaties die je kunt maken met 64 kB. Het is irrelevant of die films ook allemaal tegelijkertijd zouden kunnen bestaan.
Het is simpel om een programma te schrijven dat b.v. 2^1000000 unieke "kijkbare" films kan genereren (d.w.z. een zo'n film uit deze verzameling genereert).
[ Bericht 1% gewijzigd door Barati op 29-07-2005 14:19:59 ]
quote:Ja, daar heb jij weer een punt. Je zou van een film willekeurig beeldjes kunnen spiegelen, inverteren, enz en dan heb je zo veel meer realisaties. De vraag is: zijn al deze realisaties waarschijnlijk (intuitief zeg je van niet: je gaat niet naar een film zitten kijken waarin willekeurige beeldjes zijn gespiegeld). Een algoritme wat de waarschijnlijkheid van deze realisaties in acht neemt is waarschijnlijk niet te schrijven. In de praktijk, althans.Op vrijdag 29 juli 2005 14:14 schreef Barati het volgende:
Het is simpel om een programma te schrijven dat b.v. 2^1000000 unieke "kijkbare" films kan genereren (d.w.z. een zo'n film uit deze verzameling genereert).
quote:Neem een film met een tijdsduur van 1 uur. Deze bevat 24 * 60 * 60 = 86400 beelden. In ieder beeld zou je één pixel iets kunnen wijzigen (het minst significante bit van deze pixel bijvoorbeeld). Het aantal mogelijke gewijzigde films is hiermee groter dan 2^64k. Als het origineel kijkbaar is dan zijn deze gewijzigde films dat ook (bij een kleurendiepte van 24 bit zul je geen verschil merken tussen het origineel en de gewijzigde film)Op vrijdag 29 juli 2005 14:19 schreef BUG80 het volgende:
[..]
Ja, daar heb jij weer een punt. Je zou van een film willekeurig beeldjes kunnen spiegelen, inverteren, enz en dan heb je zo veel meer realisaties. De vraag is: zijn al deze realisaties waarschijnlijk (intuitief zeg je van niet: je gaat niet naar een film zitten kijken waarin willekeurige beeldjes zijn gespiegeld). Een algoritme wat de waarschijnlijkheid van deze realisaties in acht neemt is waarschijnlijk niet te schrijven. In de praktijk, althans.
[ Bericht 100% gewijzigd door Barati op 29-07-2005 14:45:47 ]
[ Bericht 100% gewijzigd door Barati op 29-07-2005 14:45:28 ]
quote:Ah, there you go, dat lijkt me wel een goed bewijs ja.Op vrijdag 29 juli 2005 14:35 schreef Barati het volgende:
[..]
Neem een film met een tijdsduur van 1 uur. Deze bevat 24 * 60 * 60 = 86400 beelden. In ieder beeld zou je één pixel iets kunnen wijzigen (het minst significante bit van deze pixel bijvoorbeeld). Het aantal mogelijke gewijzigde films is hiermee groter dan 2^64k. Als het origineel kijkbaar is dan zijn deze gewijzigde films dat ook (bij een kleurendiepte van 24 bit zul je geen verschil merken tussen het origineel en de gewijzigde film)
Bestaat er eigenlijk een formule waarmee de hoeveelheid "redundantie" in een willekeurig bestand is te berekenen, m.a.w. wat de maximaal haalbare compressie van dat bestand zou zijn?
quote:neeOp vrijdag 29 juli 2005 14:52 schreef BUG80 het volgende:
[..]
Ah, there you go, dat lijkt me wel een goed bewijs ja.
Bestaat er eigenlijk een formule waarmee de hoeveelheid "redundantie" in een willekeurig bestand is te berekenen, m.a.w. wat de maximaal haalbare compressie van dat bestand zou zijn?
quote:Ok. Kort en bondig
De vraag of een bestand kan worden gecomprimeerd tot N bytes is alleen te weerleggen met een tegenvoorbeeld, het is niet te bewijzen dat het wel kan zonder de code erbij te geven.
quote:dit klinkt wel leukOp donderdag 21 juli 2005 17:18 schreef Danny het volgende:
[..]
heel simpel uitgelegd:
een bestand zet je om in een getal. dit kan gewoon het bestand in binaire stand zijn (nullen en enen), maar ook het bestand in decimale waarden (000-255).
Dat getal is vele miljoenen tot miljarden tekens lang, maar het blijft één enkel getal.
Dat getal ga je vervolgens omzetten in eenoptelsomvermenigvuldiging van priemgetallen, welke je wiskundig noteert (een paar bytes per priemgetal).
voila, je hebt het bestand gereduceerd tot een paar honderd Kb.
Probleem is dat er enorm veel rekenkracht nodig is om de juiste priemgetallen en formules te vinden.
Heb je dat eenmaal gedaan dan is de omschakeling naar het oorspronkelijke bestand relatief eenvoudig.
De wiskundige notaties worden gewoon voluit neergezet, de optelsommen worden gemaakt en je hebt je bestand weer in binaire/decimale notatie en dus je oorspronkelijke bestand.
(heel simpel gezegd, niet zo makkelijk uit te voeren)
jammer dat factorisatie van grote
[ Bericht 3% gewijzigd door McCarthy op 29-07-2005 19:15:07 ]
quote:1231387Op vrijdag 22 juli 2005 16:15 schreef gelly het volgende:
http://www.free-space.us/primer/Applet1.html
Je kunt deze applet beter in een standalone viewer bekijken, zowel firefox als IE zweten nogal als het ingegeven getal erg groot wordt. Het loopt niet vast, al lijkt het wel zo.
Calculating ...
Calculating ...
Calculating ...
New prime found
Calculating ...
New prime found
Calculating ...
New prime found
Used primes : 8 for 7 decimals
Compression is 114 %
quote:MersenneOp vrijdag 22 juli 2005 16:27 schreef gelly het volgende:
[..]
Ja, ik sla namelijk niet de priemgetallen zelf op, alleen het hoeveelste Mersenne priemgetal het is.
als je een echt krachtige computer hebt zou je natuurlijk ook gewoon de echte priemen kunnen fixen
quote:jpeg werkt met fractals dacht ikOp 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.
De bestanden die ingepakt worden zijn data van de aarde
quote:1% maar?Op vrijdag 29 juli 2005 19:41 schreef McCarthy het volgende:
geofysici werken met een compressie factor van 1%
De bestanden die ingepakt worden zijn data van de aarde
Maar goed, op de vele terabytes die een gemiddelde seismische meting opleveren scheelt dit aardig wat dollars.
quote:jep
quote:dat was het woord wat ik zochtMaar goed, op de vele terabytes die een gemiddelde seismische meting opleveren scheelt dit aardig wat dollars.