Ander bit stelsel?

[esvier]

Ik hoorde laast weer iemand praten over die man die een techniek had bedacht om alle dvd's van de wereld op 1 cd te zetten. Nu vond ik het wel grappig om zelf een compressie te bedenken.

nu dacht ik zo:
Maak een CD-rom waar je de tekens bijv. A t/m K op kwijt kan en die tekens geef je een waarde, die waarde kan de computer dan weer omzetten naar de normale BITS.


waarden voor de letters:

a = ***0
b = ***1
c = **10
d = **11
e = *001
f = *011
g = *111
h = 0001
i = 0011
j = 0111
k = 1111


bestand:
10011101101
wordt omgezet naar "bicdab" op de CD, volgens het tabel.

het is nu al van 11 tekens naar 6 tekens verkleint als je het vergelijkt hoe het op een CD staat.

Je zult zelfs die A t/m K kunnen vergroten om zo een nog grotere library te creeren, en waarschijnlijk daardoor een grotere compressie.

Maar zal dit werken?

[Zoefff]

Nee, tuurlijk werkt dit niet. Hoe wil je in godsnaam een letter op een cd/dvd zetten?

Je kan alleen maar 0 of 1 schrijven, aan of uit, gaatje of geen gaatje. Je kan dus niet zomaar 'bicdab' op een cd/dvd zetten, maar je zal die letters eerst om moeten zetten naar code's van 0 en 1, en dan ben je weer terug bij af

[ge-flopt]

Nee... Volgens jou tabel is *****1 B, maar een paar regels is diezelfde laatste 1 weer een E (*001). Verder is misschien het idee wel goed, maar moet er gewoon (flink) geschaafd worden. Je getallen stelsel klopt in ieder geval niet.

Mijn kennis van encryptie is niet zo echt denderend.

[ Voor 12% gewijzigd door ge-flopt op 14-09-2004 10:02 ]

[Rey Nemaattori]

Teneerste zul je bij a t/m g voor die sterretjes een 0 oid moeten invullen omdat anders de teken reeks niet even lang is en een machiene nooit zou kunnen weten of het om een of meerdere karakters gaat...

Daarnaast wil je niet aleen plain text op willen slaan op een cd' tje, ook andere tekens inclusief cijfers, en speciale tekens zoals ?,% en $ enz. zullen moeten worden opgeslagen, volgens mij heb je dan echt wel een volwaardige ascii tabel nodig....

Om nog maar te zwijgen van gecompileerde binaire code...

Je zou wel gaatjes op de dvd/cd kunnen maken met verschillende dieptes of groottes, waarbij ieder gaatje weer een andere bit-combinatie voorstelt, maar da's geen encryptie, dat gewoon een kwestie van meer opslag ruimte maken....

[ Voor 19% gewijzigd door Rey Nemaattori op 14-09-2004 10:10 ]

[SysRq]

esvier schreef op 14 september 2004 @ 09:59:
Maak een CD-rom waar je de tekens bijv. A t/m K op kwijt kan en die tekens geef je een waarde, die waarde kan de computer dan weer omzetten naar de normale BITS.

Zodra jij in plaats van een put (0) en geen putje (1) letters/andere tekens op een cd kan zetten veranderd er natuurlijk al heel veel. Één keer raden waarom dat nog niet in gebruik is?

waarden voor de letters:

a = ***0
b = ***1
c = **10
d = **11
e = *001
f = *011
g = *111
h = 0001
i = 0011
j = 0111
k = 1111

B is gelijk aan h?? Waarschijnlijk bedoel je dit:

code:

a = 0000
b = 0001
c = 0010
d = 0011
e = 0100
f  = 0101
g =  0111
enz..

Maar zal dit werken?

Nee dus.

[Maasluip]

Als ik 10011101101 volgens jou lookup tabel omzet en van boven begin met opzoeken dan is dat baabbbabbab.
Als ik van onder begin met opzoeken is het cjf*error* (10=c, 0111=j, 011=f, voor 01 is geen vertaling).

Ik zou zeggen: ga eens op zoek naar wat literatuur over compressiealgorithmen.

[Dido]

esvier schreef op 14 september 2004 @ 09:59:
a = ***0
b = ***1
c = **10
d = **11
e = *001
f = *011
g = *111
h = 0001
i = 0011
j = 0111
k = 1111

en eerste is de vraag hoe jij letters gaat branden op je cd.

verder, wat is het verschil tussen bbbb (1111?) en k(1111).
Hoe geef jij 1101 weer? Middels 'dab'? of 'bbab'? (Hint: met jouw a en b kun je heel mooi binair tellen, en je andere letters zijn nutteloos )

[Stamgastje]

esvier schreef op 14 september 2004 @ 09:59:
het is nu al van 11 tekens naar 6 tekens verkleint als je het vergelijkt hoe het op een CD staat.

En hoe ga je die 6 tekens wegschrijven op de disc? Standaard Ascii codes beslaan al 8 bits (=1 byte) per teken, dus je hebt alleen nog maar ruimte verloren.

