Datacompressie van een student uit India

[Verwijderd]

Let op: deze thread is gestart naar aanleiding van dit bericht op de Tweakers.net Frontpage.

Ik vind de reacties om de datacompressieuitvinding onwaar te verklaren te kort door de bocht.

Stel dat we de claim dat het op een stuk papier zou moeten opslaan vergeten. We doen alles virtueel. Niks afdrukken en niks inscannen.

Kleuren vind ik ook niet belangrijk, we weten allemaal dat elke kleur een bepaalde code heeft en dat kost ook weer een aantal bits.

Wat ik wel boeiend vind zijn de symbolen. Stel dat we met elkaar 1 miljoen verschillende symbolen afspreken (een mega super ASCII tabel ofzo) en het symbool opslaan als plaatje. (mag ook als iets anders aangezien je plaatjes kunt aanpassen wat niet wenselijk is)

Bijvoorbeeld:

A = 00000000000000001
B = 00000000000000010
C = 00000000000000011
D = 00000000000000100
etc.
> = 10101111100000011
< = 10101111100000100

(het voorbeeld is niet doorgerekend, ik had waarschijnlijk nog veel meer 0 en moeten gebruiken)

[ Voor 11% gewijzigd door Confusion op 29-11-2006 08:04 ]

[Bor]

Voor mijn eigen begrip: welke datacompressie uitvinding? Misschien een link naar een artikel toevoegen aan de startpost oid?

[MADG0BLIN]

Bor de Wollef schreef op dinsdag 28 november 2006 @ 12:26:
Voor mijn eigen begrip: welke datacompressie uitvinding? Misschien een link naar een artikel toevoegen aan de startpost oid?

Volgens mij wordt dit artikel bedoelt: nieuws: Student claimt 256GB-opslag op A4-velletje

[Iblies]

Misschien niet onwaar,
alleen moet je het uiteindelijk het weer omzetten naar enen en nullen aangezien de processor dat alleen begrijpt.

[Bor]

Problemen waar je tegenaan zult lopen is dat papier erg kwetsbaar is en OCR technieken ook niet gehel feilloos werken. Printers die de zeer kleine figuurtjes echt haar scherp kunnen printen lijken mij ook niet goedkoop overigens. Daarnaast is het formaat natuurlijk erg onhandig voor bv thuis gebruik. En hoe wil je het papier beschermen? Stop of bv een haar zorgt mogelijk al voor het niet meer terug kunnen OCR'ren van de info.

[Dido]

Hoe ga jij je symbolen opslaan in minder bits dan ze vertegenwoordigen in je tabel

Verduidelijking: met 8 pixels die alleen zwart/wit kunnen zijn kan ik 256 mogelijkheden verzinnen. Dat is toevallig ook precies het aantal mogelijke waarden dat ik in 8 bits op kan slaan, dus win ik er niets mee

[Bor]

Dido schreef op dinsdag 28 november 2006 @ 12:55:
Hoe ga jij je symbolen opslaan in minder bits dan ze vertegenwoordigen in je tabel

Verduidelijking: met 8 pixels die alleen zwart/wit kunnen zijn kan ik 256 mogelijkheden verzinnen. Dat is toevallig ook precies het aantal mogelijke waarden dat ik in 8 bits op kan slaan, dus win ik er niets mee

Inderdaad. De enige winst die ik kan bedenken is dan ook de toevoeging van kleuren.

[Gomez12]

Verwijderd schreef op dinsdag 28 november 2006 @ 12:14:
Ik vind de reacties om de datacompressieuitvinding onwaar te verklaren te kort door de bocht.

Stel dat we de claim dat het op een stuk papier zou moeten opslaan vergeten. We doen alles virtueel. Niks afdrukken en niks inscannen.

Alles virtueel wat moet ik daar onder verstaan???

Wat ik wel boeiend vind zijn de symbolen. Stel dat we met elkaar 1 miljoen verschillende symbolen afspreken (een mega super ASCII tabel ofzo) en het symbool opslaan als plaatje. (mag ook als iets anders aangezien je plaatjes kunt aanpassen wat niet wenselijk is)

Bijvoorbeeld:

A = 00000000000000001
B = 00000000000000010
C = 00000000000000011
D = 00000000000000100
etc.
> = 10101111100000011
< = 10101111100000100

(het voorbeeld is niet doorgerekend, ik had waarschijnlijk nog veel meer 0 en moeten gebruiken)

Maar dan praat je gewoon over een referentie tabel. Dan kan je net zo goed zeggen dat je elke film in 1 bit kan opslaan zolang je van te voren maar een referentietabel hebt aangemaakt ter grootte van de film met de inhoud van de film ( 1 = de film, 0 = niet boeiend ).

En referentietabellen verliezen in de dagelijkse praktijk steeds meer en meer waarde doordat ze vanwege andere compressietechnieken ( divx / zip /rar / mp3 etc ) die op de bestanden zitten steeds slechter werken.

Met referentie tabellen kan je elke compressie factor halen zolang je referentie tabel maar goed genoeg is en daar zit hem het grote probleem met referentie tabellen. Deze moeten zo generiek zijn dat ze onmogelijk groot worden. Je kan best 1000 films "comprimeren"in 64 kb, alleen heb je wel een referentie tabel nodig die alle gegevens van die 1000 films bevat en in de praktijk zal dit referentiebestand dan zo onnoemelijk groot worden ( in dit voorbeeld 1000 films groot ) dat het onhandelbaar is.

[Zyppora]

Ik zie er wel wat in hoor. Als je figuren gebruikt van een bepaalde grootte, kun je een aantal dingen opslaan:

- kleur
- achtergrondkleur
- figuur

Dat zijn al drie kenmerken op een symbool van (noem eens iets) 1 mm².

Als je dan afspreekt dat er (bijvoorbeeld):

- 4 verschillende kleuren
- 4 verschillende achtergrondkleuren
- 4 verschillende figuren

gebruikt kunnen worden, heb je op elke mm² dus 4 * 3 * 4 = 48 verschillende mogelijkheden (en dat tegen slechts 2 mogelijkheden per bit).

Per cm² is dat dus 48¹⁰⁰ = 1.33 * 10¹⁶⁸ mogelijke combinaties.
Zijn er dus nogal wat.

[Gomez12]

Zyppora schreef op dinsdag 28 november 2006 @ 13:03:
Ik zie er wel wat in hoor. Als je figuren gebruikt van een bepaalde grootte, kun je een aantal dingen opslaan:

- kleur
- achtergrondkleur
- figuur

Dat zijn al drie kenmerken op een symbool van (noem eens iets) 1 mm².

Als je dan afspreekt dat er (bijvoorbeeld):

- 4 verschillende kleuren
- 4 verschillende achtergrondkleuren
- 4 verschillende figuren

gebruikt kunnen worden, heb je op elke mm² dus 4 * 3 * 4 = 48 verschillende mogelijkheden (en dat tegen slechts 2 mogelijkheden per bit).

Per cm² is dat dus 48¹⁰⁰ = 1.33 * 10¹⁶⁸ mogelijke combinaties.
Zijn er dus nogal wat.

En mm² verhoudt zich tot bit in welke mate???
Want volgens mij kan je beter een gevoeligere scanner/printer bouwen die gewoon zwart/wit pixels neergooit/inscant en dat gewoon doet op een resolutie dat er 25 bits op 1 mm² komen te staan. Is veel fouttoleranter.

[Zyppora]

Gomez12 schreef op dinsdag 28 november 2006 @ 13:11:
[...]

En mm² verhoudt zich tot bit in welke mate???
Want volgens mij kan je beter een gevoeligere scanner/printer bouwen die gewoon zwart/wit pixels neergooit/inscant en dat gewoon doet op een resolutie dat er 25 bits op 1 mm² komen te staan. Is veel fouttoleranter.

mm² verhoudt zich helemaal niet tot een bit. Het aantal bits per mm² is namelijk variabel (meer/minder kleuren/figuren). En fouttolerantie heeft voor een groot deel te maken met de implementatie van de printer/scanner.

[Verwijderd]

Gomez12 schreef op dinsdag 28 november 2006 @ 12:59:
[...]

Alles virtueel wat moet ik daar onder verstaan???

[...]

Maar dan praat je gewoon over een referentie tabel. Dan kan je net zo goed zeggen dat je elke film in 1 bit kan opslaan zolang je van te voren maar een referentietabel hebt aangemaakt ter grootte van de film met de inhoud van de film ( 1 = de film, 0 = niet boeiend ).

En referentietabellen verliezen in de dagelijkse praktijk steeds meer en meer waarde doordat ze vanwege andere compressietechnieken ( divx / zip /rar / mp3 etc ) die op de bestanden zitten steeds slechter werken.

Met referentie tabellen kan je elke compressie factor halen zolang je referentie tabel maar goed genoeg is en daar zit hem het grote probleem met referentie tabellen. Deze moeten zo generiek zijn dat ze onmogelijk groot worden. Je kan best 1000 films "comprimeren"in 64 kb, alleen heb je wel een referentie tabel nodig die alle gegevens van die 1000 films bevat en in de praktijk zal dit referentiebestand dan zo onnoemelijk groot worden ( in dit voorbeeld 1000 films groot ) dat het onhandelbaar is.

Met alles virtueel bedoel ik alles digitaal. Dus niets inscannen/uitprinten met de dataloss ten gevolge.

Wat je zegt over de referentietabel is inderdaad waar. Je hebt een grote tabel nodig. Maar wat is groot? 1 miljoen symbolen is niet heel groot, zal een keer 20 MB kosten denk ik.

Daarnaast moet je de referentietabel natuurlijk niet elke keer gaan meezenden, die installeer je samen met je winzip achtige programma.

Ik zie niet veel meer waarde in het toevoegen van kleuren, dan maak je alleen de referentietabel groter en dat lijkt me hetzelfde als het toevoegen van meer verschillende symbolen.

[Verwijderd]

Iblies schreef op dinsdag 28 november 2006 @ 12:35:
Misschien niet onwaar,
alleen moet je het uiteindelijk het weer omzetten naar enen en nullen aangezien de processor dat alleen begrijpt.

dat moet winzip toch ook? Dat noemen we uitpakken, toch?

gewoon een programma maken waar de tabel in staat met alle symbolen en welke "string" van enen en nullen dit symbool representeert. Dit programma zal daardoor een behoorlijke omvang hebben maar moet toch wel een 1 CDtje passen lijkt me.

Het inpakken en uitpakken (de nullen en enen vertalen naar de symbolen en andersom) zal misschien niet zo snel gaan, maar wat is dat nou voor probleem met hedendaagse processoren?

Zou dit niet veel betere compressie opleveren dan bijvoorbeeld winzip?

[Delerium]

Het voordeel van kleuren is wel dat er meer mogelijke kleuren zijn dan digitale nummers. 1 of 0 tegeover rood, groen, blauw zwart enzovoort. Wat op een HDD opgeslagen wordt als bytes (8-bits) kan je met een beetje kleurenpallet wel uitdrukken. Dan werkt ieder kleurenbitje als een byte. En middels scannen kan je dat weer terugconverteren.

Maar of het ooit toepasbaar wordt? Ik weet het zo net nog niet, papier is uiteindelijk net zo beperkt houdbaar als digitale data. Met die opmerking dat je voor papier geen moeite hoeft te doen om het uit te lezen.

[Verwijderd]

Waarom zou je het opslaan op papier? Ik snap die stap niet. 1 grote kleurenpalet zie ik wel, wat dan hetzelfde werkt als de referentietabel die ik noemde. Je kunt de kleurenreeks toch gewoon als plaatje digitaal verzenden? We hebben tegenwoordig toch internet?

[Dido]

Verwijderd schreef op dinsdag 28 november 2006 @ 13:28:
Wat je zegt over de referentietabel is inderdaad waar. Je hebt een grote tabel nodig. Maar wat is groot? 1 miljoen symbolen is niet heel groot, zal een keer 20 MB kosten denk ik.

20MB is 20 bytes per symbool dat je in je tabel zet. Da's nogal een verspilling aan ruimte, als je maar 1 miljoen verschillende combo's opslaat.

Voor 1 miljoen "characters" heb ik maar 20 bits nodig, en dat is meteen ook de maximum hoeveelheid informatie die je in iedere combo kwijt kunt (anders krijg je "gaten").

Als je dus winst wil behalen moet je met minder dan 20 bits naar de juiste 20-bit string in je tabel kunnen verwijzen. Succes

[Rob]

Verwijderd schreef op dinsdag 28 november 2006 @ 13:48:
Waarom zou je het opslaan op papier? Ik snap die stap niet. 1 grote kleurenpalet zie ik wel, wat dan hetzelfde werkt als de referentietabel die ik noemde. Je kunt de kleurenreeks toch gewoon als plaatje digitaal verzenden? We hebben tegenwoordig toch internet?

