mega-compressie !

en btw...het is wiskundig aangetoond dat die 64 niet mogelijk zijn..het is te weinig data

quote:

Op woensdag 20 juli 2005 13:02 schreef JasperE het volgende:
en btw...het is wiskundig aangetoond dat die 64 niet mogelijk zijn..het is te weinig data

Slaat nergens op. Je moet buiten de gebaande paden kijken.

quote:

Op woensdag 20 juli 2005 15:47 schreef yootje het volgende:
Slaat nergens op. Je moet buiten de gebaande paden kijken.

De 1 + 1 = 3 paden i.p.v. de 1 + 1 = 2 paden?

juist, buiten de gebaande paden. 1 pixel staat voor een kleur, rgb samen wit, nakka rgb zwart. je kan een weg aanleggen die zo groot is als nederland (2d denken) of je kan een soort 3d kubus maken met daarin "rotondes, vanaf een unieke plaats op de rotonde aankomen (soort paardesprong) zorgt dat de pixel een bepaalde kleur aanneemt, op die manier kan je imo redelijk snel en compressieloos een beeld opbouwen, compressie betekend in dit geval nl grof gezegd dat je voor iedere stap moet in en uitpakken, binnen het 2d denken best acceptabel maar niet toereikend voor het echte race werk . nogmaals , ik heb zelf 123 niet het antwoord maar als de beste kerel zo'n apparaat had dan was dat voor 1000% zeker op die basis, een extra dimensie in stroom gebruiken en de echte rekenaars hier kunnen je voorrekenen hoe intressant of t is om iets 3d ipv 2d te benaderen

quote:

Op woensdag 20 juli 2005 16:02 schreef st0mpie het volgende:
juist, buiten de gebaande paden. 1 pixel staat voor een kleur, rgb samen wit, nakka rgb zwart. je kan een weg aanleggen die zo groot is als nederland (2d denken) of je kan een soort 3d kubus maken met daarin "rotondes, vanaf een unieke plaats op de rotonde aankomen (soort paardesprong) zorgt dat de pixel een bepaalde kleur aanneemt, op die manier kan je imo redelijk snel en compressieloos een beeld opbouwen, compressie betekend in dit geval nl grof gezegd dat je voor iedere stap moet in en uitpakken, binnen het 2d denken best acceptabel maar niet toereikend voor het echte race werk . nogmaals , ik heb zelf 123 niet het antwoord maar als de beste kerel zo'n apparaat had dan was dat voor 1000% zeker op die basis, een extra dimensie in stroom gebruiken en de echte rekenaars hier kunnen je voorrekenen hoe intressant of t is om iets 3d ipv 2d te benaderen

Hoe wil jij 3d rekenen?

Even heel simpel uitgelegd waarom het onmogelijk is, ongeacht hoe hij ertegenaankeek (ander binair systeem, 3d-denken of wat dan ook).

Stel, hij beweert dat hij alle films kan comprimeren tot 1 bit aan data. Dan zijn er voor het gecomprimeerde bestand, hoe de compressie ook is, 2 mogelijkheden: een 0 en een 1.

Een programma die dit gecomprimeerde bestand uit gaat pakken, gaat er weer de echte film van maken. We laten dit programma even 3 films inpakken en daarna uitpakken.
1e film: Back to the Future.
Het inpakprogramma geeft een 0 als resultaat.
2e film: Back to the Future 2.
Het inpakprogramma geeft een 1 als resultaat.
3e film: Back to the Future 3.
Het inpakprogramma geeft weer een 0 als resultaat (hij moet wel een resultaat geven dat al gebruikt is, want er zijn niet meer mogelijkheden).

Vervolgens willen we de films uitpakken. Het uitpakprogramma leest het gecomprimeerde bestand, en er blijkt een 0 te staan. Hoe kan het uitpakprogramma nou weten of het om BttF1 of Bttf3 ging? Dat kan het uitpakprogramma niet weten, want er is geen verschil tussen de bestanden.
Daarom is het onmogelijk om 3 (of meer) films in te pakken met 1 bit aan informatie.