[Confusion]

esvier schreef op 14 september 2004 @ 09:59:
Maak een CD-rom waar je de tekens bijv. A t/m K op kwijt kan en die tekens geef je een waarde, die waarde kan de computer dan weer omzetten naar de normale BITS.

Zoals diverse mensen hierboven al aangeven: je zal die tekens op een of andere manier moeten coderen op de CD-ROM. De meest effectieve manier (waarmee het meeste op de CD kan) is door daar putjes voor te gebruiken en wel/geen putje als 0/1 te laten tellen. Je kan wel complete figuurtjes in de CD gaan etsen, maar dat levert je veel minder informatie op. Een herkenbaar tekentje neemt veel meer ruimte in dan vier bits. Het putje als bitje is niet ontstaan omdat men 'vastgeroest zit' op het binaire stelsel: je kan zo gewoon de meeste informatie kwijt op een oppervlak.

[Commander Zulu]

De manier om het weg te schrijven is al uitgevonden:



De informatie (geluid in dit geval) wordt opgeslagen in de vorm van de spiraalvormige geul. De afwijking ten opzichte van het midden representeert de waarde die je wilt opslaan.

Dit is zelfs een betere uitvinding, omdat je meer dan 11 verschillende waarden per 'bit' kan opslaan, namelijk frequenties tussen 20 en 10.000 Hz (bij benadering).

Helaas is er wel een lage signaal-ruis-ratio, maar een slim foutcorrectie algoritme daar rekening mee houden.

[Rey Nemaattori]

Dido schreef op 14 september 2004 @ 10:10:
(Hint: met jouw a en b kun je heel mooi binair tellen, en je andere letters zijn nutteloos )

In dat geval stem ik dat we het gewoon houden bij het huidige stelsel

Commander_Zulu schreef op 14 september 2004 @ 10:23:
De manier om het weg te schrijven is al uitgevonden:

[afbeelding]

De informatie (geluid in dit geval) wordt opgeslagen in de vorm van de spiraalvormige geul. De afwijking ten opzichte van het midden representeert de waarde die je wilt opslaan.

Dit is zelfs een betere uitvinding, omdat je meer dan 11 verschillende waarden per 'bit' kan opslaan, namelijk frequenties tussen 20 en 10.000 Hz (bij benadering).

Helaas is er wel een lage signaal-ruis-ratio, maar een slim foutcorrectie algoritme daar rekening mee houden.

Aangezien je spriaal naar binnen spiraalt, nemen je waardes dan, onafhankelijk van je informatie, niet langzaam af of toe? Immers je spiraalt naar binnen of naar buiten, dus de afstand neemt hoe dan ook toe of af

[the_stickie]

Rey Nemaattori schreef op 14 september 2004 @ 10:49:
[...]


In dat geval stem ik dat we het gewoon houden bij het huidige stelsel


[...]


Aangezien je spriaal naar binnen spiraalt, nemen je waardes dan, onafhankelijk van je informatie, niet langzaam af of toe? Immers je spiraalt naar binnen of naar buiten, dus de afstand neemt hoe dan ook toe of af

ja! en een plaat gaat ook trager klinken aan de binnen kant!

daar kan je rekening mee houden als je het medium beschrijft!

[esvier]

Als ik 10011101101 volgens jou lookup tabel omzet en van boven begin met opzoeken dan is dat baabbbabbab.
Als ik van onder begin met opzoeken is het cjf*error* (10=c, 0111=j, 011=f, voor 01 is geen vertaling).

Ik zou zeggen: ga eens op zoek naar wat literatuur over compressiealgorithmen.

De computer moet er rekening mee houden dat je het zo klein mogelijk wilt opschrijven, dus je werkt van onder naar boven.

dus 10011101101 wordt

cjabcb

Hoe geef jij 1101 weer? Middels 'dab'? of 'bbab'?

middels "dab" de computer gaat er van uit dat je het zo kort mogelijk opschrijft.

En hoe ga je die 6 tekens wegschrijven op de disc?

Met een gewone CD weet ik het niet, maar door gebruik temaken van diepte, lengte kun je al een heel eind komen.

ik zat zelf ook nog te denken om de puntjes op een cd onder een hoek te branden als je dan 11 sensoren hebt kun je dat ook weer koppelen aan het tabel.

lazer straal schijnt op de cd en wordt onder een bepaalde hoek weer weerkaast
en wordt dan opgevangen door 1 van de 11 sensoren.

[Gomez12]

Dan praat je niet meer over een ander bit stelsel, maar gewoon over een andere opslag techniek.

[Zoefff]

esvier schreef op 14 september 2004 @ 10:58:
[...]


De computer moet er rekening mee houden dat je het zo klein mogelijk wilt opschrijven, dus je werkt van onder naar boven.

dus 10011101101 wordt

cjabcb

Als ik van onder naar boven werk, zoals je zegt, dan vind ik de letters 10, 0111, 011, 1, 0 oftewel cjfba, en niet cjabcb.