Een A4 is een voorbeeld. Het is ook niet handig om het op een A4 op te slaan, maar voor een niet-nerd is het een goed te begrijpen eenheid.

[Verwijderd]

Het probleem is dat je pc/decoder programma nu zoveel groter moet worden als de ruimte die je juist bespaart bij je uiteindelijke bestand (om al die combinaties weer terug te kunnen rekenen).

[Verwijderd]

Dido schreef op dinsdag 28 november 2006 @ 13:50:
[...]

Als je dus winst wil behalen moet je met minder dan 20 bits naar de juiste 20-bit string in je tabel kunnen verwijzen. Succes

stel dat je met 600-bit strings ga werken, daarmee moet het zeker lukken en past nog mooi op een CDtje

[Voutloos]

Dido schreef op dinsdag 28 november 2006 @ 13:50:
Als je dus winst wil behalen moet je met minder dan 20 bits naar de juiste 20-bit string in je tabel kunnen verwijzen. Succes

Precies, Pigeon Hole Principle, fijne wedstrijd.

Dit is gewoon geen compressie. Puur een beetje husselen met verschillende representaties en opeens schreeuwen dat je iets op een efficientere manier opslaat.

Verwijderd schreef op dinsdag 28 november 2006 @ 13:54:
[...]
stel dat je met 600-bit strings ga werken, daarmee moet het zeker lukken en past nog mooi op een CDtje

Hoeveel bits is het hele punt dus niet.

[Dido]

Verwijderd schreef op dinsdag 28 november 2006 @ 13:54:
stel dat je met 600-bit strings ga werken, daarmee moet het zeker lukken en past nog mooi op een CDtje

Wat wil je dan op dat CD'tje zetten? 1 miljoen random strings van 600 bits lang? Schiet je niet zoveel mee op. (Er passen er dan trouwens al zo'n 8 miljoen op dat cd'tje, maar goed).

Strings van 600 bits zijn pas interessant als je er 4.15*10¹⁸⁰ verschillende van in je tabel hebt. Oh, ja, en natuurlijk als je minder dan 600 bits aan informatie nodig hebt om naar ieder van die 4.15*10¹⁸⁰ mogelijke strings te verwijzen, dat blijft onveranderd.

[Verwijderd]

Verwijderd schreef op dinsdag 28 november 2006 @ 13:53:
Het probleem is dat je pc/decoder programma nu zoveel groter moet worden als de ruimte die je juist bespaart bij je uiteindelijke bestand (om al die combinaties weer terug te kunnen rekenen).

Dit is overduidelijk het probleem inderdaad, maar is het met de huidige harde schijven nog wel een probleem. Windows kost Gigabytes veel ruimte en een gemiddelde game kost tegenwoordig al 3 GB ofzo.

Als dit kan werken zou ik me niet druk maken over hoe groot het programma is dat het encoden/decoden doet.

[Dido]

Verwijderd schreef op dinsdag 28 november 2006 @ 14:09:
Als dit kan werken zou ik me niet druk maken over hoe groot het programma is dat het encoden/decoden doet.

Dat deed Sloot ook niet.

Wat win je er dan mee?

Als jij een cd met 900 GB in je PC plaatst, met de goede gegevens erop, dan kan ik je een spotgoedkoop USB-stickje leveren met 100 films erop (en ruimte over!).
Sterker nog, voor iedere van die 100 filmsheb ik maar 7 bits nodig!

[Verwijderd]

Dido schreef op dinsdag 28 november 2006 @ 14:04:
[...]

Wat wil je dan op dat CD'tje zetten? 1 miljoen random strings van 600 bits lang? Schiet je niet zoveel mee op. (Er passen er dan trouwens al zo'n 8 miljoen op dat cd'tje, maar goed).

Strings van 600 bits zijn pas interessant als je er 4.15*10¹⁸⁰ verschillende van in je tabel hebt. Oh, ja, en natuurlijk als je minder dan 600 bits aan informatie nodig hebt om naar ieder van die 4.15*10¹⁸⁰ mogelijke strings te verwijzen, dat blijft onveranderd.

De strings zijn niet "random", er moeten dan afspraken komen (lees protocol) over waar elke kleur of symbool welke string aan enen en nullen representeert.

En ja, het moeten er dan 4.15*10¹⁸⁰ verschillende zijn.

En waarom moet er minder dan 600 bits gebruikt worden om de informatie terug te rekenen? Als in de indextabel staat welke reeks nullen en enen hoort bij welke symbool/kleur, hoef je dit toch niet mee te zenden?

[Verwijderd]

Dido schreef op dinsdag 28 november 2006 @ 14:15:
[...]

Dat deed Sloot ook niet.

Wat win je er dan mee?

Als jij een cd met 900 GB in je PC plaatst, met de goede gegevens erop, dan kan ik je een spotgoedkoop USB-stickje leveren met 100 films erop (en ruimte over!).
Sterker nog, voor iedere van die 100 filmsheb ik maar 7 bits nodig!

Wat je ermee wint???? Het programma hoeft maar 1 malig te worden geinstalleerd.

[Nvidiot]

Als je met een string van 600 bits verwijst naar een entry in je tabel die ook 600 bits lang is, schiet het niet op natuurlijk. Je kan dan net zo goed gewoon die entry oversturen. De kunst is dus om met *minder* dan 600 bits uniek een entry in de tabel aan te geven, en dat is dus onmogelijk.

[Dido]

Verwijderd schreef op dinsdag 28 november 2006 @ 14:25:
Wat je ermee wint???? Het programma hoeft maar 1 malig te worden geinstalleerd.

En is bijna een Terabyte groot
En als je aan 100 mogelijke films niet genoeg hebt, moet je voor iedere film een 9 GB bestand(je) erbij installeren.

Voor iedere nieuwe film heb je maar een paar bits nodig.

Plus een DVD

[Verwijderd]

Nvidiot schreef op dinsdag 28 november 2006 @ 14:26:
Als je met een string van 600 bits verwijst naar een entry in je tabel die ook 600 bits lang is, schiet het niet op natuurlijk. Je kan dan net zo goed gewoon die entry oversturen. De kunst is dus om met *minder* dan 600 bits uniek een entry in de tabel aan te geven, en dat is dus onmogelijk.

Ik snap het probleem inderdaad. Hoe meer kleuren je nodig hebt, hoe meer bits het kost om 1 kleur vast te stellen.

Maar wat nu als je dus gaat werken met:

-een symbool
-een voorgrondkleur en
-een achtergrondkleur

zoals al eerder geopperd?

Zou je dan niet een plaatje kunnen opslaan dat kleiner is in bytes dan de hoeveelheid mogelijkheden die je ermee kunt maken?

[Verwijderd]

Dat compressie algoritme van die Indiër is in essentie gelijk aan die van het oude WinZip. Alleen de presentatie is anders. Bitreeksen worden kleuren en symbolen, een harde schijf wordt papier. Die Indiër verteld niet nieuws maar presenteert het zodanig dat het iets heel anders lijkt.

En er is telkens verwarring over mogelijke combinaties en het aantal gegevens dat je echt kunt opslaan.

16 bits geven 65536 mogelijke combinaties.
In 16 bits kun je slechts één Unicode karakter tegelijk opslaan.

Om 65536 verschillende Unicode karakters op te slaan, het je 65536 x 16 bits nodig.
Een gewone tekst bestaat nooit uit unieke verschillende tekens, maar komen telkens de zelfde tekens weer terug. Hier kun je compressie op toepassen, bijvoorbeeld door middel van een tabel.

Winzip gebruikt een binaire tabel.
De indiër gebruikt kleuren en symbolen als tabel.

Er iets niets nieuws, en de claim van 250 GB is onwaar.

[0rbit]

Ik zie hierin absoluut geen compressie. Deze meneer heeft hooguit een manier om data op te slaan. Afhankelijk van resolutie en nauwkeurigheid van de apparatuur kun je best 256 GB op een A4 kwijt.

Als je echter denkt dat je met een figuurtje meer informatie kunt opslaan dan met de pixels (die nota bene zo groot zijn als het Nyquist criterium toelaat!) dan heb je gewoon niets van informatietheorie begrepen!

Ik word echt heel erg moe van die halve voorbeelden... *zucht*

[Verwijderd]

Verwijderd schreef op dinsdag 28 november 2006 @ 14:41:

Winzip gebruikt een binaire tabel.
De indiër gebruikt kleuren en symbolen als tabel.

Er iets niets nieuws, en de claim van 250 GB is onwaar.

Dus als die een tabel maakt van, zeg, 2 GB groot met verschillende combinaties erin, zou dit geen goede compressie kunnen opleveren?

(en dan ga ik ervan uit dat iedereen die tabel van 2 GB op zijn computer heeft staan)

[Sendy]

Vergelijk het eens met met het volgende. Stel je hebt alle beschikbare speelfilms op DVD op je harddisk staan. Stel dat dit er 65536 zijn. Dan kan je met 16 bits iedere DVD aanwijzen. Nu kan je toch je 16 bit waarde toch geen compressie noemen van de hele (bijbehorende) DVD?

[Dido]

Verwijderd schreef op dinsdag 28 november 2006 @ 14:38:
Maar wat nu als je dus gaat werken met:

-een symbool
-een voorgrondkleur en
-een achtergrondkleur

zoals al eerder geopperd?

Zou je dan niet een plaatje kunnen opslaan dat kleiner is in bytes dan de hoeveelheid mogelijkheden die je ermee kunt maken?

Nopes, zeker niet in bytes(*). Als je een apparaat erbij maakt dat daadwerkelijk die verschillende kleuren waarneemt voordat je met bits begint, zou het kunnen, ja. Dan heb je een ADC gemaakt, trouwens.

(*)voor vier kleuren heb je twee bits nodig als je het "in bytes" opslaat. Daar ontkom je niet aan.

Verwijderd schreef op dinsdag 28 november 2006 @ 15:02:
Dus als die een tabel maakt van, zeg, 2 GB groot met verschillende combinaties erin, zou dit geen goede compressie kunnen opleveren?

(en dan ga ik ervan uit dat iedereen die tabel van 2 GB op zijn computer heeft staan)

Waar je aan voorbij gaat is dat je met die tabel van 2GB misschien 1 bestand van 200GB gecompressed hebt, maar niet alle andere bestanden die er zijn.
Met een gezipte versie van bestand A kan ik bestand B niet recupereren, dus heb ik er niets aan.
Als 100 mensen dus ieder 1 bestand willen hebben, moet iedereen 198 GB aan nutteloze tabel opslaan (2GB per niet-gebruikt bestand).

[Verwijderd]

Ik begin het te begrijpen. bedankt Dido. Zolang de processor met 0en en 1en werkt is er geen mogelijkheid iets uniek te identificeren zonder een unieke hoeveelheid data voor te gebruiken.

Het is dus tijd voor een processor die niet kijkt naar nullen en enen (plus zoveel volt en min zoveel volt), maar naar een processor die kijkt naar de kleur van licht. Net zoals bij glasvezel. Zo zouden we veel meer mogelijkheden kunnen verwerken met minder ruimte, toch?

Ik snap dat je de data dan niet meer kan gebruiken op een normale computer, maar dat lijkt me bijvoorbeeld voor een stand alone spelcomputer geen probleem, toch?

[Gomez12]

Verwijderd schreef op dinsdag 28 november 2006 @ 15:31:
Ik begin het te begrijpen. bedankt Dido. Zolang de processor met 0en en 1en werkt is er geen mogelijkheid iets uniek te identificeren zonder een unieke hoeveelheid data voor te gebruiken.

Het is dus tijd voor een processor die niet kijkt naar nullen en enen (plus zoveel volt en min zoveel volt), maar naar een processor die kijkt naar de kleur van licht. Net zoals bij glasvezel. Zo zouden we veel meer mogelijkheden kunnen verwerken met minder ruimte, toch?

Ik snap dat je de data dan niet meer kan gebruiken op een normale computer, maar dat lijkt me bijvoorbeeld voor een stand alone spelcomputer geen probleem, toch?

En wat schiet je er mee als je meer data kan opslaan op minder ruimte als je het hele principe van computers ( 0 en 1 ) opnieuw moet gaan bouwen. Als je ook gewoon kan minaturiseren en verder gaan op bestaande principes. Kijk eens naar een usb-stick van nu en een hdd van 20 jaar geleden. Het wordt al opgeslagen op minder ruimte, maar het principe van computers is wel nog steeds gelijk.

Nog daargelaten dat binair gewoon heel efficient en goedkoop werkt voor computers.
Werken met kleuren maakt het alleen maar complexer en alle onderdelen moeten duurder. ( vb. 0,6 is voor een pc nog steeds 1. Maar wat is oranje met een tintje groen ( is dit rood, geel of groen ??? ) )

[Sendy]