Dit is ZONDER AANNAMES over hoe het ingepakt is. Er kunnen wiskundige technieken gebruikt zijn die we nog niet kennen, computertechnieken die we pas over 300 jaar terugvinden, maar hoe je het ook probeert, dit zal niet gaan. Omdat 3>2, en dat blijft zo wat je ook zal doen.

Daarom kun je ook bewijzen dat het ONMOGELIJK is dat je alle mogelijke films (>256⁶⁵⁵³⁶) kunt opslaan in 256⁶⁵⁵³⁶ bits aan informatie. Mensen zeggen niet dat het niet kan omdat het niet voor te stellen is, of omdat we niet weten hoe het zou moeten, of omdat we het onwaarschijnlijk achten, maar het kan niet omdat het ONMOGELIJK is. Onafhankelijk van de gebruikte techniek. De man kan nog zo slim geweest zijn, dingen die onmogelijk zijn (zoals 2>3) gaat hij niet voor elkaar krijgen.
Dit heeft echt niks te maken met dat wij te beperkt tegen het probleem aankijken.

_{En Michael J. Fox is stoerrrr}

Thabit heeft al laten zien dat de bewering van de Sloot algoritme in het beste geval overdreven is. De interessantere vraag is nu hoeveel overdreven is.

quote:

de man had een uitvinding waarmee hij een bestand van welk formaat dan ook kon terugbrengen tot 64Kb én in real-time kon uitpakken zonder verlies

De man had een uitvindingen waarmee hij willekeurig grote bestanden naar zijn keuze lossless kon terugbrengen tot 64Kb

De man kon willekeurige bestanden van een bepaald formaat (ongecomprimeerde films?) terugbrengen tot 64Kb zonder merkbaar kwaliteitsverlies

Deze zijn wel een stuk minder spectaculair, maar wel mogelijk. En met een beetje overdrijven zit je al aan de beloftes van het Sloot algoritme.

De theorieen die hier besproken worden over een alternatieve wijze van opslag zijn uitgesloten daar het op een smartcard pastte. Aangenomen dat hij geen eigen type smartcard ontwikkeld heeft met een eigen lezer is het onmogelijk dat hij het op een andere manier opsloeg dan binair.

quote:

Op woensdag 20 juli 2005 16:55 schreef SlaadjeBla het volgende:
De theorieen die hier besproken worden over een alternatieve wijze van opslag zijn uitgesloten daar het op een smartcard pastte. Aangenomen dat hij geen eigen type smartcard ontwikkeld heeft met een eigen lezer is het onmogelijk dat hij het op een andere manier opsloeg dan binair.

De sleutel (die waarschijnlijk zeer groot moet zijn, en in het kastje ergens opgeslagen zou zijn) kan wel op een andere manier opgeslagen zijn.

Het is overigens altijd nog 64Kb + 370Mb aan data binnen het systeem.

quote:

Op woensdag 20 juli 2005 17:00 schreef Lynx666 het volgende:
Het is overigens altijd nog 64Kb + 370Mb aan data binnen het systeem.

Dat maakt voor de sleutel niks uit, die blijft 64Kb, dus blijft het onmogelijk. Ook al was het 64Kb + 370000000 Tb aan data. (Ik denk dat jij dat wel snapt, maar anderen zouden het verkeerd kunnen opvatten.)

Ja een van de theorien is dus ook dat hij een coderingssleutel gevonden heeft, die voor videobanden beide kanten opwerkt (compressie en decompressie). Het is waarschijnlijk dat een dergelijke sleutel veel ruimte inneemt, omdat er uiteindelijk toch een paar GB aan rauwe data per film geproduceerd moet worden..

heb t boek net bij de bieb gehaald, denk niet dat er wat voor oplossing dan ook in staat. denk echter nog steeds dat je vanuit een "hersen"perspectief moet denken en misschien alle nulletjes en eentjes in de kast moet zetten. en onthou ten aller tyden dat een 60 gig comp 10 jr geleden tot een absolute absurditeit behoorde en dat je die tegenwoordig met een stalen gezicht gewoon bij de lidl kan kopen

quote:

Op woensdag 20 juli 2005 17:45 schreef st0mpie het volgende:
en onthou ten aller tyden dat een 60 gig comp 10 jr geleden tot een absolute absurditeit behoorde en dat je die tegenwoordig met een stalen gezicht gewoon bij de lidl kan kopen

Het was absurd omdat het te duur en onnodig was. Het was in principe wel mogelijk, de techniek was voorhanden. Huidige opslagsystemen werken weinig anders dan toen. Als dit waar is, wat ik ten zeerste betwijfel, dan zou het ons hele denken over computersystemen veranderen.

quote:

Op woensdag 20 juli 2005 17:45 schreef st0mpie het volgende:
heb t boek net bij de bieb gehaald, denk niet dat er wat voor oplossing dan ook in staat. denk echter nog steeds dat je vanuit een "hersen"perspectief moet denken en misschien alle nulletjes en eentjes in de kast moet zetten. en onthou ten aller tyden dat een 60 gig comp 10 jr geleden tot een absolute absurditeit behoorde en dat je die tegenwoordig met een stalen gezicht gewoon bij de lidl kan kopen

Nee, het perspectief maakt echt geen reet uit. Onmogelijk is onmogelijk.
Ik sluit niet uit dat er inpakmethodes komen die 10 keer zo goed zijn, ik wil best geloven dat over 10 jaar 60000000 TB weinig is, dat er chips komen die 1000 films op bioscoopkwaliteit tegelijkertijd kunnen afspelen, dat er een 'andere kijk' komt waardoor er miljoen keer zoveel informatie door een draadje kan, dat quantumcomputers op de markt komen. En dat je ze gratis bij een pak wasmiddel krijgt kan ook nog. Maar zelfs als er morgen aliens komen die enkele miljoenen jaren aan technische vooruitgang met ons delen, dan nog blijft hetgene dat beweerd wordt onmogelijk. ONMOGELIJK. Niet onwaarschijnlijk maar ONMOGELIJK.

mensen leg je er toch eens bij neer dat het ONMOGELIJK is

o.t. de beste compressie die ik ken is uharc tot factortje 20 in mijn ervaring

Sloot heeft ook nooit het woord "compressie" in de mond genomen. Hij heeft het altijd gehad over "codering". Wie het De Broncode in huis heeft moet Bijlage 1 er maar eens bijpakken, daar staat dat haarfijn uitgelegd.

quote:

Op woensdag 20 juli 2005 18:52 schreef gelly het volgende:
Waarom zou het gehele bestand met 1 logaritme opgeroepen moeten kunnen worden ? Uiteraard is dat onmogelijk, de sleutel zou immers dezelfde omvang als het bestand hebben.

Wanneer je van meerdere algoritmes gebruik maakt, moet je 1 of meer bits reserveren om aan te geven welk algoritme je gebruikt. Daardoor wordt je winst door deze methode dus nul.

Wat Pie.er zegt!

Al die onzin als "je moet buiten het binaire systeem denken" en "misschien werkt het net zoals hersenen" en "hij heeft een soort inverteerbare hashing bedacht"... Hou op!

Iedere hoeveelheid informatie is altijd in bits uit te drukken, ook al sla je het niet binair of digitaal op. En meer bits past niet in minder, dus onmogelijk, klaar.

Hey, is dit onderwerp weer terug van weggeweest?
Kansloos...

quote:

Op woensdag 20 juli 2005 19:01 schreef gnomaat het volgende:
Wat Pie.er zegt!

Al die onzin als "je moet buiten het binaire systeem denken" en "misschien werkt het net zoals hersenen" en "hij heeft een soort inverteerbare hashing bedacht"... Hou op!

Iedere hoeveelheid informatie is altijd in bits uit te drukken, ook al sla je het niet binair of digitaal op. En meer bits past niet in minder, dus onmogelijk, klaar.

Precies.

quote:

Op woensdag 20 juli 2005 18:59 schreef Lynx666 het volgende:
Sloot heeft ook nooit het woord "compressie" in de mond genomen. Hij heeft het altijd gehad over "codering". Wie het De Broncode" in huis heeft moet Bijlage 1 er maar eens bijpakken, daar staat dat haarfijn uitgelegd.