Je hebt theoretisch wel gelijk dat als je meerdere tekens gebruikt (dus bijvoorbeeld a t/m k ipv 0 en 1) dat je dan op een efficientere manier data kan op slaan. Het enige probleem is dat je die andere tekens dus niet op kan slaan.

Wat je als "oplossing" geeft, is dat je die tekens dan 3D wilt gaan opslaan in een schijfje, maar het resultaat is dat je die tekens alsnog weer gaat opslaan in de vorm van 0 en 1. Dan kan je dus net zo goed normale data 3D opslaan, dan bereik je hetzelfde, en scheelt het ook nog eens een keer coderen/decoderen. Het blijft namelijk een feit dat processoren alleen kunnen rekenen met 0 en 1, dus het zal altijd eerst vertaald moeten worden.

[ Voor 49% gewijzigd door Zoefff op 14-09-2004 11:11 ]

[Verwijderd]

Wat de TS wil is in principe het tegenovergestelde van prefix-codes met variabele lengte. In bestaande compressiealgoritmes worden deze prefix-codes veel gebruikt; bv. Huffman codes of Shannon-Fano codes. Maw. het omgekeerde is al zo'n 50 jaar geleden bedacht, waarbij Huffman kon bewijzen dat zijn codes optimaal comprimeren.

Maw. dit ideetje is anti-compressie oftwel een decompressie- of "uitpak-" algoritme; het comprimeren moet exact andersom werken.

[Verwijderd]

De uitvinding waar oorspronkelijk aan gerefereerd werd kon een videofilm van pak-um-beet 5 Gb opslaan in 1 Kb aan getallen. Een snel algoritme kon deze sleutel weer herleiden naar het oorspronkelijke bestand. Let wel: de uitvinder zelf gaf aan dat het niet met compressie werkte.

Wat volgens mij een wezenlijke verbetering zou zijn is de uitvinding van een reversibel hash algoritme. Hashes berekenen aan de hand van de waarde en positie van bytes in een bestand een sleutel van vaste lengte, bijv bij MD5 512 bits. Het algoritme is zo opgebouwd dat een wijziging (hoe klein ook) in het oorspronkelijke bestand een totaal andere message digest oplevert. Vanuit die optiek kun je de message digest zien als de handtekening van een bestand. De mogelijkheid dat een ander bestand dezelfde digest oplevert is zeer klein.

Het grappige aan een hash is dat het maar één kant op werkt; je kunt niet de message digest aan het omgekeerde algoritme voeren en dan weer bij het oorspronkelijke bestand uitkomen. Dit is (als het waar is) de uitvinder wél gelukt, vanuit een abstracte en zeer beperkte sleutel kon hij weer bij het oorspronkelijke bestand uitkomen.

[Iblies]

Eigenlijk is het systeem met bitjes hopeloos verouderd,
het dateerd uit het jaar blok -> al sinds er een schakelaar is in principe. Aan en uit, spanning en spanningloos, 1 en 0 .
De meest nieuwe Intel of AMD werkt op hetzelfde principe, al is het dan gecomprimeerd tot 130/90 nm per schakelaar.

Als je nu diepte gaat creeeren, dan krijg je meer mogelijkheden, daar moeten we naar kijken. Een nieuwe chip is al in ontwikkeling, er waren een paar berichten op de frontpage, ga zometeen even zoeken.
Dan heb je het probleem met de opslag, dat is nog steeds plat, oftewel geen diepte, en ik zie niet een twee drie hoe ze dat gaan oplossen. Wil je namelijk het gaan uitbreiden,
dan moet je,
1 diepte creeeren
2 werken met verschillende tinten -> rood groen blauw, zwart grijs wit, maar dan heb je wel heel secuur apparatuur nodig.

Feit is dat het huidige systeem het makkelijkst is, wat betreft opslag omdat apparatuur voor een ander systeem simpelweg niet bestaat om tot dezelfde prestaties te komen.

[Gomez12]

Verwijderd schreef op 16 september 2004 @ 11:36:

Wat volgens mij een wezenlijke verbetering zou zijn is de uitvinding van een reversibel hash algoritme. Hashes berekenen aan de hand van de waarde en positie van bytes in een bestand een sleutel van vaste lengte, bijv bij MD5 512 bits. Het algoritme is zo opgebouwd dat een wijziging (hoe klein ook) in het oorspronkelijke bestand een totaal andere message digest oplevert. Vanuit die optiek kun je de message digest zien als de handtekening van een bestand. De mogelijkheid dat een ander bestand dezelfde digest oplevert is zeer klein.

De kans dat een ander "aanwezig" bestand dezelfde digest oplevert is klein maar wel degelijk aanwezig. De kans dat er een bestand ergens bestaat wat exact dezelfde digest oplevert is (schatting van mezelf) 99%.