Maar dat maakt toch geen wezenlijk verschil? Je kan ook een computer bouwen die i.p.v. een binair systeem een trinair systeem gebruikt (0, 1, 2). Hier kan je per eenheid inderdaad meer informatie in opslaan. Echter het opslaan van de 3 waarden per eenheid is weer lastiger, en dit wordt alleen maar erger naarmate je een groter system wil gebruiken. Een groot voordeel van 0 en 1 (of niet-stroom en stroom) is dat het verschil zo goed gezien kan worden.

[0rbit]

Je hebt een hoeveelheid informatie die je altijd in bit-equivalent kunt uitdrukken. Dit is een rein theoretisch probleem en heeft niets met de verdere implementatie te maken.

Zelfs al zou je kleuren gaan gebruiken; De vraag is met welke nauwkeurigheid je kleuren kunt onderscheiden; dat bepaald hoeveel informatie je ermee kunt opslaan.

Ik begrijp hoe langer hoe minder van hoe deze meneer nu denkt 256GB op een blaadje papier te kunnen opslaan. Je kunt iets niet lossless comprimeren voorbij de hoeveelheid informatie die iets bevat volgens de wet van Shannon. Zodra je dit doet is het lossy.

Natuurlijk kun je in een A4 alle geschreven informatie ter wereld kwijt mits je de juiste techniek hebt; Een A4 bestaat uit nogal wat atomen die je zo kunt rangschikken dat hun topologische of geometrische indeling informatie beschrijft.

Ik word uit alle informatie die ik vind van deze meneer niet wijs; Waarin is deze vinding nieuw? Waarom spreekt men van compressie terwijl een opslagmethode besproken wordt? Etc.

Hier staan mijn bezwaren iets beter verwoord: http://www.techworld.com/storage/news/index.cfm?newsid=7432

[ Voor 5% gewijzigd door 0rbit op 28-11-2006 16:37 ]

[link0007]

je kan toch ook gewoon elk blokje los printen? en dan gewoon een 256kleuren palet, dus elk blokje is één letter... alleen moet één zo'n bit natuurlijk weer uit de standaard printerkleuren bestaan... weet iemand hoe groot één blokje moet zijn om 256kleuren te kunnen geven?

en geeft nog een mooi regenboog effect ook

[0rbit]

link0007 schreef op dinsdag 28 november 2006 @ 17:02:
je kan toch ook gewoon elk blokje los printen? en dan gewoon een 256kleuren palet, dus elk blokje is één letter... alleen moet één zo'n bit natuurlijk weer uit de standaard printerkleuren bestaan... weet iemand hoe groot één blokje moet zijn om 256kleuren te kunnen geven?

en geeft nog een mooi regenboog effect ook

Ik ben in een berekening op Tweakers.net uitgegaan van 1200 dpi en wel per dot 256 kleurniveaus per kanaal. Dan kom je op 133 MB per pagina. Natuurlijk is het in werkelijkheid met een printer iets lager, omdat je geen complete overlap in je dots hebt en je een kleurdiepte van 24 bits wel kunt vergeten.

Het is allemaal off-topic. Deze man beweert dat hij middels figuurtjes en kleurtjes meer informatie kan opslaan dan door alleen geprinte dots en hun kleuren. Dat is onzin; dat kan niet, simpelweg omdat geprinte dots altijd samen een figuurtje bouwen en je door het maken van een bepaald figuur bepaalt welke dots je maakt. Het weghalen van een dot om een ander figuur te maken levert je misschien een paar bits aan informatie, maar je verliest dus ook een dot die 24 bits o.i.d. aan informatie bevatte.

In de hele discussie lopen nogal wat begrippen als informatie en representatie ervan door elkaar. Ik denk dat het slim is daar even iets duidelijkheid over te scheppen.

Even een voorbeeldje. Neem nu het volgende "figuurtje":



Dit figuurtje bestaat uit 4 x 3 pixels die ieder een waarde hebben die danwel 0 (zwart) danwel 1 (wit) is. In totaal bestaat het dus uit 12 bits. (De bit is een eenheid die een keuze tussen 2 mogelijkheden beschrijft). De informatie in dit figuurtje is dus 12 bits. Die informatie haal je uit het feit dat je precies dit figuurtje hebt en niet een van de andere mogelijke figuren. (Dit zijn er 2^12-1). Dat is de informatie en niet het feit dat er 2^12 mogelijkheden zijn.

Verder zien we dat dit figuurtje met wat fantasie de letter A kan voorstellen. Veel andere ons bekende letters zijn ook mogelijkheden van die 2^12 figuurtjes. Het feit dat we in een herinterpretatie van het figuurtje (door het als een letter te interpreteren) als geheel de letter A ontwaren, voegt geen informatie toe. De informatie is dat we de combinatie (vlnr en vbnb) 000010000010 aantreffen.

Zo moet je dit probleem zien. Je hebt een oplossend vermogen van je medium. Neem je de hoogste resolutie wat betreft dimensies (hoe groot is een "pixel") en nauwkeurigheid (ook een dimensie; in dit geval 0 en 1) dan legt dit de hoeveelheid informatie die een figuurtje kan bevatten in het geheel vast.

Neem je een kleurenbeeld dan heb je in feite geen binair figuur meer, maar een figuur waarbij iedere pixel bijvoorbeeld 24 bits voorstellen (3 kanaals RGB bijvoorbeeld). Dan heb je nog steeds een maximum van 24x12 bits aan informatie.

Let wel: Voeg je compressie aan dit soort figuren toe dan gebeurt er feitelijk nog steeds niets met de hoeveelheid informatie. Het is eerder omgekeerd; je kunt alleen bronnen comprimeren die redundant zijn. Dat wil zeggen dat er meer symbolen uit de bron komen dan strict noodzakelijk om de maximale hoeveelheid informatie over te brengen.

Pas je in dit geval compressie toe dan beperk je het aantal geldige figuren, omdat niet iedere figuur een geldige ongecomprimeerde tegenhanger heeft. Zo kan ik de figuren die letters voorstellen comprimeren door de 26 letters van ons alfabet met een 5 bits code te representeren. (2^5 = 32, dus je kunt ook nog wat leestekens kwijt). Netto representeert een letter van ons alfabet dus een informatie van 2log(26), wat ongeveer gelijk is aan 4.7 bits.

Compressie pas je toe wanneer uit statistische analyse van de figuren die je in een reeks hebt blijkt dat één van de combinaties veel vaker voorkomt dan de andere. Dan loont het om deze reeks door een korter, andere reeks te vervangen. Wel moet je er dan voor zorgen dat je de overige figuren nog juist representeert. Dit is wat bijvoorbeeld in de Huffmann compressie gebeurt (o.a. WinZip).

[ Voor 54% gewijzigd door 0rbit op 28-11-2006 19:51 ]

[MSalters]

Verwijderd schreef op dinsdag 28 november 2006 @ 15:31:
Ik begin het te begrijpen. bedankt Dido. Zolang de processor met 0en en 1en werkt is er geen mogelijkheid iets uniek te identificeren zonder een unieke hoeveelheid data voor te gebruiken.

Het is dus tijd voor een processor die niet kijkt naar nullen en enen (plus zoveel volt en min zoveel volt), maar naar een processor die kijkt naar de kleur van licht. Net zoals bij glasvezel. Zo zouden we veel meer mogelijkheden kunnen verwerken met minder ruimte, toch?

Op zich is 0/1 als opslagmedium niet overal meer in gebruik. Intel Strataflash gebruikt al 0/1/2/3. Dat wordt gewoon gemapt naar 0/2 + 0/1, en op die manier heb je dus 2 bits per cel. Het gevolg is wel dat de nivo's op 0.45 Volt zitten. Van 2 naar 4 bits betekent dat je van 0.45V naar 0.11V zou dalen. Voor een beetje extra bits gaat je marge dus heel snel omlaag.

Met kleur heb je op zich vergelijkbare mogelijkheden, maar ook daar geldt: hoeveel ruimte is er tussen rood en groen? Voor elke bit halveren je marges.

[Henk007]

Zoals zo vaak bij dit soort claims wordt er weer volop gespeculeerd, zowel in de FP reakties, als in dit topic. Zelf ben ik razend nieuwsgierig naar de originele publicatie van die kerel. Die is echter nergens te vinden, tenminste niet door mij. In geen enkel nieuwsbericht wordt vermeld in welk wetenschappelijk tijdschrift zal worden gepubliceerd. Nogmaals, zonder de harde feiten is een inhoudelijke discussie zinloos.

[Oyster]

Datacompressie van een student uit India

Jan? Ben jij het?

[MicroWhale]

Er worden hier een paar denkfouten gemaakt. Er wordt voornamelijk teveel in bits gedacht. Dit denken moet even losgelaten worden om te begrijpen wat deze man heeft gedaan. Als je dit om gaat zetten naar bits dan is het weer even groot als dat het was.

Waarom?

Omdat het geen compressie is, maar een opslag anders dan die in bits. In plaats van de oude vertrouwde 0 en 1 pakt meneer een aantal kleuren en symbolen. Hiervan is de informatiedichtheid per eenheid natuurlijk veel groter dan die van de twee cijfers. Logisch.

Maar niemand durft verder te denken en iedereen zegt dat het per definitie onmogelijk is omdat we 'nou eenmaal' bits hebben.

Het probleem zit hem hier in hoe het opgeslagen wordt. Dan en slechts dan als de wetenschap een manier vindt om in plaats van nullen en enen, symbolen en kleuren op te slaan op een of andere harde schijf, dan heeft deze opslagmethode nut. Opslaan op een stuk papier brengt namelijk een hoop real-world interface-problemen met zich mee, zoals verkleuring door warmte en wellicht andere natuurkundige en biologische processen.

Het gaat dus niet echt om het medium papier maar wel om de toevoeging van een dimensie aan het opslaan van gegevens. Als men dit gaat toepassen bij het opslaan met licht (dat is in de maak, toch?) Dan zou men de informatiedichtheid door het gebruik kleur alleen al met een veelvoud (in het slechtste geval met een factor 2) omhoog kunnen gooien.

[Confusion]

Verwijderd schreef op dinsdag 28 november 2006 @ 15:31:
Ik begin het te begrijpen. bedankt Dido. Zolang de processor met 0en en 1en werkt is er geen mogelijkheid iets uniek te identificeren zonder een unieke hoeveelheid data voor te gebruiken.

Elke andere manier om informatie te beschrijven is uiteindelijk uit te drukken in bits.

Daarnaast: je kan sowieso niets uniek identificeren zonder een unieke hoeveelheid data te gebruiken. Immers: als twee dingen door dezelfde data worden geidentificeerd, welke van de twee kies je dan als je dat stuk data tegenkomt? Als dat afhangt van bijvoorbeeld de context, dan zit daar alsnog data in opgeslagen en is je concept van 'de' data die iets identificeert te nauw.

maar naar een processor die kijkt naar de kleur van licht. Net zoals bij glasvezel.

Glasvezelcapaciteit druk je ook in bits uit. Dat is gewoon de kleinste eenheid van informatie en dat gaat nooit meer veranderen. Om informatie over te dragen zal je op zijn minst moeten aangeven of iets waar of onwaar is, wel of niet bestaat.

[0rbit]

MrWilliams schreef op woensdag 29 november 2006 @ 08:06:
Er wordt voornamelijk teveel in bits gedacht. Dit denken moet even losgelaten worden om te begrijpen wat deze man heeft gedaan.

Volg eerst maar eens de cursus "Informatietheorie", voordat je met dit soort beweringen komt.

Men doet net alsof informatie compleet onbegrepen is terwijl er toch echt vrij veel over bekend is. Zolang je daar niet van op de hoogte bent zul je inderdaad geneigd zijn te denken dat een willekeurige student wel even iets nieuws kan uitvinden. Helaas, zo makkelijk is het niet meer...

[GH45T]

Maar als je nu bijvoorbeeld één keer een kleurcode aangeeft met bitjes, vervolgens aangeeft op welke locaties deze zich bevindt. Ditzelfde doe je bij de ASCII caracters welke daar weer als het ware overheen liggen. Als laatste haal je nog data uit de combinatie die je kunt vormen met verschillende kleuren blokjes achter elkaar.

Het klinkt ongeloofelijk logisch om te zeggen dat een bit altijd een nul of een één is en dat je er ook nooit meer in op kunt slaan, maar misschien is het met slimme koppeling van technieken dus wel mogelijk. Kijk maar eens naar de revolutie die jpeg heeft betekend, normal gesproken zou je ook stellen dat een afbeelding niet kleiner is op te slaan dan als bitmap, immers elke pixel wordt vertegenwoordigt door zijn eigen kleurwaarde, maar door slimme combinaties te gebruiken is er wel degelijk wat mogelijk. Even voor de duidelijkheid, ik bedoel dus jpeg zonder kwaliteitsverlies, anders is het een scheve vergelijking.

[0rbit]