Dan sloeg heel het verhaal van "16 films op een kaartje van 64kb" dus nergens op. En wat noem jij een codering dan? Want dan ik kan ook wel films coderen in slechts 10 cijfers (hint: http://www.imdb.com )

Als die 4Kb per film alleen een soort indexering is, heb je er een apart blok data bij nodig waar de daadwerkelijke films op staan, en dat is compleet onzinnig (hoe had je precies gedacht films te gaan uitbrengen op dit medium). En als die 4Kb per film de film zelf bevat is het alsnog compressie, en dus onmogelijk, zie boven.

quote:

Op woensdag 20 juli 2005 19:04 schreef gelly het volgende:
Uhm, als je met een logaritme dat bv 10 bits beslaat 100 kb aan data kunt genereren is dat geen verlies.

Klopt, alleen dat kan niet. Want je kunt slechts een totaal insignificantie fractie van alle mogelijke stukken data van 100Kb tot 10 bits reduceren. 1024 van de 2⁸⁰⁰ om precies te zijn.

quote:

Op woensdag 20 juli 2005 19:04 schreef gelly het volgende:

Uhm, als je met een logaritme dat bv 10 bits beslaat 100 kb aan data kunt genereren is dat geen verlies.

Waarom gebruikte je dat algortime dan niet meteen?
Het feit blijft, met 100 Mb kun je veel meer verschillende bestanden maken dan met 64 Kb.

quote:

Op woensdag 20 juli 2005 19:09 schreef gelly het volgende:
Bedenk eens dat mensen eenmalig een blok data kopen, en dat je de rest (de index dus, die vrij klein is) razendsnel van het net afplukt tegen betaling. Dat is 2 keer kassa, en video on demand is voor iedereen beschikbaar.

Ik koop dus een enorme database met alle mogelijke films, en daarna koop ik individuele sleutels om specifieke films te kunnen bekijken.

1. Hoe groot denk je dat die database is?
2. Hoe werkt dat met films die morgen uitkomen?
3. De ruimtebesparing, waar in heel dit verhaal nou juist zo'n bombarie om werd gemaakt, is nu... hoe groot precies?

quote:

Op dinsdag 19 juli 2005 00:42 schreef Danny het volgende:

[..]

ik doel erop dat hij 16 gecomprimeerde films in real-time (en zelfs versneld) tegelijkertijd kun uitpakken en afspelen van een chipkaartje

Had hij dat chipkaartje ook zelf gefabriceerd dan? Want die kaartjes werken met FAT, en zijn systeem was niet eens op 0-en en 1-en gebaseerd.

quote:

Op woensdag 20 juli 2005 19:12 schreef gelly het volgende:
De 100Kb was slechts een voorbeeld, de truc is om zo groot mogelijke brokken data te vangen in een zo klein mogelijk algoritme. Daar is alleen enorm veel rekenkracht voor nodig.

Het is gewoon theoretisch onmogelijk. Je kunt niet grotere brokken data tot kleinere reduceren. Ook niet met heel veel rekenkracht.

Ongeacht wat je "klein" noemt of wat voor bizarre compressiemethode je gebruikt: je kunt hooguit 2^b verschillende brokken data van meer dan b bits reduceren tot b bits. En aangezien er altijd meer dan 2^b verschillende brokken data van meer dan b bits bestaan, kan het dus niet.

en zo loopt gnomaat tegen hetzelfde principe op als einstein en de heren v/d quantum , geeft niet , geeft slechts aan dat we nog een hoop te ontdekken hebben en nee, ik sluit pertinent niet uit dat iemand een simpele ingeving gehad kan hebben. alhoewel alle blabla eromheen op zn minst open staat voor verwarring

Hmm... een klein kastje, je moet er een chipkaart in steken om films te bekijken...

Hij heeft stiekem een Canal+ decoder gebruikt!!!

quote:

Op woensdag 20 juli 2005 19:24 schreef gelly het volgende:
[afbeelding]

6.320.430 cijfers

2^20996011-1

Het argument?

Dat je een brok data bestaande uit meer dan 6 miljoen cijfers hebt weten terug te brengen tot een stuk of 10?

quote:

Op woensdag 20 juli 2005 19:34 schreef gelly het volgende:
Theoretisch zou je een film in 1 priemgetal kunnen samenvatten, mits het een priemgetal is natuurlijk. Dat is het hele idee.

Ehm.. leg eens uit?

quote:

Op woensdag 20 juli 2005 19:35 schreef gelly het volgende:

[..]

Yep.

5.212.459 cijfers ... zo, zeg maar es welk getal ik bedoelde

quote:

Op woensdag 20 juli 2005 19:38 schreef gelly het volgende:

[..]

Het plaatje dat ik postte is het grootste priemgetal tot nu toe gevonden. Stel dat die cijfers echte data waren van bv een film, dan kun je je dus voorstellen wat de compressie is als je data met weinig gegevens weer kunt genereren.

Klopt, maar een priemgetal is niet hetzelfde als een willekeurig bestand.

quote:

Op woensdag 20 juli 2005 19:37 schreef Ravage het volgende:
5.212.459 cijfers ... zo, zeg maar es welk getal ik bedoelde

Nee, hij slaat het op als "2^20996011-1", dat is heel klein (als data om op te slaan) en daar kan de oorspronkelijke data natuurlijk weer uit gehaald worden.

quote:

Op woensdag 20 juli 2005 19:35 schreef gelly het volgende:
Yep.

Goed. Hoeveel stukken data van 6 miljoen cijfers kun je op deze manier reduceren, denk je?

Een gemiddelde film bestaat uncompressed uit grofweg 60.000 stukken van 6 miljoen cijfers. Afgerond op heel veel decimalen is de kans NUL dat er ook maar één van die 60.000 stukken voor zo'n korte notatie in aanmerking komt.

In de praktijk bestaat er dus geen enkele film ter wereld die je op deze manier kleiner krijgt.

Bovendien heb je hier ook nog de verkeerde kant op gewerkt, je begint met een gecomprimeerde vorm en kijkt vervolgens welke "oorspronkelijke" data toevallig op die manier kan worden opgeslagen. In de praktijk heb je natuurlijk andersom nodig.

quote:

Op woensdag 20 juli 2005 19:52 schreef gelly het volgende:
Er werd beweert dat je informatie maar tot een factor x kon comprimeren, wat dus helemaal niet het geval is. Ik beweer ook nergens dat een bestand precies met 1 priemgetal moet overeenkomen.

Afhankelijk van je compressiemethode kun je ieder blok data wel comprimeren tot 1 bit.

Namelijk: noem een blok data X, dan definieer ik de volgende compressiemethode: indien data = X, dan output = 0, en anders output = 1 gevolgd door de oorspronkelijke data. Deze methode reduceert X (die bijvoorbeeld 22 gigabyte groot kan zijn) tot één bit.

Wat natuurlijk bedoeld wordt is dat je in het algemeen informatie niet gegarandeerd kleiner kunt maken.
Of misschien bedoel je de limiet van Shannon. Die houdt nog steeds stand met jouw voorbeeld: bekijk maar eens hoe dat enorme blok data van jou er binair uitziet

quote:

Op woensdag 20 juli 2005 19:57 schreef gelly het volgende:
Jawel, ik heb het op kleine schaal getest.

Wat is klein? Filmpjes van bijvoorbeeld 3 seconden? Kan ik wat voorbeeld filmpjes sturen en kun jij dan eens aangeven hoe klein die worden?

En je hebt nog het probleem dat niet elk priemgetal de vorm 2^n-1 heeft, en niet elk getal te ontbinden is in '2^n-1'-factoren

quote:

Op woensdag 20 juli 2005 20:05 schreef gnomaat het volgende:

[..]

Wat is klein? Filmpjes van bijvoorbeeld 3 seconden? Kan ik wat voorbeeld filmpjes sturen en kun jij dan eens aangeven hoe klein die worden?

Je kan 1 bestand ook in meerdere bestanden verdelen...