Als je systeem met een hashing systeem werkt, dan heb je ook niet perse het wachtwoord van een gebruiker nodig, een ander wachtwoord met dezelfde hash voldoet ook ( let op, een film van 5Gb grootte kan dezelfde hash opleveren als jouw 8-letterige wachtwoord).

Daarom is een hash gewoon niet terug te rekenen, het kan aan meer waarden voldoen.

simpele voorstelling van hashen:
1+1 = 2
wachtwoord is hier twee keer een 1. Digest is 2. Ik kan niet met een 8 en een 9 inloggen. Maar niemand kan ook het wachtwoord terughalen uit het getal 2.

Het grappige aan een hash is dat het maar één kant op werkt; je kunt niet de message digest aan het omgekeerde algoritme voeren en dan weer bij het oorspronkelijke bestand uitkomen. Dit is (als het waar is) de uitvinder wél gelukt, vanuit een abstracte en zeer beperkte sleutel kon hij weer bij het oorspronkelijke bestand uitkomen.

Kan niet. Het feit dat een digest zo klein is komt doordat het niet terug te voeren hoeft te zijn.

[Voutloos]

Commander_Zulu schreef op 14 september 2004 @ 10:23:
De informatie (geluid in dit geval) wordt opgeslagen in de vorm van de spiraalvormige geul. De afwijking ten opzichte van het midden representeert de waarde die je wilt opslaan.

En daar gaat het fout. Bij een hdd/cd is een track heel smal aangezien er geen amplitude gebruikt wordt. En dus kan je meer tracks kwijt. Deze tracks worden allen volledig gebruikt, terwijl bij een plaat alleen maar de groef informatie bevat. Het randje van de groef is nog nodig, maar alles dat tussen 2 groeven zit en niet direct het randje vormt is zonde van de ruimte. (metafoor: de sloot is de info, de wal is nodig voor de vorm van de sloot, maar al die weilanden zijn overbodig)

[Zoijar]

Verwijderd schreef op 16 september 2004 @ 11:36:
Wat volgens mij een wezenlijke verbetering zou zijn is de uitvinding van een reversibel hash algoritme.

Dat kan per definitie niet, want een hash functie is geen injectieve functie en heeft dus geen inverse.

[frickY]

esvier schreef op 14 september 2004 @ 10:58:
Met een gewone CD weet ik het niet, maar door gebruik temaken van diepte, lengte kun je al een heel eind komen.

ik zat zelf ook nog te denken om de puntjes op een cd onder een hoek te branden als je dan 11 sensoren hebt kun je dat ook weer koppelen aan het tabel.

lazer straal schijnt op de cd en wordt onder een bepaalde hoek weer weerkaast
en wordt dan opgevangen door 1 van de 11 sensoren.

Hologramschijven bedoel je? Sorry je bent net te laat, die zijn er al.

Maar wat je dan doet is niet je data comprimeren, maar je opslag capaciteit vergroten. Zo kan ik het ook

[Dido]

Gomez12 schreef op 16 september 2004 @ 13:02:
De kans dat een ander "aanwezig" bestand dezelfde digest oplevert is klein maar wel degelijk aanwezig. De kans dat er een bestand ergens bestaat wat exact dezelfde digest oplevert is (schatting van mezelf) 99%.

Nog leuker, als je hash, zeg, 512bits is, en je hebt 2⁵¹²+1 bestanden, is de kans 100% dat minimaal twee van die bestanden dezelfde hash hebben

Verder lijkt de TS inderdaad eerder te doelen op vergroting van opslagcapaciteit dan op compressie of een ander "bitstelsel". (Een bitstelsel is per definitie base 2, en de manier waarop we met bits informatie opslaan is wel redelijk geoptimaliseerd ondertussen.)

[MSalters]

Helaas voor de TS worden dit soort systemen al een tijd gebruikt. Alle modems zijn 2400Hz ; om meer dan 1 bit per Hz erin te proppen gebruiken ze dat soort encoding schema's. Weliswaar niet met de letters a..k, maar met combinaties van amplitude en fase.

Zie bijv http://cnx.rice.edu/content/m11724/latest/

[ Voor 11% gewijzigd door MSalters op 16-09-2004 21:00 . Reden: plaatje ]

[Zoijar]

Dido schreef op 16 september 2004 @ 17:41:
Nog leuker, als je hash, zeg, 512bits is, en je hebt 2⁵¹²+1 bestanden, is de kans 100% dat minimaal twee van die bestanden dezelfde hash hebben

Ehmm nee, dat klopt van geen kant die uitspraak. De kans is wel erg groot, maar niet 1. Bovendien heb je met ongeveer 2^256 bestanden (wortel uit 2^512) al bij verwachting eenzelfde hash.

[GlowMouse]

Ehmm nee, dat klopt van geen kant die uitspraak. De kans is wel erg groot, maar niet 1.

Welles

Stel je hebt een 3-bits hash, mogelijkheden:
000
001
010
011
100
101
110
111

8 verschillende dus. Met 2³+1 bestanden móet je dus wel een keer dezelfde hash hebben. Kans van 1.

[RSpliet]