GH45T schreef op woensdag 29 november 2006 @ 09:15:
Als laatste haal je nog data uit de combinatie die je kunt vormen met verschillende kleuren blokjes achter elkaar.

Die combinatie ligt al vast door je data. Daarin kun je dus geen informatie stoppen zonder de voorgaande informatie te veranderen. Zie mijn voorbeeld met de letter 'A'.

Het klinkt ongeloofelijk logisch om te zeggen dat een bit altijd een nul of een één is en dat je er ook nooit meer in op kunt slaan, maar misschien is het met slimme koppeling van technieken dus wel mogelijk.

Jij ziet een bit als een schakelaar. Dat is een verwezenlijking van een bit. Echter een bit zelf is een eenheid van informatie. Het maakt niet uit of je de hoeveelheid informatie uitrekent in bits, in blups, in worps o.i.d. net zo min als het uitmaakt hoe je de massa van een object uitdrukt. Dat kan in pakken suiker, in grammen, in kilogrammen, in stones etc. Het verandert niets aan de massa van het object. Zo is het ook met informatie.

Kijk maar eens naar de revolutie die jpeg heeft betekend, normal gesproken zou je ook stellen dat een afbeelding niet kleiner is op te slaan dan als bitmap, immers elke pixel wordt vertegenwoordigt door zijn eigen kleurwaarde, maar door slimme combinaties te gebruiken is er wel degelijk wat mogelijk. Even voor de duidelijkheid, ik bedoel dus jpeg zonder kwaliteitsverlies, anders is het een scheve vergelijking.

Dat is onzin. JPEG baseert op een discrete cosine transform. De daarbij ontstane tabel kun je lossless door Huffmann comprimeren. De terugtransformatie geeft je dan een lossless JPEG. Je kunt de tabel ook korter maken en minder belangrijke frequenties weglaten. Dan ben je lossy bezig.
De feitelijke informatie in het beeld is niet de hoeveelheid pixels, maar juist de kleinst mogelijke representatie die lossless is.

Word nou even concreet. Wat bedoel je nu met "slimme combinaties"? Hoe kan ik ooit aantonen dat je onzin verkoopt als je nooit concreet wordt?

[GH45T]

Mr_Atheist schreef op woensdag 29 november 2006 @ 09:25:
Word nou even concreet. Wat bedoel je nu met "slimme combinaties"? Hoe kan ik ooit aantonen dat je onzin verkoopt als je nooit concreet wordt?

Nooit concreet? Het was mijn eerste reactie in dit topic hoor...

Maar goed, stel je slaat het volgende op:

3X5

Hieruit kun je op verschillende manieren informatie halen.

• 3 x 5 = 15 en beschrijft daarmee een karakter
• De 3 beschrijft een karakter
• De 5 beschrijt een karakter
• De X beschrijft een karakter
• Het eerste getal heeft de kleur rood beschrijft daarmee een karakter
• Het tweede getal heeft de kleur blauw beschrijft daarmee een karakter
• Als je de kleuren vermengd heb je paars beschrijft daarmee een karakter

Je hebt dus 7 uitgangspunten van informatie. Je hebt het volgend opgeslagen:

• Het cijfer 3
• De rode kleur van het cijfer 3
• De letter X
• Het cijfer 5
• De kleur van het cijfer 5

Je hebt dan 2 stukjes extra informatie gewonnen door te combineren. Hoe langer de string wordt hoe meer informatie je eruit kunt herlijden. Op een gegeven moment kun je er ook voor kiezen om niet meer telkens opnieuw de kleurcode mee te geven maar door bijvoorbeeld aan te geven dat teken 3,7,15, etc dezelfde kleurcode bevatten. Je gaat er vanuit dat de standaardkleur zwart is, vandaar dat ik ook niet apart heb aangegeven wat de kleur van X is.

[Verwijderd]

Dit is de informatietheorie variant, van de eeuwig terugkeerende dicussie over sneller dan het lichtreizen. Als je de achterliggende theorie kent is het antwoord heel eenvoudig en is het heel erg simple om te zien dat het gene dat beweerd wordt onmogelijk is. Helaas, veel mensen zijn niet op de hoogte van de theorie en komen dus aan met een soort boerenklompen logica, waar je gaten in kan blijven schieten tot je een ons weegt, maar voor elke "leek" (in de zin iemand die ergens geen kennis van heeft, dus niet negatief bedoelt) die je overtuigt staan er tien in de rij met vergelijkbare argumenten.

Volgens mij wordt het tijd, dat informatietheorie en SRT verplichte vakken worden op de middelbare school . En als we dan toch bezig zijn, doen we gelijk ook maar thermodynamica erbij. (Dat heeft toch een overlap met informatietheorie.)

[0rbit]

GH45T schreef op woensdag 29 november 2006 @ 09:39:
[...]

Nooit concreet? Het was mijn eerste reactie in dit topic hoor...

In iedere reactie vind ik dat je je argumenten of voorbeelden moet aandragen. Ik ben blij dat je dat nu doet.

Maar goed, stel je slaat het volgende op:

[...]

Wat sla je op? De beeldtenis of de tekenreeks? Kun je even duidelijk maken welke symbolen je toestaat in je beschrijving? Is 1x2 ook geldig?

Hieruit kun je op verschillende manieren informatie halen.

• 3 x 5 = 15 en beschrijft daarmee een karakter
• De 3 beschrijft een karakter
• De 5 beschrijt een karakter
• De X beschrijft een karakter
• Het eerste getal heeft de kleur rood beschrijft daarmee een karakter
• Het tweede getal heeft de kleur blauw beschrijft daarmee een karakter
• Als je de kleuren vermengd heb je paars beschrijft daarmee een karakter

Je hebt dus 7 uitgangspunten van informatie. Je hebt het volgend opgeslagen:

• Het cijfer 3
• De rode kleur van het cijfer 3
• De letter X
• Het cijfer 5
• De kleur van het cijfer 5

Je hebt dan 2 stukjes extra informatie gewonnen door te combineren.

Fout. Je hebt uit twee symbolen een derde, per definitie redundant symbool afgeleidt. Paars beschrijft al rood en groen samen, dat hoef je niet nog eens extra af te leiden. Dat 3x5 15 is weten we allemaal, maar 15 wordt volledig vastgelegd door de gegeven symbolen 3 en 5. Dat hoef je dus ook niet af te leiden, want je voegt er geen extra informatie aan toe dan wanneer je alleen 3 en 5 zou opslaan. Als je namelijk 3 en 5 opslaat maar je eens een keer geen 15 hebt, dan klopt het al niet meer.

Hoe langer de string wordt hoe meer informatie je eruit kunt herlijden.

Nee, dat is niet het hele verhaal. De hoeveelheid informatie die je vastlegt is gegeven door de lengte van je representatie en hoeveel symbolen je opneemt in je representatie.

Op een gegeven moment kun je er ook voor kiezen om niet meer telkens opnieuw de kleurcode mee te geven maar door bijvoorbeeld aan te geven dat teken 3,7,15, etc dezelfde kleurcode bevatten. Je gaat er vanuit dat de standaardkleur zwart is, vandaar dat ik ook niet apart heb aangegeven wat de kleur van X is.

Ja, en wat voegt dat dan toe? Als 3,7,15 altijd dezelfde kleur hebben; dan gooi je juist ruimte weg om informatie op te slaan.

Als ik jouw voorbeeld even generaliseer dan kom ik op het volgende. Je neemt de symbolen 1 tot 9 en voegt hieraan toe een symbool X in het midden. Dit symbool beschrijft geen informatie. Ik zou in feite 35 kunnen schrijven als ik 3x5 wil schrijven. Daarnaast neem je voor ieder symbool 4 mogelijke kleuren aan. Rood, groen, blauw en zwart. Ieder symbool uit deze representatie heeft dus 4 (kleuren) maal 9 types is gelijk aan 4x9=36 mogelijke waarden. Een symbool in jouw representatie beschrijft dus log2(36) = 5.1699 bits aan pure informatie. Een string van twee symbolen beschrijft dus maximaal het dubbele.

Let wel: Eventuele redundantie in de informatiebron doet niets af aan de hoeveelheid informatie die jouw representatie beschrijft. Je kunt oneindig vele schemas afleiden om een willekeurige bron tot aan het Shannon criterium te comprimeren. Daar voorbij wordt het lossy.

[Verwijderd]

GH45T schreef op woensdag 29 november 2006 @ 09:39:
[...]

Nooit concreet? Het was mijn eerste reactie in dit topic hoor...

Maar goed, stel je slaat het volgende op:

[...]

Hieruit kun je op verschillende manieren informatie halen.

• 3 x 5 = 15 en beschrijft daarmee een karakter
• De 3 beschrijft een karakter
• De 5 beschrijt een karakter
• De X beschrijft een karakter
• Het eerste getal heeft de kleur rood beschrijft daarmee een karakter
• Het tweede getal heeft de kleur blauw beschrijft daarmee een karakter
• Als je de kleuren vermengd heb je paars beschrijft daarmee een karakter

Je hebt dus 7 uitgangspunten van informatie. Je hebt het volgend opgeslagen:

• Het cijfer 3
• De rode kleur van het cijfer 3
• De letter X
• Het cijfer 5
• De kleur van het cijfer 5

Je hebt dan 2 stukjes extra informatie gewonnen door te combineren. Hoe langer de string wordt hoe meer informatie je eruit kunt herlijden. Op een gegeven moment kun je er ook voor kiezen om niet meer telkens opnieuw de kleurcode mee te geven maar door bijvoorbeeld aan te geven dat teken 3,7,15, etc dezelfde kleurcode bevatten. Je gaat er vanuit dat de standaardkleur zwart is, vandaar dat ik ook niet apart heb aangegeven wat de kleur van X is.

Maar je schiet er niks mee op. Want hoeveel ruimte heb je nodig om jouw symbolen te representeren? Zeker meer dan je nodig hebt om een paar bits te representeren. En dat is het punt. Je gaat nooit meer informatie op een blaadje krijgen dan circa 24bits per punt (en zelfs dat is een ruime overschatting) Dat levert je een informatiedichtheid op van zo'n 4 miljoen bits per vierkante centimeter. Op een A4 levert dat je een hoeveelheid data op van de orde van 1 GB of iets dergelijks (kan er een orde van grote naast zitten, maar dan waarschijnlijk in de optimistische richting.)

[GH45T]

Wat ik duidelijk probeer te maken is dat als je zowel 2, 4 als 8 op wilt slaan en zowel rood, blauw als paars je dan 2X4 op kunt slaan. 8 en paars zijn dan procesresultaten hiervan. De caracters die je wel opslaat doe je doormiddel van een uniforme methode zoals ASCII en je werkt bijvoorbeeld met een 16 kleuren pallet.

Ik denk ook dat je niet zozeer in bits moet gaan denken, je moet een extra tussenlaag tussen ruwe data en bruikbare data indenken.

Enigzins offtopic maar een kleine vergelijking kan wel, als ik een telefoonnummer intype op de vaste telefoon en ik bel iemand binnen mijn regio dan hoef ik het kengetal (077 in mijn geval) niet in te typen omdat de centrale dit automatisch al na kan gaan. Dit beschouw ik dan ook als procesgegevens, als je het een al weet en je krijgt het ander te zien kun je een combinatie maken en hier een uitkomst uit herleiden.

Als ik 3x5 op heb geschreven kun jij herleiden dat er 3 staat, dat er 5 staat, dat er een vermenigvuldigingsteken staat én dat de uitkomst 15 is zonder dat dit verder ergens staat genoteerd.

[Confusion]

GH45T schreef op woensdag 29 november 2006 @ 09:39:
Je hebt dan 2 stukjes extra informatie gewonnen door te combineren.

'Gewonnen' ten opzichte van wat? Dat je 7 willekeurige begrippen hebt weten te coderen in 5 willekeurige menselijke begrippen bewijst niets. Als je dit soort ideeen gaat proberen te systematiseren en te beschrijven zodat je er wiskundig iets over kunt zeggen, dan kom je er uiteindelijk op uit dat alles in eenheden van waar/onwaar, aan/uit, bestaand/niet bestaand uit te drukken is.

Met jouw 3 tekens en 2 kleuren kan je per teken 6 verschillende dingen aanduiden. Maar om aan te duiden welke kleur en welk teken je hebt gekozen heb je 3 bits nodig: 2 voor het teken en 1 voor de kleur. Met 3 bits kan ik 2^3 = 8 verschillende dingen aangeven, jij slechts 6. Jouw methode is dus minder efficient. Als je hem verbetert zodat je er uiteindelijk 8 kan aanduiden met elke 3 bits, dan heb je een ingewikkeld binair systeem bedacht.

[MicroWhale]

Mr_Atheist schreef op woensdag 29 november 2006 @ 09:05:
[...]


Volg eerst maar eens de cursus "Informatietheorie", voordat je met dit soort beweringen komt.

Men doet net alsof informatie compleet onbegrepen is terwijl er toch echt vrij veel over bekend is. Zolang je daar niet van op de hoogte bent zul je inderdaad geneigd zijn te denken dat een willekeurige student wel even iets nieuws kan uitvinden. Helaas, zo makkelijk is het niet meer...

Heb jij dat wel gedaan dan?

Vertel me dan maar dat het volgende niet waar is:

Aanname:
1. Een bit kan twee standen in- en uitgelezen worden 0 en 1
2. Een kleur kan in acht standen in- en uitgelezen 0,1,2,3,4,5,6,7
3. De fysieke opslaggrootte van een bit is even groot als die van een kleur


Is de informatiedichtheid van de kleur dan niet 4 keer zo groot als die van de bit? Is dan de opslagcapaciteit van het medium met de kleur, gegeven de gelijke opslaggrootte, niet 4x zo groot?

Dat is namelijk wat ik uit probeerde te leggen. Dat je dan naar een computer toe die 7 moet vertalen in 3 bits staat hier even buiten beschouwing want we hebben het over de manier van opslag.

[ Voor 11% gewijzigd door MicroWhale op 29-11-2006 10:36 ]

[0rbit]

GH45T schreef op woensdag 29 november 2006 @ 10:22:
Wat ik duidelijk probeer te maken is dat als je zowel 2, 4 als 8 op wilt slaan en zowel rood, blauw als paars je dan 2X4 op kunt slaan. 8 en paars zijn dan procesresultaten hiervan. De caracters die je wel opslaat doe je doormiddel van een uniforme methode zoals ASCII en je werkt bijvoorbeeld met een 16 kleuren pallet.

En hoe kun jij meer informatie opslaan in het geheel dan als in de losse tekens? Juist als je correlaties in de data gaat inbouwen verlies je mogelijkheden. Het feit blijft: Jouw beschrijving heeft een bepaalde informatiedichtheid en die wordt niet ineens hoger als je je bedenkt dat je 15 niet hoeft op te slaan doordat je 3x5 opslaat.

Vergelijk het met bits in een computer; Ik hoef de som van de bits in een byte niet op te slaan; die kan ik gewoon opnieuw berekenen. (Natuurlijk kan ik die som mooi gebruiken om te bepalen of er in mijn byte bij de verzending niet per ongeluk bitjes zijn omgevallen. Zo kan ik het voorkomen van een fout detecteren.)

Ik denk ook dat je niet zozeer in bits moet gaan denken, je moet een extra tussenlaag tussen ruwe data en bruikbare data indenken.

Zolang jij geen informatietheoretische kennis hebt en niet eens in bits kunt denken, hoef je mij niet te vertellen dat ik anders zou moeten denken. In welke zin denk je dat een extra tussenlaag tussen ruwe data en bruikbare data helpt? Volgens mij snap jij het verschil niet tussen informatie en representatie. Je kunt wel honderden representaties bedenken en betogen dat je ermee meer informatie kunt opslaan dan het Shannon criterium voorschrijft, maar zolang je dit niet kunt aantonen heb je geen zaak.

Enigzins offtopic maar een kleine vergelijking kan wel, als ik een telefoonnummer intype op de vaste telefoon en ik bel iemand binnen mijn regio dan hoef ik het kengetal (077 in mijn geval) niet in te typen omdat de centrale dit automatisch al na kan gaan. Dit beschouw ik dan ook als procesgegevens, als je het een al weet en je krijgt het ander te zien kun je een combinatie maken en hier een uitkomst uit herleiden.

Dat is helemaal niet zo offtopic. Stel een regionale centrale heeft 10.000 abonnees. Hoeveel telefoonnummers moet deze centrale uitgeven om iedere abonnee een nummer te geven? Hoeveel informatie (in bits) moet ieder telefoonnummer dus bevatten om bij het draaiien van een nummer een unieke abonnee te bereiken? Kun je me dat even voorrekenen?

Als ik 3x5 op heb geschreven kun jij herleiden dat er 3 staat, dat er 5 staat, dat er een vermenigvuldigingsteken staat én dat de uitkomst 15 is zonder dat dit verder ergens staat genoteerd.

De uitkomst correleert direct met je input; je voegt dus geen informatie toe. Je kunt in jouw beschrijving nooit opslaan 3x5=12, want dat klopt gewoon niet. Waar jij je denk ik door laat misleiden in jouw eigen beschrijving is dat je het interpreteert als de gangbare tekens die we kennen voor getallen en vermenigvuldigen.

Nogmaals: De hoeveelheid informatie wordt puur en alleen vastgelegd door het aantal mogelijke symbolen en de hoeveelheid symbolen er in je beschrijving geldig zijn. Dit kun je ten alle tijden uitdrukken in bits. De bit is de kleinste eenheid van informatie.

[0rbit]

MrWilliams schreef op woensdag 29 november 2006 @ 10:34:
[...]


Heb jij dat wel gedaan dan?

Vertel me dan maar dat het volgende niet waar is:

Aanname:
1. Een bit kan twee standen in- en uitgelezen worden 0 en 1
2. Een kleur kan in acht standen in- en uitgelezen 0,1,2,3,4,5,6,7
3. De fysieke opslaggrootte van een bit is even groot als die van een kleur


Is de informatiedichtheid van de kleur dan niet 4 keer zo groot als die van de bit? Is dan de opslagcapaciteit van het medium met de kleur, gegeven de gelijke opslaggrootte, niet 4x zo groot?

Dat is namelijk wat ik uit probeerde te leggen. Dat je dan naar een computer toe die 7 moet vertalen in 3 bits staat hier even buiten beschouwing want we hebben het over de manier van opslag.

Ja, ik wel en jij blijkbaar niet.

1. Een bit heeft twee standen ongeacht je techniek. Over in- en uitlezen hoeven we dus niet te spreken. Een bit representeert een keuze tussen 2 mogelijkheden.
2. Een kleur zoals jij hem beschrijft heeft 8 mogelijkheden per symbool. De informatie van een symbool dat een kleur beschrijft is in jouw geval log2( 8 ) = 3 bits.
3. Het gaat niet om fysieke opslaggroottes. We hebben het over informatie en de compressie ervan. Maar goed, als je wil; Als het je lukt om in een volume gelijk aan een bit uit 1) een kleur uit 2) op te slaan, dan verhoog je de informatiedichtheid met een factor 3.

Het gaat allemaal voorbij aan het principiele bezwaar. Mijn stelling is: Je kunt uit een figuur bestaande uit symbolen niet meer informatie halen, dan uit de losse symbolen en dat schijnen de oneindige-compressie-gelovigen hier niet in te zien.

[MicroWhale]

Mr_Atheist schreef op woensdag 29 november 2006 @ 10:47:
[...]
Het gaat allemaal voorbij aan het principiele bezwaar. Mijn stelling is: Je kunt uit een figuur bestaande uit symbolen niet meer informatie halen, dan uit de losse symbolen en dat schijnen de oneindige-compressie-gelovigen hier niet in te zien.

Als je de "positie" van een symbool toevoegt als informatiedrager van een figuur. En elk symbool kan op één van vier posities in een figuur gezet worden, dan is de informatie die eruit te halen is toch ook 4x zo veel? (ik kan het mis hebben, want ik ben immers geen expert)

Wat dit met oneindige-compressie te maken heeft weet ik zo snel niet.

[0rbit]

MrWilliams schreef op woensdag 29 november 2006 @ 11:10:
[...]


Als je de "positie" van een symbool toevoegt als informatiedrager van een figuur. En elk symbool kan op één van vier posities in een figuur gezet worden, dan is de informatie die eruit te halen is toch ook 4x zo veel? (ik kan het mis hebben, want ik ben immers geen expert)

Tja, jij denkt dat je niet in bits moet denken, maar ik denk dat je dat wel moet doen, omdat het veel verwarring voorkomt. Juist het toevoegen van onnodige dingen in je representatie geven je de indruk dat je meer informatie opslaat dan voorheen; dat doe je ook, maar niet meer dan het equivalent in bits. Dat is niet mogelijk. Ook de positie van de symbolen voegt geen extra informatie toe; sterker nog; ze is de informatie.

Stel ik neem een figuur 0100. Deze figuur bestaat uit 4 symbolen. Hoe kan de positie van de symbolen nu meer informatie beschrijven anders dan dat ik andere combinaties beschrijf? Met deze vier symbolen en hun onderlinge positie kan ik nog steeds maar 2^4 = 16 mogelijkheden beschrijven.

Of bedoel je dat de geometrische positie van belang is? Dan kom ik weer uit op elementen die met een bepaald maximaal oplossend vermogen geschreven en gelezen kunnen worden. De geometrische informatie van de symbolen onderling is niet groter dan de informatie van de elementen los, dat heb ik volgens mij toch wel duidelijk gemaakt in mijn voorbeeld met de letter 'A'.

Wat dit met oneindige-compressie te maken heeft weet ik zo snel niet.

Mensen hebben een intuitief gevoel bij informatie en de compressie ervan dat niet klopt. Als je maar lang genoeg goochelt en opnieuw representeert dan hou je steeds minder over en je kunt ten alle tijde het origineel terugberekenen, denkt men. Dat idee is onjuist en dat idee vat ik samen als 'oneindige-compressie'.

Je kunt van alles berekenen hoeveel informatie het daadwerkelijk beschrijft. Met een beetje rekenwerk kun je zelfs beschrijven wat de maximale informatie in een zo kort mogelijke representatie is. Korter dan dat is niet mogelijk zonder lossy te worden. Dit feit moet je onder ogen zien. Alle halfzachte pogingen om het tegendeel aan te tonen (met kleur, trits, quads etc.) zullen niet helpen. Alle hier getoonde voorbeelden zijn gelimiteerd door de door Shannon opgestelde wetten wat betreft informatie.

[bszz]

De bron die Tweakers heeft gebruikt heeft inmiddels een uitstekend artikel gepubliceerd waarin uitgelegd wordt dat dit verhaal onzin is, of zoals ze zelf zeggen, het gevolg van 'journalistieke onzorgvuldigheid'

Naast praktische bezwaren als de nauwkeurigheid van printer en scanner wordt een aantal fundamentele redenen genoemd waarom dit niet mogelijk is.

Zelf eens lopen rekenen: Als elke dot een byte (256 mogelijke waardes) zou kunnen vertegenwoordigen, vereist 2,7 GB/inch² sqr(2.700.000.000)=51962 dpi, of als je ook de achterkant zou bedrukken 25981 dpi

[MicroWhale]

Ik heb het nergens over compressie of het weglaten of erbij toveren van informatie. Ik zeg alleen dat gegeven je een "fysieke informatiegrootte" met iets anders dan een één of een nul kan vullen door andere fysieke eigenschappen te gaan gebruiken, zodat je meer informatie op dezelfde "fysieke informatiegrootte" kwijtkunt. Dit heeft niks met compressie te maken. Je stopt er informatie in en je haalt exact diezelfde informatie er weer uit. Je kunt alleen meer informatie op hetzelfde fysieke stukje kwijt waar je anders een 0 of 1 weg zou schrijven.

[Confusion]

MrWilliams schreef op woensdag 29 november 2006 @ 10:34:
Vertel me dan maar dat het volgende niet waar is:
[..]
3. De fysieke opslaggrootte van een bit is even groot als die van een kleur

Je praat hier zonder blikken of blozen over de fysieke opslaggrootte van een kleur?! I rest my case.

[0rbit]

MrWilliams schreef op woensdag 29 november 2006 @ 12:08:
Ik heb het nergens over compressie of het weglaten of erbij toveren van informatie. Ik zeg alleen dat gegeven je een "fysieke informatiegrootte" met iets anders dan een één of een nul kan vullen door andere fysieke eigenschappen te gaan gebruiken, zodat je meer informatie op dezelfde "fysieke informatiegrootte" kwijtkunt. Dit heeft niks met compressie te maken. Je stopt er informatie in en je haalt exact diezelfde informatie er weer uit. Je kunt alleen meer informatie op hetzelfde fysieke stukje kwijt waar je anders een 0 of 1 weg zou schrijven.

Wat je zegt klopt in principe. Als je het voor elkaar krijgt meer bits aan informatie (zij het in de vorm van fotonen, elektronen of weet ik wat) in een kleiner volume te schrijven en lezen, dan heb je een hogere informatiedichtheid bereikt.

Nu moeten we er even de beweringen van die Indiase student bijhalen. Hij zegt dat hij betaalbare apparaten heeft die zo nauwkeurig kunnen scannen dat hij op een A4 256GB kwijt kan. Dit betekent dat hij 1) Deze hoeveelheid informatie kan opslaan of 2) Dat hij uitgaat van een gemiddelde informatiebron die redundant is en dus gecomprimeerd kan worden. Er kan dus feitelijk minder op een A4, maar door compressie is het equivalent aan 256GB.