Hmm, die compressietechniek werkt dus om bovenstaande redenen waarschijnlijk niet. Je kan in de CD alleen 1tjes en 0-etjes neerzetten, en de ASCII specificatie bestaat gewoon uit 256 tekens, net als instructies voor wat dan ook.
Een cijfer kan bijvoorbeeld in een programma worden opgeslagen als 00110011 (da's dus 51). In de ASCII specificatie kom je dan op 3. Zou je ditzelfde getal moeten opslaan in die ASCII specificatie, dan krijg je de reeks 0011010100110001, dus het opslaan van getallen gaat al optimaal. Nadeel is dat het getal 255 (11111111) ook bestaat, en die dus ook moet kunnen worden opgeslagen op de een of andere manier. Er moeten dus sowieso 256 combinaties mogelijk zijn, dus zo kom je nergens.

Wil je een leuke compressietechniek hebben, dan moet je denken aan reeksen van bijvoorbeeld 9 bits ipv 8, die dan 2 veel gebruikte tekens achter elkaar representeren. Dus bijvoorbeeld ee word veel gebruikt, dan wijs je die de reeks 100000001 toe (let op, 7 nullen). Zo heb je een winst gemaakt van 7 bits, en als je het goed doet kan je dat redelijk uitbereiden. Met 9 bits heb je weliswaar maar 2x zoveel mogelijkheden (dus niet alle combinaties zijn mogelijk), maar op de meestgebruikte combinaties bespaar je zo wel wat . En waarom zou je dit niet uitbereiden tot 12 bits? Da's een kwestie van testen dus wat het meest optimaal werkt. En mocht er een ongebruikelijke reeks van 2 tekens komen, dan kan je altijd dmv 010101010 (bijvoorbeeld) aangeven dat het een enkel tekentje uit de ascii standaard is, met de code 10101010 (ik verzin maar wat dus he )

[ Voor 19% gewijzigd door RSpliet op 16-09-2004 21:22 ]

[Zoijar]

GlowMouse schreef op 16 september 2004 @ 21:06:
8 verschillende dus. Met 2³+1 bestanden móet je dus wel een keer dezelfde hash hebben. Kans van 1.

Iha zijn er meer bestanden met dezelfde hash. En aangezien je geen bestanden kan creeren die allemaal verschillende hashes opleveren, komt het er dus op neer dat "een bestand" gelijk staat aan "een willekeurige hash". Met een 3 bit hash en 8 bestanden is de kans klein dat ze allemaal verschillend zijn.

(verder heet wat jij beschrijft "het laatjes principe", en dat is geloof ik zelfs een axioma)

[ Voor 11% gewijzigd door Zoijar op 16-09-2004 21:23 ]

[MSalters]

Zoijar, je mist de "minimaal" in "minimaal twee bestanden". De kans dat er precies twee bestanden dezelfde hash hebben is kleiner dan 1.

[RayNbow]

Als vraag aan de TS, startte je dit topic naar aanleiding van de uitvinding van Jan Sloot?

Stukje tekst van http://www.gids.nl/techno/jan-sloot.html:

Het Sloot Digital Coding System (soes) zou de wereld opschudden: een nieuw alfabet voor digitale informatieopslag dat niet langer meer gebruikmaakt van het binaire stelsel van nulletjes en eentjes, maar een veel efficientere methode hanteert. Het principe werkte ogenschijnlijk simpel. Net zoals er voor een stuk tekst maar een beperkt aantal karakters beschikbaar is, wordt een film uit een eindig aantal kleuren en geluiden opgebouwd. Al die basisgegevens werden in vijf algoritmes in vijf verschillende geheugens opgeslagen. Bij de opslag van films zou ieder algoritme een maximale omvang van 74 megabyte krijgen. In totaal dus 370 megabyte: de motor van de vinding. Het enige wat nodig was om die te starten was een passende sleutel. Sloot berekende voor iedere bladzijde van een boek, of ieder beeld van een film, een unieke code waarvan het geheel ook weer resulteerde in een unieke code. Die laatste code, de sleutel, nam slechts één kilobyte geheugen in beslag, ongeacht de lengte van de film of de dikte van het boek. Op één simpele chipkaart konden op die manier tientallen sleutels worden opgeslagen. Iemand zou bijvoorbeeld, tegen betaling, met een gsm binnen enkele seconden de sleutels van een aantal films kunnen verkrijgen om die thuis via een afspeler met de basisalgoritmes te bekijken. Een technologie kortom, met een onvoorstelbaar potentieel voor creatieve destructie. Alle geluidsdragende industrieen - cd, dvd, tape, diskette - zouden niet lang meer bestaan. Bedrijven die miljarden investeren in glasvezelnetwerken evenmin. Het aloude koperdraadje zou plotseling weer goud waard zijn. Hetzelfde geldt voor gsm. En wat te denken van alle denkbare vormen van consumentenelektronica die beeld en geluid of andere informatie voortbrengen? Niets zou hetzelfde blijven. Het bedrijf met de licenties op SDCS zou, zo stelde Roel Pieper handenwrijvend vast, honderden miljarden dollars waard zijn.

[GlowMouse]

Wat overigens een leuke methode is, als het allemaal fijn genoeg te maken is, is om niet 2 verschillende (0 en 1) maar 256 verschillende trapjes te maken. Dan kun je 1 byte in slechts 1 'bit' opslaan en heb je 256x zoveel geheugen op hetzelfde oppervlakte.
In geheugen is dit niet haalbaar, omdat iets aan of uit staat, en tussenvormen erg moeilijk te maken zijn door lekstromen.

[Rey Nemaattori]

The_Stickie schreef op 14 september 2004 @ 10:56:
[...]

ja! en een plaat gaat ook trager klinken aan de binnen kant!

daar kan je rekening mee houden als je het medium beschrijft!

Langzamer schrijven naar mate je naar binnen komt? Denk je echt dat ut helpt? De afstand tot het midden neemt nogsteeds af, dus de waardes die je erop zet ook

[MSalters]

GlowMouse schreef op 16 september 2004 @ 21:47:
Wat overigens een leuke methode is, als het allemaal fijn genoeg te maken is, is om niet 2 verschillende (0 en 1) maar 256 verschillende trapjes te maken. Dan kun je 1 byte in slechts 1 'bit' opslaan en heb je 256x zoveel geheugen op hetzelfde oppervlakte.
In geheugen is dit niet haalbaar, omdat iets aan of uit staat, en tussenvormen erg moeilijk te maken zijn door lekstromen.

Niet haalbaar is een groot woord. Hitachi bijvoorbeeld maakt multi-level flash.

[Zoijar]

MSalters schreef op 16 september 2004 @ 21:33:
Zoijar, je mist de "minimaal" in "minimaal twee bestanden". De kans dat er precies twee bestanden dezelfde hash hebben is kleiner dan 1.

Ah ja, doh. Ik zat in m'n hoofd met een gegeven hash terug rekenen (daar ging het eerder om). Haalde even twee dingen door elkaar, excuus.

[Verwijderd]

Inderdaad zijn er paniekerige berichten over gevonden collisions in hash algoritme's (SHA). Zie http://www.mail-archive.c...etzdowd.com/msg02554.html voor een voorbeeld.

[Grijze Vos]

Zoijar schreef op 16 september 2004 @ 21:01:
[...]

Ehmm nee, dat klopt van geen kant die uitspraak. De kans is wel erg groot, maar niet 1. Bovendien heb je met ongeveer 2^256 bestanden (wortel uit 2^512) al bij verwachting eenzelfde hash.

Lol, als je 367 mensen hebt zijn er ook 2 mensen op dezelfde dag jarig hoor.

[Verwijderd]

Lol, als je 367 mensen hebt zijn er ook 2 mensen op dezelfde dag jarig hoor.

offtopic:
Als er meer dan 22 mensen bij elkaar zijn is de kans dat er 2 mensen op dezelfde dag jarig zijn groter dan dat dit niet het geval is......
Bij 367 mensen is die kans > 100%

[MSalters]

Verwijderd schreef op 17 september 2004 @ 14:20:
Als er meer dan 22 mensen bij elkaar zijn is de kans dat er 2 mensen op dezelfde dag jarig zijn groter dan dat dit niet het geval is......
Bij 367 mensen is die kans > 100%

> 100% zelfs? Dat is wel erg veel

[Yoozer]

Iblies schreef op 16 september 2004 @ 12:53:
Eigenlijk is het systeem met bitjes hopeloos verouderd,
het dateerd uit het jaar blok -> al sinds er een schakelaar is in principe. Aan en uit, spanning en spanningloos, 1 en 0.

Tja, het decimale talstelsel is ook al hopeloos verouderd, maar het werkt nog steeds erg goed. Sterker nog, de wiskunde maalt er niet om of er in binair of decimaal gerekend hoeft te worden; de axioma's veranderen niet, wel de notatie.

De meest nieuwe Intel of AMD werkt op hetzelfde principe, al is het dan gecomprimeerd tot 130/90 nm per schakelaar.

Tja, het formaat is kleiner gemaakt, en de schakelaars zijn sneller geworden (SOI).

Als je nu diepte gaat creeeren, dan krijg je meer mogelijkheden, daar moeten we naar kijken. Een nieuwe chip is al in ontwikkeling, er waren een paar berichten op de frontpage, ga zometeen even zoeken.

Maar diepte betekent alleen dat je de oppervlakte van de CPU vergroot. Ook zit je met het probleem dat je de constructie dan stukken moeilijker maakt; je hebt dan niet 1 laag waar je puur met een masker hoeft te werken, maar met meerdere maskers die allemaal maar een bepaald stuk mogen "wegbijten". Meerdere CPU's stapelen maakt de constructie in de hoogte een probleem. Het idee is niet revolutionair, maar het veroorzaakt vooralsnog meer problemen dan mogelijkheden. Je zult dan atoom voor atoom moeten bouwen om een dergelijke structuur ook nog "sterk" te maken. Een 4-layer "3D"-CPU is dan gewoon gelijk aan een 6-CPU computer (even grof geteld, om voor de onderlinge traagheid te compenseren zijn er een paar extra bij gezet).

Dan heb je het probleem met de opslag, dat is nog steeds plat, oftewel geen diepte, en ik zie niet een twee drie hoe ze dat gaan oplossen. Wil je namelijk het gaan uitbreiden,
dan moet je,
1 diepte creeeren
2 werken met verschillende tinten -> rood groen blauw, zwart grijs wit, maar dan heb je wel heel secuur apparatuur nodig.

Platte opslag werkt an sich goed. Voor DVD's bestaat al een gestapelde opslag - dat is gewoon dual layer. Maar er is meer winst te krijgen in het verkleinen van benodigde oppervlakte dan in het layers erbij smijten. Dat laatste geeft de eerste keer een winst van 50%, dan nog maar een winst van 33%, dan nog maar 25% en lager.

Feit is dat het huidige systeem het makkelijkst is, wat betreft opslag omdat apparatuur voor een ander systeem simpelweg niet bestaat om tot dezelfde prestaties te komen.

Makkelijkst en technisch haalbaarst. Mocht er meer behoefte zijn aan opslag, dan is het makkelijker en stukken goedkoper om een extra harddisk erbij te zetten dan een nieuwe te ontwikkelen .

[Grijze Vos]

Verwijderd schreef op 17 september 2004 @ 14:20:
[...]

offtopic:
Als er meer dan 22 mensen bij elkaar zijn is de kans dat er 2 mensen op dezelfde dag jarig zijn groter dan dat dit niet het geval is......
Bij 367 mensen is die kans > 100%

Waar heb jij wiskunde gekregen? Kansen schrijf je tussen 0 en 1, en 1 is de grootst mogelijke waarde.

[Verwijderd]

Grijze Vos schreef op 18 september 2004 @ 13:36:
[...]

Waar heb jij wiskunde gekregen? Kansen schrijf je tussen 0 en 1, en 1 is de grootst mogelijke waarde.

En 1 komt niet voor tussen 0 en 1

[Verwijderd]

Uhhhh... qua kansberekening ben ik een autodidact, maar voor de rest ben ik afgestudeerd aan de University of Liverpool (Information Technology).. ok?

[Verwijderd]

Grijze Vos schreef op 17 september 2004 @ 13:14:
Lol, als je 367 mensen hebt zijn er ook 2 mensen op dezelfde dag jarig hoor.

Inderdaad, en om hier even een wetenschappelijk tintje aan te geven: dat heet het pigeon hole principe.

RayNbow schreef op 16 september 2004 @ 21:44:
Sloot berekende voor iedere bladzijde van een boek, of ieder beeld van een film, een unieke code waarvan het geheel ook weer resulteerde in een unieke code. Die laatste code, de sleutel, nam slechts één kilobyte geheugen in beslag, ongeacht de lengte van de film of de dikte van het boek.

Dat betekent dus ook dat er maar 2¹⁰²⁴ "mediaitems" opgeslagen kunnen worden, en waarschijnlijk zelfs minder, voordat je een conflict krijgt tussen sleutels. Nou is 2¹⁰²⁴ op zich behoorlijk veel (), maar ik vind het maar een rare eigenschap van het algoritme.

Maar dat betekent dat dit in principe dus ook een hashing algoritme is, omdat het niet injectief is, zoals Zoijar opgemerkt heeft. Hmmm... interesting... (* krabt aan zijn kin *)

[Verwijderd]

Het binaire stelsel(grondtal 2) is het meest efficiente stelsel IMHO. Iets is er wel... of niet.
Anders wordt het Of fuzzy, Of een fout-reductie stelsel.

Als je al iets anders wilt, dan moet je in een andere dimensie denken (ik bedoel hier geen UFO/Blackhole-stuff)
Gewoon een binair stelsel met kleuren (laser chip)
Men neme dan bijvoorbeeld een AND-poort die op een normale manier werkt, maar tegelijker tijd met andere kleuren.
Hierbij zou je dezelfde schakelingen tegelijkertijd kunnen gebruiken ipv aparte, maar dan parallel en desnoods met een eigen timing.

Misschien als je ipv verbindingen 'gewoon' zender-chips maakt met frequentie modulatie, dan scheelt dat ook in bedrading. Dat zou super parallel kunnen werken, en een faradaykooi deromheen: klaar!

Met snelheid maak je betere compressie methoden mogelijk, zonder perse uit te wijken naar een ander stelsel.

offtopic:
DNA, werkt bijvoorbeeld met grondtal 4: C, G, T, A
mRNA, welke van DNA is afgeleid, 'vervangt' de T door een U.
en dan nog tRNA... bla-di-bla

Dat DNA een grondtal 4 heeft, werkt in het voordeel van decoderen.
Zo kun je toch een willekeurig begin punt vinden, zonder te weten waar die zit.
Dat gaat weer een stuk lastiger met een binair stelsel.

[MLM]

Stel je hebt een bestand waar je de hash van berekend H.
Als je nu ook eens de lengte van het bestand (aantal bytes) N zou weten, kun je in principe alle mogelijke bestanden met lengte N de hash Hn berekenen, en als die overeenkomt met gegeven H, heb je het originele bestand gevonden.

De kans dat je een bestand met dezelfde lengte EN dezelfde hash tegenkomt is erg klein tenzij je ERG grote bestanden hebt.

In principe kun je dus met gegeven H en N het bestand terugvinden, en is het dus eigenlijk een compressie

Los van dat dit niet erg praktisch is, is het wel mogelijk denk ik

[Verwijderd]

Meschien mis ik iets hoor.

Maar het binaire stelsel is volgenst mij totaal het probleem niet.
want de "waarde" van 101(binair) is gelijk aan 5(decimaal).
En het is de waarde die je moet noteren, of mee moet werken.

Gezien logiese constructies, nogsteeds opgebouwt zijn uit AND en OR en aanverwante en geralateerde bouw blokken, kan men daar enkel met een binair stelsel werken.
En de eenigste reden om dit verkeerd te vinden is als een andere manier meer snelheid op zou leveren.
Maar ik kan mij niet eens een manier bedenken, die niet in zijn essentie binair werkt. (al zegt dat niet veel)

Bij veel opslag methoden word er ook binair opgeslagen,
Maar bij somige methoden word het ook omgezet naar andere vormen.
Denk dan even groter dan de doos van de computer, en zie een printer die doormiddel van vormen data neer schrijft.
Of een beeldscherm, dat dit op een vergelijkbarere methode doet.

Dat deze vormen van opslag enkel indirect weer terug gevoed worden aan een computer is IMHO niet belangrijk.
Denk OCR/scanner zelfs zelf overtiepen.

En als je het zo benaderd, dan denk ik niet dat het veranderen van het stelsel ook maar echt nuttig gaat zijn.

(ik zie ook neit in wat het veranderen van een stelsel met compressie te maken heeft, en all helemaal niet wat compresse er mee te maken heeft.)

[ Voor 5% gewijzigd door Verwijderd op 23-09-2004 21:27 ]

[Zoijar]

MLM schreef op 22 september 2004 @ 22:29:
In principe kun je dus met gegeven H en N het bestand terugvinden, en is het dus eigenlijk een compressie

Ja, alleen dat je om alle bestanden van 1K te genereren je waarschijnlijk tot het einde der tijden bezig bent (256^1024...gigantisch)

[Makkelijk]

zal ik eens vanuit een niet theoretisch wetenschappelijk punt uitleggen waarom er nog geen cd-rom's worden gebruikt met 8 verschillende dieptes of vormpjes of kleurtjes van gaten voor meer mogelijkheiden..

dan worden de cd-rom's te duur

[Voutloos]

MLM schreef op 22 september 2004 @ 22:29:
De kans dat je een bestand met dezelfde lengte EN dezelfde hash tegenkomt is erg klein tenzij je ERG grote bestanden hebt.

Stel, je hebt 2³² hashes. Bedenk eens hoeveel verschillende strings er van 1 kilobyte zijn. 256¹⁰²⁴ dus. Dus zelfs al heb je een goede bestandsgrootte, dan nog heb je bij dit voorbeeld al heel veel dubbele occurences.

DKasemier schreef op 23 september 2004 @ 22:11:
zal ik eens vanuit een niet theoretisch wetenschappelijk punt uitleggen waarom er nog geen cd-rom's worden gebruikt met 8 verschillende dieptes of vormpjes of kleurtjes van gaten voor meer mogelijkheiden..

dan worden de cd-rom's te duur

Alle nieuwe technieken waren ooit bijna onbetaalbaar. Als iedereen zo dacht waren we niet zo ver als nu...

Bij veel opslag methoden word er ook binair opgeslagen,
Maar bij somige methoden word het ook omgezet naar andere vormen.

Ja, dat kan transparant gebeuren. Als Western Digital een platter uitvindt waarbij er per veld 4 niveaus magnetisme kunnen worden gebruikt, kunnen ze dat gewoon doen (en als financieel aantrekkelijk, zullen ze het ook doen). De controller kan gewoon normale data over de IDE richting de rest van de pc sturen en niemand die het door heeft. Dit is mijn inziens een voorbeeld van een verbetering die daadwerklijk mogelijk is.
Maar dit gaat nog steeds volgens de "hoeveelheid data = aantal eenheden * informatieve waarde van 1 eenheid" regel.
En dat is gewoon een logische regel. Ik kan daarom ook verder niet meegaan in alle andere zogenaamd revolutionaire concepten die op een andere manier, zonder compressie, data tevoorschijn toveren.

[ Voor 71% gewijzigd door Voutloos op 23-09-2004 22:45 ]