Wat er beweerd wordt is dat hij door middel van het gebruik van figuren meer informatie kwijt kan dan de losse elementen waaruit die figuren bestaan. Dat is hetgeen ik onmogelijk acht en maakt dit verhaal in het geheel onwaarschijnlijk.

Het beschreven principe van printen en scannen kan. 256GB op een A4 kan mits je een hele goede printer hebt en een hele goede scanner. Ongeveer een factor 50 beter dan wat jij en ik kunnen kopen. Dit maakt het voor mij onaannemelijk dat zijn beweringen kloppen zeker als hij dan ook nog beweert dat hij dit soort apparatuur goedkoop kan maken en dat er al varianten voor in laptops zijn etc.

Daarnaast gaat dit topic (zie de topicstart) weldegelijk over de compressie kant van het verhaal...

[Pascal]

Confusion schreef op woensdag 29 november 2006 @ 12:37:
[...]

Je praat hier zonder blikken of blozen over de fysieke opslaggrootte van een kleur?! I rest my case.

Ik denk dat hij bedoeld, 1 dot zwart of een dot kleur op een stuk papier blijft toch gewoon 1 dot.? Dus de grote blijft hetzelfde, of heb ik het verkeerd?

[GH45T]

Evilman schreef op woensdag 29 november 2006 @ 12:49:
[...]


Ik denk dat hij bedoeld, 1 dot zwart of een dot kleur op een stuk papier blijft toch gewoon 1 dot.? Dus de grote blijft hetzelfde, of heb ik het verkeerd?

Dan is het toch feitelijk niet meer digitaal maar analoog

[MicroWhale]

Confusion schreef op woensdag 29 november 2006 @ 12:37:
[...]

Je praat hier zonder blikken of blozen over de fysieke opslaggrootte van een kleur?! I rest my case.

wat is daar mis mee?

[0rbit]

MrWilliams schreef op woensdag 29 november 2006 @ 15:08:
[...]


wat is daar mis mee?

Kleur is een eigenschap van electromagnetische straling. Kleur bestaat eigenlijk alleen in je hoofd; de golflengte van de EM-straling bepaalt de kleur die jij er in je hoofd van maakt. Kleur bestaat strict fysisch gesproken dus niet buiten een (continue) golflengte en je kunt dus ook niet spreken van het opslaan van een kleur.

Je slaat zelfs de golflengte in de praktijk niet op, omdat een apparaat maken wat de intentsiteit van EM-straling over een bepaald bereik nauwkeurig kan meten vrij duur is om te maken. Daarom bouw je het spectrum op uit een aantal basis componenten (rood, groen en blauw is de bekendste combinatie).

Wat je daadwerkelijk opslaat is dus een drietal getallen (voor RGB) op een bepaalde schaal die je middels een kleurcalibratie aan een golflengte hebt gelinked.

[MicroWhale]

Mr_Atheist schreef op woensdag 29 november 2006 @ 15:24:
[...]
[verhaal]

Nu begin je weer over bits. Op papier (waar die indiase jongen het over heeft) wordt een kleur wel degelijk opgeslagen in de vorm van een dot. (bijvoorbeeld een foto) Wellicht is er iets te maken wat kleur "opslaat" (lees: oneindig laat weerkaatsen) in een prisma. Het gaat erom dat je het als informatie-eenheid zou kunnen gebruiken, maar daar lees je elke keer overheen.

[0rbit]

MrWilliams schreef op woensdag 29 november 2006 @ 15:32:
[...]


Nu begin je weer over bits. Op papier (waar die indiase jongen het over heeft) wordt een kleur wel degelijk opgeslagen in de vorm van een dot. (bijvoorbeeld een foto) Wellicht is er iets te maken wat kleur "opslaat" (lees: oneindig laat weerkaatsen) in een prisma. Het gaat erom dat je het als informatie-eenheid zou kunnen gebruiken, maar daar lees je elke keer overheen.

Lees nou eens wat ik al tien keer in dit topic heb gezegd. Iedere informatie-eenheid hoe gek je hem ook wil definieren laat zich uitdrukken in bits. Dat jij daar niet aan wil en denkt dat informatie in een andere vorm ineens niet meer uit te drukken is in de standaardeenheid bits, dat is niet mijn probleem. Dacht jij dat je langer werd als ik je lengte ga meten in lineaaltjes in plaats van meters? Als je niet snapt dat dit voor informatie net zo geldig is, dan heeft verder discussieren geen zin meer.

Het oneindig weerkaatsen van licht in prismas.. *zucht* van elektrodynamica heb je dus ook geen kaas gegeten...

[Voutloos]

Tja, daar zit het idee van alle 'believers', informatie opslaan zonder dat je het opslaat. Gewoon met representaties husselen of net zo lang romantiseren tot je in Jan Sloot-achtige theorien gaat geloven.

Ja, als je per element meer waarden hebt, heb je minder elementen nodig om dezelfde hoeveelheid data op te slaan. Nee, je kan dan alsnog niet het Pigeon Hole Principle negeren. Ja, soms kan je entiteiten efficient labelen (bv. elke bestaande film een nummer geven). Nee, daarmee heb je nog niet de entiteit zelf opgeslagen.

[MicroWhale]

Mr_Atheist schreef op woensdag 29 november 2006 @ 15:46:
[...]


Lees nou eens wat ik al tien keer in dit topic heb gezegd. Iedere informatie-eenheid hoe gek je hem ook wil definieren laat zich uitdrukken in bits. Dat jij daar niet aan wil en denkt dat informatie in een andere vorm ineens niet meer uit te drukken is in de standaardeenheid bits, dat is niet mijn probleem. Dacht jij dat je langer werd als ik je lengte ga meten in lineaaltjes in plaats van meters? Als je niet snapt dat dit voor informatie net zo geldig is, dan heeft verder discussieren geen zin meer.

Het oneindig weerkaatsen van licht in prismas.. *zucht* van elektrodynamica heb je dus ook geen kaas gegeten...

Nogmaals mijn punt: Net zoals alle informatie-eenheden in bits uit te drukken zijn, zijn ze in kleuren uit te drukken. Bij een gelijke informatie opslag-grootte is het wel degelijk interessant om hiernaar te kijken.

Ik snap heel goed wat jij zegt, het lijkt erop dat dat andersom niet zo het geval is. Het (analoge) fototoestel was in jouw wereld nooit uitgevonden, omdat je eerst iets uit moest vinden om kleuren in bits op te slaan op een medium.

[Janoz]

Natuurlijk kun je informatie in kleuren uit drukken, maar dan heb je geen compressie. Je hebt nog steeds dezelfde hoeveelheid informatie als daarvoor.

[MicroWhale]

Janoz schreef op woensdag 29 november 2006 @ 16:12:
Natuurlijk kun je informatie in kleuren uit drukken, maar dan heb je geen compressie. Je hebt nog steeds dezelfde hoeveelheid informatie als daarvoor.

dat zeg ik zelf ook. Maar bij een gelijke fysieke informatie-eenheid-grootte, kun je wel meer informatie op hetzelfde fysieke plekje opslaan.

En dat is mijn hele onontkenbare punt.

[Verwijderd]

MrWilliams schreef op woensdag 29 november 2006 @ 16:23:
[...]


dat zeg ik zelf ook. Maar bij een gelijke fysieke informatie-eenheid-grootte, kun je wel meer informatie op hetzelfde fysieke plekje opslaan.

En dat is mijn hele onontkenbare punt.

Inderdaad, als een blok van 2x2 zwart/wit twee mogelijkheden vertegenwoordigd dan vertegenwoordigen 4 blokken van 1x1 zwart/wit in een vlak van 2x2 zestien mogelijkheden. In drie kleuren worden dat 91 mogelijkheden. Dat heeft echter niets met compressie te maken.

Daarnaast is aangetoond dat met de huidige printers en scanners de beloofde opslag niet gehaald kan worden. Het enige dat meneer dan wellicht toegekend kan worden is de prijs voor printer en scanner met het hoogste oplossend vermogen.

[ Voor 17% gewijzigd door Verwijderd op 29-11-2006 16:27 ]

[Harrie]

Janoz schreef op woensdag 29 november 2006 @ 16:12:
Natuurlijk kun je informatie in kleuren uit drukken, maar dan heb je geen compressie. Je hebt nog steeds dezelfde hoeveelheid informatie als daarvoor.

De essentie van (lossless) compressie is toch juist het opslaan van dezelfde hoeveelheid informatie met minder tekens / symbolen?
Dus voor en na compressie is de hoeveelheid informatie hetzelfde.

[ Voor 7% gewijzigd door Harrie op 29-11-2006 16:28 ]

[Verwijderd]

Harrie schreef op woensdag 29 november 2006 @ 16:26:
[...]


De essentie van (lossless) compressie is toch juist het opslaan van dezelfde hoeveelheid informatie met minder tekens / symbolen?
Dus voor en na compressie is de hoeveelheid informatie hetzelfde.

Ja, maar de mate van compressie hangt toch af van de mate van complexiteit van de boodschap? Een bestand van 1200 megabyte met enkel de letter a erin kan enorm gecomprimeerd worden, echter, de hoeveelheid informatie was vantevoren ook al niet groot. (volgens mij in ieder geval)

[Harrie]

Verwijderd schreef op woensdag 29 november 2006 @ 16:32:
[...]


Ja, maar de mate van compressie hangt toch af van de mate van complexiteit van de boodschap? Een bestand van 1200 megabyte met enkel de letter a erin kan enorm gecomprimeerd worden, echter, de hoeveelheid informatie was vantevoren ook al niet groot. (volgens mij in ieder geval)

Inderdaad. Dat is toch precies wat ik zeg? De informatie in het 1200MB bestand wat je noemt is evengroot als de hoeveelheid informatie in het bestand na comprimeren. De compressie zorgt alleen voor een andere representatie van deze informatie met een hogere informatiedichtheid.

onzinnig: Een 256GB file met alleen maar a's kan je dus zeer waarschijnlijk wel op een A4 op slaan

Mr_Atheist schreef op woensdag 29 november 2006 @ 12:47:
[...]
Wat er beweerd wordt is dat hij door middel van het gebruik van figuren meer informatie kwijt kan dan de losse elementen waaruit die figuren bestaan. Dat is hetgeen ik onmogelijk acht en maakt dit verhaal in het geheel onwaarschijnlijk.

Wat betreft deze claim (waar de hele theorie van de Indiaanse student om lijkt te draaien) moet ik me aansluiten bij Mr_Atheist. Juist doordat er door het gebruik van symbolen extra correlatie tussen de losse elementen zit, is de informatiedichtheid mijns insziens juist lager.

[ Voor 35% gewijzigd door Harrie op 29-11-2006 17:03 ]

[eamelink]

Dat is niet zo moeilijk nee, print gewoon de string "Een 256 GB file vol met a's" uit op je papier en je hebt precies dezelfde hoeveelheid informatie als werkelijk in die file staat

En bestand gevuld met een lange rij van hetzelfde karakter heeft nu eenmaal een zeer lage entropie en kan dus makkelijk gecomprimeerd worden

[0rbit]

MrWilliams schreef op woensdag 29 november 2006 @ 16:08:
[...]
Het (analoge) fototoestel was in jouw wereld nooit uitgevonden, omdat je eerst iets uit moest vinden om kleuren in bits op te slaan op een medium.

Je legt me nu woorden in de mond.

Het gaat in dit geval over informatie en representatie en niet over informatiedichtheid. Jij wil hoe dan ook met kleurtjes denken; ik denk als het om informatie gaat graag in de standaardeenheid "bit". Dan kun je gemakkelijk vergelijken en over compressie nadenken. Dat wil dus NIET zeggen dat je overal bits van MOET maken in de fysische realisatie van een opslagtechniek.

Zeggen dat in "mijn" wereld de analoge camera niet zou bestaan vind ik dan ook gewoon stompzinnig en getuigen van gebrek aan kennis over de beginselen der informatietheorie. Maar goed, ga je gang, denk lekker verder in kleurtjes...

[maikel]

GH45T schreef op woensdag 29 november 2006 @ 10:22:
Wat ik duidelijk probeer te maken is dat als je zowel 2, 4 als 8 op wilt slaan en zowel rood, blauw als paars je dan 2X4 op kunt slaan. 8 en paars zijn dan procesresultaten hiervan. De caracters die je wel opslaat doe je doormiddel van een uniforme methode zoals ASCII en je werkt bijvoorbeeld met een 16 kleuren pallet.

En wat dan als ik 2, 4, 9, rood, blauw en groen op wil slaan?

[Confusion]

MrWilliams schreef op woensdag 29 november 2006 @ 16:23:
Maar bij een gelijke fysieke informatie-eenheid-grootte, kun je wel meer informatie op hetzelfde fysieke plekje opslaan.

En dat is mijn hele onontkenbare punt.

En een totaal zinloos punt, want de fysieke informatie-eenheids-grootte is niet gelijk. Je kan een gekleurde pixel niet net zo klein maken als de magnetische eilandjes die een bit representeren in een harde schijf. Je kan ze uberhaupt niet erg klein maken, want op een gegeven moment hebben ze geen goed definieerbare kleur meer. Je kan met een voldoende kleine, gevoelige, fotospectrometer best de kleur van iets van 0.1x0.1 mm meten, met een golflengte nauwkeurigheid van pakweg 1 nm, in het bereik van 100-900 nm. Gefeliciteerd, je kan nu 800 waarden coderen op 0.1 mm². Dat doet een harde schijf beter.

[MSalters]

Henk007 schreef op woensdag 29 november 2006 @ 00:39:
Zoals zo vaak bij dit soort claims wordt er weer volop gespeculeerd, zowel in de FP reakties, als in dit topic. Zelf ben ik razend nieuwsgierig naar de originele publicatie van die kerel. Die is echter nergens te vinden, tenminste niet door mij. In geen enkel nieuwsbericht wordt vermeld in welk wetenschappelijk tijdschrift zal worden gepubliceerd. Nogmaals, zonder de harde feiten is een inhoudelijke discussie zinloos.

Weinig speculatie over nodig. Als je 1000 duiven hebt, en 999 duiventillen, dan kun je niet elke duif een eigen til geven. Iedereen snapt dat je dan geen discussie nodig hebt over het duivenras, en of het prijswinnende duiven zijn, en of het wel allemaal mannetjes zijn. Nee, je hebt duidelijk een duif te veel of een til te weinig.

Met informatie werkt het hetzelfde. 1000 bitten informatie, 999 bitten opslag - dat past niet.

[0rbit]

Maar een duif heeft ook een kleur toch?

Dit zaakje stinkt aan alle kanten. Als je echt zoiets uitvindt dan patenteer je dat voor je gaat publiceren. En zelfs publiceren heeft die student niet echt gedaan; er is nergens een paper te vinden waarin hij zijn geclaimde systeem beschrijft. Hij heeft een presentatie gegeven en die is waarschijnlijk via grote omwegen misvertaald.

Zonder harde feiten is een inhoudelijke discussie echter niet zinloos. We hebben al genoeg harde feiten over informatietheorie en soortgelijke systemen voor opslag en compressie. Deze student het voordeel van de twijfel geven is volgens mij in dit geval niet wetenschappelijk.

[link0007]

Dit is sowieso een domme manier van opslag: een blu-ray / HD-DVD schijf levert je 25GB per laag, met de mogelijkheid voor meerdere lagen, en betere bescherming. Maak een HD-DVD in de vorm van een A4-tje, bouw een A4-DVD speler, en je kan flink wat bits kwijt:

een CD heeft een diameter van 12cm.
het "onschrijfbare" gedeelte is 4,5cm.
de totale opp is 12PI= 38
het totale schrijfbare oppervlak is 12PI - 4.5PI = 24 cm2
dus 25/24 = 1,0 cm2 per GB
een A4 is 21 * 30 = 6,3*10^2 cm2
dat is dus ook 6,3*10^2 GB... dus waarom zouden we dan nog kleurtjes moeten gebruiken? een A4-DVD kan je nog als spiegel gebruiken ook

[MicroWhale]

Confusion schreef op woensdag 29 november 2006 @ 17:14:
[...]

En een totaal zinloos punt, want de fysieke informatie-eenheids-grootte is niet gelijk. Je kan een gekleurde pixel niet net zo klein maken als de magnetische eilandjes die een bit representeren in een harde schijf. Je kan ze uberhaupt niet erg klein maken, want op een gegeven moment hebben ze geen goed definieerbare kleur meer. Je kan met een voldoende kleine, gevoelige, fotospectrometer best de kleur van iets van 0.1x0.1 mm meten, met een golflengte nauwkeurigheid van pakweg 1 nm, in het bereik van 100-900 nm. Gefeliciteerd, je kan nu 800 waarden coderen op 0.1 mm². Dat doet een harde schijf beter.

Zo is dat op dit moment ja, maar dat wil niet zeggen dat daar nooit verandering in kan komen.

Het is trouwens ook niet beperkt tot kleur. Je kunt ook andere dingen gebruiken: warmte, koude, een molecuul met 8 elektronen waarvan je de draairichting kan veranderen, dna, nanotube, een enorm stabiele spanningsregelaar en apparatuur die tussen de elektronische 0 en 1 nog 6 andere waarden kan onderscheiden. Verzin het maar.

Het enige wat ik doe is filosoferen over de eventuele mogelijkheden en daarbij sluit ik niks uit.

Btw dat die indiër een kul-idee had bedacht dat wist ik ook wel, maar het laat niet onverlet om eens na te denken over of en hoe het misschien op een andere manier beter zou kunnen.

Als die dingen toch vrijwel altijd per 8 uitgelezen worden, waarom verzin je er dan geen fysieke drager voor?

[Confusion]

MrWilliams schreef op donderdag 30 november 2006 @ 08:26:
Het is trouwens ook niet beperkt tot kleur. Je kunt ook andere dingen gebruiken: warmte, koude, een molecuul met 8 elektronen waarvan je de draairichting kan veranderen, dna, nanotube, een enorm stabiele spanningsregelaar en apparatuur die tussen de elektronische 0 en 1 nog 6 andere waarden kan onderscheiden. Verzin het maar.

Er is geld zat in te verdienen en in de industrie hebben ze elk idee dat jij hier kan verzinnen wel een keer gehad, om het af te wijzen op praktische (lees: economische) gronden. Nou kunnen ze daar ongelijk in gehad hebben en nou zou daar door technologische vooruitgang verandering in kunnen komen, maar dat neemt niet weg dat hier een beetje mogelijkheden bedenken zinloos is. Als je zo'n mogelijkheid technisch uitwerkt, dan heb je wat.

Het enige wat ik doe is filosoferen over de eventuele mogelijkheden en daarbij sluit ik niks uit.

Sometimes a practical impossibility is more important than a theoretical possibility. -- Daniel C. Dennett.

Als die dingen toch vrijwel altijd per 8 uitgelezen worden, waarom verzin je er dan geen fysieke drager voor?

Ze worden gewoonlijk per veel meer dan 8 uitgelezen. Welk voordeel biedt een 'fysieke drager' volgens jou? Dat je informatie can coderen in de ordening van die dragers? Biedt dat dan voordeel?

Overigens wordt er op universiteiten onderzoek gedaan naar de mogelijkheid om zowel de lading als de spin van electronen als informatiedrager te gebruiken, waardoor je 4 states per transistor, oftewel 2 bits per transistor, hebt. Waarom nog steeds transistoren? Omdat je die reproduceerbaar in goed gedefineerde, 100% betrouwbaar onderscheidbare toestanden kan brengen. Dat lukt met andere dingen die net zo klein zijn bijzonder moeilijk. Daarom gebruiken we magnetische eilandjes, niet omdat de industrie vastgeroest zit op een of ander denkbeeld.

Als jij hier begint met teksten als 'er wordt teveel in bits gedacht', dan moet je het niet vreemd vinden dat je voor crackpot wordt versleten. Als jij kleuren gebruikt, codeer je nog steeds voor een bepaalde hoeveelheid informatie, uit te drukken in de eenheid bits.

[ Voor 6% gewijzigd door Confusion op 30-11-2006 08:48 ]

[MicroWhale]

Confusion schreef op donderdag 30 november 2006 @ 08:45:
[...]

Er is geld zat in te verdienen en in de industrie hebben ze elk idee dat jij hier kan verzinnen wel een keer gehad, om het af te wijzen op praktische (lees: economische) gronden. Nou kunnen ze daar ongelijk in gehad hebben en nou zou daar door technologische vooruitgang verandering in kunnen komen, maar dat neemt niet weg dat hier een beetje mogelijkheden bedenken zinloos is. Als je zo'n mogelijkheid technisch uitwerkt, dan heb je wat.
[...]
Sometimes a practical impossibility is more important than a theoretical possibility. -- Daniel C. Dennett.

[...]
[verhaal]

Mwah, de wetenschap is ook nog steeds bezig met de praktische onmogelijkheden van de relativiteitstheorie, maar ze boeken wel vooruitgang. Einstein zelf heeft hier 0 mogelijkheden technisch van uitgekwerkt, maar blijkbaar waren de mogelijkheden die hij had bedacht toch niet zo zinloos als ze aanvankelijk werden ontvangen.

Bovendien worden de meeste creatieve/innoverende oplossingen bedacht door mensen die aanschoppen tegen de gevestigde orde van een vakgebied (lees: de regels aan hun laars durven lappen). Simpelweg omdat ze verder kunnen kijken dan de mensen die, door beroepsdeformatie, niet verder kunnen kijken dan de horizon van hun eigen vakgebied.

[0rbit]

MrWilliams schreef op donderdag 30 november 2006 @ 09:22:
[...]

Bovendien worden de meeste creatieve/innoverende oplossingen bedacht door mensen die aanschoppen tegen de gevestigde orde van een vakgebied (lees: de regels aan hun laars durven lappen). Simpelweg omdat ze verder kunnen kijken dan de mensen die, door beroepsdeformatie, niet verder kunnen kijken dan de horizon van hun eigen vakgebied.

Ja, dat gebeurt wel eens ja. Maar je moet niet vergeten dat dat soort mensen het vakgebied zelf ook beheersen en van daaruit verder durven denken. Zoiets simpels als informatietheorie doen ze uit de losse pols...

Wel grappig dat je critici gelijk beschuldigt van beroepsdeformatie als ze wijzen op theoretische onmogelijkheden binnen de informatietheorie. Informatietheorie is puur wiskundig en heeft niks met opslagmethoden te maken. Daar heb je materiaalkunde, signaalbewerking en aanverwanten voor nodig. Pas bij het uitlezen van de informatie komt de informatietheorie weer om de hoek kijken bij zaken als signal to noise ratios, bit error rates en error correction. Ik kan ook wel fantaseren over mogelijkheden om informatie op te slaan.

Jij moet desnoods maar je eigen topic beginnen over opslagmethoden, want dit topic (lees de topic-start!) gaat over een claim van datacompressie om op een A4 256GB op te slaan door gekleurde figuren.

[Confusion]

MrWilliams schreef op donderdag 30 november 2006 @ 09:22:
Bovendien worden de meeste creatieve/innoverende oplossingen bedacht door mensen die aanschoppen tegen de gevestigde orde van een vakgebied

Flauwekul. De meeste creatieve/innoverende oplossingen worden gewoon door hard ploeterende promovendi en de R&D afdelingen van bedrijven bedacht.

Mwah, de wetenschap is ook nog steeds bezig met de praktische onmogelijkheden van de relativiteitstheorie, maar ze boeken wel vooruitgang. Einstein zelf heeft hier 0 mogelijkheden technisch van uitgekwerkt, maar blijkbaar waren de mogelijkheden die hij had bedacht toch niet zo zinloos als ze aanvankelijk werden ontvangen.

Waar in vredesnaam heb je het over? Dat sommigen in het begin dachten (en vele crackpots nog steeds trouwens) dat de relativiteitstheorie onmogelijk de werkelijkheid goed kon beschrijven, heeft niets van doen met 'praktische onmogelijkheden'. Alles dat de relativiteitstheorie voorspelt is juist gebleken. Daar is men achtergekomen door het uit te proberen, zoals men er ook door uitproberen achter is gekomen dat allerlei vormen van dataopslag niet werken. Je haalt 'denken dat een theorie de praktijk niet beschrijft' en 'in de praktijk vaststellen dat iets niet werkt' door de war.

Waarom in vredesnaam vinden mensen het de hele tijd, vooral in dit soort threads, nodig om 'de wetenschap' voor naief, kortzichtig, onwillig, dom en meer van zulks te verslijten? Het toont alleen maar aan dat ze niet weten hoe de wetenschappelijke praktijk werkt.

[ Voor 62% gewijzigd door Confusion op 30-11-2006 10:23 ]

[MicroWhale]

inderdaad, alles wat in het begin theoretisch wel mogelijk leek, maar tegen 'praktische onmogelijkheden' op liep, wordt langzaam door uitproberen/uitvinden bewezen. Daar heb ik het over, en dat was als repliek op de quote van Mr_Atheist.

Als je je beschuldigd voelt van beroepsdeformatie, dan heb je blijkbaar mijn en je eigen tekst niet goed gelezen. Tenzij je je bezighoudt met het onderzoeken van fysieke opslagmogelijkheden.

Kritiek is goed hoor, maar het blijkt dat we het over twee compleet verschillende onderwerpen hebben. En dat is al een aantal posts zo bezig. Ik zou inderdaad een topic moeten openen over manieren van opslag. Als de reacties hier een voorbode zijn van wat ik daar kan verwachten, kan ik dat beter niet doen.

[Delerium]

Confusion schreef op donderdag 30 november 2006 @ 08:45:
Als jij kleuren gebruikt, codeer je nog steeds voor een bepaalde hoeveelheid informatie, uit te drukken in de eenheid bits.

Dat klopt, maar voor opslag zouden kleuren toch nog steeds kunnen voldoen? Met een 16-kleurenpalet is iedere dot 4 bits. De winst is IMHO dan dat je ipv 4 dots slechts 1 dot nodig hebt. En indien je meer kleuren neemt (moeilijker onderscheiden, dat wel) kan je zelfs 8 bits of zelfs 24 bits wegschrijven op 1 dot (bij 24 bits is je foutcorrectie belangrijker dan de info zelf).

Ergens zou het mij wel handig lijken, je essentiele data kunnen wegschrijven door het uit te printen. Ook al is het 100 Mb per A4, dan praat je nog over vele gigabytes in handzaam boekformaat. Als je HD crashed kan je tenminste je data zo opnieuw inlezen. De winst is dat papier wel wat betrouwbaarder kan zijn als magnetisme (een HDD is na 10 jaar liggen onleesbaar) en ik vertrouw papier ook meer dan een CD'tje. Het nadeel is evident: het inlezen van data is gruwelijk langzaam, dus louter als backup bruikbaar. 256 Gb per bladzijde, daar geloof ik ook helemaal niets van.

* Delerium ziet opeens CIA-agenten met vakantiefo'to's opeens heel anders.

@Williams, die opmerking over zogenaamde recalcitrante mensen die meer resultaat boeken dan wetenschappers.... dit is een W&L-forum, je kan mensen zo gruwelijk beledigen met opmerkingen als deze.

[ Voor 7% gewijzigd door Delerium op 30-11-2006 11:01 ]

[wasco]

datacompressie zal het wel niet zijn nee, daar is iedereen het nu wel over eens.
maar wat de 'bitlovers' (zo noem ik ze maar even) toch wel uit te oog verliezen is dat volgens mij de indische man/jongen op zijn blad papier niet alle informatie gaat opzetten.
Hij zal er symbolen opzetten, in verschillende kleuren. stel je hebt een set van wel enkele honderden/duizenden verschillende symbolen, die elks in 256 of i-dont-care-hoeveel kleuren weergegeven kunnen worden,... zo kan je nog wel wat factoren verzinnen waarmee je hetzelfde symbool toch anders kan uitlezen en dus eigenlijk een ander symbool is.

wel als elk van die symbolen nu voor een bepaalde bitreeks staat, en je hebt op je computer de vertaalboek staan dat in combinatie met het scanprogramma de symbolen kan vertalen naar de bitreeksen, dan kan je mogelijk wél meer opslaan op een a4.

als ik sommige zie zeggen, stop in bits te denken, dat klopt dit ook. Ja je moet de gegevens uiteindelijk wel in bitvorm omzetten om ze bruikbaar te maken. Echter, jullie willen op dat blad papier niet alleen de gecodeerde data hebben staan, maar ook de vertaalboek. Want, zo redeneren jullie, als ik het blad papier inlees, dan moet ik dezelfde data terughebben.

Klopt, maar daar heb je dus het vertaalboek voor nodig. Nu ben ik er van overtuigd dat er weldegelijk een databank met bitreeksen moet kunnen opgebouwd worden die bruikbaar is om alles wat er maar mogelijk is op computer naar die symbolen te vertalen.

Ok, het blad papier is dan niet de echte drager van de informatie, het is slechts een landkaart die je nog moet interpreteren. Bekijk het als een heel geavanceerd geschrift.

Een voorbeeld uit de informatica waar dit ook gebeurt:
het microsoft .net framework: elk programma dat in .net geschreven is, bevat eigenlijk niet alle gegevens van dat programma. Zonder het framework ben je er niets mee. Je hebt context nodig om het te kunnen starten: die context is het .net framework.

Nu willen jullie 'bitneukers' op jullie blad papier alleen maar assemblercode zien, terwijl die indier op zijn blad papier .net code schrijft. Wat is kleiner?

[Dido]

wasco: je hebt kennelijk niet de moeite genomen de draad even door te lezen, want jouw woordenboek wordt al eerder met de grond gelijk gemaakt.

Opmerkingen als "bitneukers" en "bitlovers" duiden behalve op weinig respect voor anderen in deze draad ook op een afwezigheid van begrip van de betekenis van het woord bit. Ook die betekenis wordt in deze draad meermaals uitgelegd, trouwens.

[DieterVDW]

wasco schreef op donderdag 30 november 2006 @ 11:23:
datacompressie zal het wel niet zijn nee, daar is iedereen het nu wel over eens.
maar wat de 'bitlovers' (zo noem ik ze maar even) toch wel uit te oog verliezen is dat volgens mij de indische man/jongen op zijn blad papier niet alle informatie gaat opzetten.
Hij zal er symbolen opzetten, in verschillende kleuren. stel je hebt een set van wel enkele honderden/duizenden verschillende symbolen, die elks in 256 of i-dont-care-hoeveel kleuren weergegeven kunnen worden,... zo kan je nog wel wat factoren verzinnen waarmee je hetzelfde symbool toch anders kan uitlezen en dus eigenlijk een ander symbool is.

wel als elk van die symbolen nu voor een bepaalde bitreeks staat, en je hebt op je computer de vertaalboek staan dat in combinatie met het scanprogramma de symbolen kan vertalen naar de bitreeksen, dan kan je mogelijk wél meer opslaan op een a4.

als ik sommige zie zeggen, stop in bits te denken, dat klopt dit ook. Ja je moet de gegevens uiteindelijk wel in bitvorm omzetten om ze bruikbaar te maken. Echter, jullie willen op dat blad papier niet alleen de gecodeerde data hebben staan, maar ook de vertaalboek. Want, zo redeneren jullie, als ik het blad papier inlees, dan moet ik dezelfde data terughebben.

Klopt, maar daar heb je dus het vertaalboek voor nodig. Nu ben ik er van overtuigd dat er weldegelijk een databank met bitreeksen moet kunnen opgebouwd worden die bruikbaar is om alles wat er maar mogelijk is op computer naar die symbolen te vertalen.

Ok, het blad papier is dan niet de echte drager van de informatie, het is slechts een landkaart die je nog moet interpreteren. Bekijk het als een heel geavanceerd geschrift.

Een voorbeeld uit de informatica waar dit ook gebeurt:
het microsoft .net framework: elk programma dat in .net geschreven is, bevat eigenlijk niet alle gegevens van dat programma. Zonder het framework ben je er niets mee. Je hebt context nodig om het te kunnen starten: die context is het .net framework.

Nu willen jullie 'bitneukers' op jullie blad papier alleen maar assemblercode zien, terwijl die indier op zijn blad papier .net code schrijft. Wat is kleiner?

*zucht*
1. De symbolen print je op het papier dmv dots in bepaalde kleuren.
Je kan dus veel makkelijker redeneren over de hoeveelheid informatie die deze dots kunnen bevatten dan over de symbolen die je kunt vormen met deze dots.
Met die symbolen maak je alleen een ommeweg.

2. Je hebt een half punt met je databoek idee.
Het probleem is dat dat alleen werkt met gespecialiseerde toepassingen.
Data waarvan je weet dat bepaalde bitstrings bvb heel veel zullen voorkomen.
Dan kun je inderdaad zowel aan verzenderkant als aan ontvangerskant een soort data-woordenboek afspreken en aan de hand van dat woordenboek veelgebruikte bitstrings encoderen.

Als je echter ALLE mogelijke data wil encoderen, dan werkt dat niet meer.
Voor elk woordenboek dat efficiënt is voor bepaalde data, is er een andere set data te vinden waarvoor dat woordenboek totaal NIET efficiënt is.
Je kan dan nog gebruik maken van een woordenboek, maar dan moet je het wel doorsturen, want je kant geen vast woordenboek afspreken aan verzender- en ontvangerskant.
Dit is bvb wat er gebeurt bij huffman-codering.

[MicroWhale]

ecteinascidin schreef op donderdag 30 november 2006 @ 11:00:
[...]
@Williams, die opmerking over zogenaamde recalcitrante mensen die meer resultaat boeken dan wetenschappers.... dit is een W&L-forum, je kan mensen zo gruwelijk beledigen met opmerkingen als deze.

Ik bedoel niemand te beledigen en ik besef dat ik met mijn filosofische instelling soms wat boude uitspraken kan doen in ogen van andere mensen. Vooral hier.
Het zijn vrijwel altijd wetenschappers die ontdekkingen doen. En wel vaak wetenschappers die ver over de grenzen van hun eigen vakgebied kijken. Of wetenschappers die theorem uit verschillende vakgebieden durven combineren.

[DieterVDW]

MrWilliams schreef op donderdag 30 november 2006 @ 12:02:
[...]


Ik bedoel niemand te beledigen en ik besef dat ik met mijn filosofische instelling soms wat boude uitspraken kan doen in ogen van andere mensen.

Ik denk dat je hier ook enkele filosofen beledigt hoor.
Voor filosofen is redeneren aan de hand van de logica (= een wetenschap) en feiten een hoog goed.
Je hebt niet het recht om ongefundeerde uitspraken te doen over een onderwerp waar je weinig van kent, onder het mom van filosofie.
Een lekenkijk op een bepaald onderwerp kan wel interessante filosofische kwesties opleveren, maar kenners proberen verbeteren in hun eigen vakgebied, dat zie ik Socrates en consoorten toch niet doen hoor .

fi·lo·so·fie (de ~ (v.))
1 wetenschap die zich erop toelegt het wezen van alle dingen en de beginselen die aan het gehele zijn ten grondslag liggen, te leren kennen => wijsbegeerte

[wasco]

wasco: je hebt kennelijk niet de moeite genomen de draad even door te lezen, want jouw woordenboek wordt al eerder met de grond gelijk gemaakt.

Opmerkingen als "bitneukers" en "bitlovers" duiden behalve op weinig respect voor anderen in deze draad ook op een afwezigheid van begrip van de betekenis van het woord bit. Ook die betekenis wordt in deze draad meermaals uitgelegd, trouwens.

even reageren toch:
bitlovers is helemaal niet respectloos.
"bitneukers" staat binnenkort gewoon in de van daele:
=> Computerprogrammeurs met een voorkeur voor grote problemen; of in de context waar ik het gebruikte; programmeurs met de neiging om alles zelf te doen en naar de bouwstenen zelf te grijpen ipv verder te werken om grotere bouwblokken.

[link0007]

Maar wat is nou zo speciaal aan dat gekleurde papiertje? het levert effectief niet meer opslag dan een CD of HDD... Dat hij leuke tekeningen wil maken vind ik prima, maar zeggen dat dat "de toekomst" kan zijn gaat me een beetje ver (alhoewel dat wel een geheel nieuwe betekenis aan het woord "image" geeft )

[Verwijderd]

Na het lezen van wat reacts, zat ik het volgende te denken;
Stel je hebt een karakterset en je hebt x aantal kleuren dan zijn het aantal karakters maal de kleuren het aantal unieke karakters. Een programmeertaal heeft voor een actie een of meerdere (combinatie) codes, enz. Waarom zou je dan niet alle commando's/codes, en de meest voorkomende combinaties, vertalen naar een karakter met een specifieke kleur? Een convertor zorgt voor de vertaling van het karakter terug naar commando's/codes.

Misschien sla ik de plank mis maar hiermee kun je toch alle data in een 'foto' kwijt en in gecomprimeerde vorm?

Maar, misschien is de compressie factor wel te verwaarlozen door het 'beperkte' aantal commando's of code .......

[MicroWhale]

DieterVDW schreef op donderdag 30 november 2006 @ 13:24:
[...]
Ik denk dat je hier ook enkele filosofen beledigt hoor.
[verhaal]

gaat het om de exacte woorden of wat ik ermee wil zeggen?

vul voor "filosofische" maar "ruimdenkende"

dank voor de toelichting

[blobber]

wasco schreef op donderdag 30 november 2006 @ 14:41:
[...]
"bitneukers" staat binnenkort gewoon in de van daele:
=> Computerprogrammeurs met een voorkeur voor grote problemen; of in de context waar ik het gebruikte; programmeurs met de neiging om alles zelf te doen en naar de bouwstenen zelf te grijpen ipv verder te werken om grotere bouwblokken.

In de Van Dale staan ook scheldwoorden hoor, dit is alleen een omschrijving.Zou jij het leuk gevonden worden door een onbekend persoon een "bitneuker" genoemd te worden als je alleen maar serieus met je vak bezig bent?(Hoewel dit vragen in een tijd waarin men rustig ontkent dat Tyfushond een scheldwoord is...)

[ Voor 9% gewijzigd door blobber op 30-11-2006 20:04 ]