WFL Wetenschap, Filosofie, Levensbeschouwing
Discussieer hier over alle aspecten van de wetenschap, filosofische problemen en zaken van levensbeschouwelijke aard.
De wet van Shannon is uit 1948..quote:Op vrijdag 22 juli 2005 15:02 schreef BUG80 het volgende:
Het blijft natuurlijk theoretisch gewauwel, maar 60 jaar geleden geloofde ook niemand dat je muziek op kon slaan op 1/7 van de grootte, zonder perceptioneel verlies. Zeg nooit nooit!
In Baden-Badener Badeseen kann man Baden-Badener baden sehen.
Das best pittig voor de kappersschool, niet?quote:Op vrijdag 22 juli 2005 15:05 schreef SunChaser het volgende:
Waar hebben jullie allemaal gestudeerd In mijn tijd kregen we gewoon economie en geschiedenis over Willem van Oranje op school
In mijn tijd kregen we gewoon economie en geschiedenis over Willem van Oranje op school 
In Baden-Badener Badeseen kann man Baden-Badener baden sehen.
Dat ging niet over perceptioneel coderen, toch. De werking van het oor is pas halverwege de jaren '50 in detail onderzocht.quote:Op vrijdag 22 juli 2005 15:06 schreef Pietverdriet het volgende:
[..]
De wet van Shannon is uit 1948..
We dwalen weer af
Mijn mixtape: labtones.com/listener/JSP
Och... Je hebt soms mensen die een Balthazar Gerards kapsel willenquote:Op vrijdag 22 juli 2005 15:08 schreef Pietverdriet het volgende:
[..]
Das best pittig voor de kappersschool, niet?
Overigens heb ik nu even 'snel' een applet geschreven die mijn compressiemethode simpel laat zien, ik zal hem even ergens parkeren.
Zet je onduleerijzers maar aan...quote:Op vrijdag 22 juli 2005 15:13 schreef SunChaser het volgende:
[..]
Och... Je hebt soms mensen die een Balthazar Gerards kapsel willen
In Baden-Badener Badeseen kann man Baden-Badener baden sehen.
Mooi!quote:Op vrijdag 22 juli 2005 15:20 schreef gelly het volgende:
Overigens heb ik nu even 'snel' een applet geschreven die mijn compressiemethode simpel laat zien, ik zal hem even ergens parkeren.
Ik heb hier vast een voorbeeldbestandje neergezet:
http://www.free-space.us/gnomaat/compression_test.zip (zit een file van 10 KB in)
Deze zip is nog niet password protected ofzo, maar kun je vast kijken of het een beetje werkt.
Birthdays are good for you: the more you have, the longer you live.
Hold your horses Het is een applet om te laten zien dat compressie van meer dan 50% mogelijk is en dat die compressie toeneemt naarmate het te coderen getal groter wordt...quote:Op vrijdag 22 juli 2005 15:46 schreef gnomaat het volgende:
[..]
Mooi!
Ik heb hier vast een voorbeeldbestandje neergezet:
http://www.free-space.us/gnomaat/compression_test.zip (zit een file van 10 KB in)
Deze zip is nog niet password protected ofzo, maar kun je vast kijken of het een beetje werkt.
Het is een applet om te laten zien dat compressie van meer dan 50% mogelijk is en dat die compressie toeneemt naarmate het te coderen getal groter wordt... Ik zoek alleen even een webspace om de boel te dumpen, ben het wachtwoord van de mijne kwijt...
* yootje biedt webspace aan.quote:Op vrijdag 22 juli 2005 15:54 schreef gelly het volgende:
[..]
Hold your horses Het is een applet om te laten zien dat compressie van meer dan 50% mogelijk is en dat die compressie toeneemt naarmate het te coderen getal groter wordt...
Ik zoek alleen even een webspace om de boel te dumpen, ben het wachtwoord van de mijne kwijt...
http://www.free-space.us/primer/Applet1.html
Je kunt deze applet beter in een standalone viewer bekijken, zowel firefox als IE zweten nogal als het ingegeven getal erg groot wordt. Het loopt niet vast, al lijkt het wel zo.
Je kunt deze applet beter in een standalone viewer bekijken, zowel firefox als IE zweten nogal als het ingegeven getal erg groot wordt. Het loopt niet vast, al lijkt het wel zo.
Used primes : 8 for 9 decimals
Compression is 88 %
Used primes : 0 for 1024 decimals
Compression is 0 %
Used primes : 0 for 1024 decimals
Compression is 0 %
Compression is 88 %
Used primes : 0 for 1024 decimals
Compression is 0 %
Used primes : 0 for 1024 decimals
Compression is 0 %
Beweert die applet nu dat het zulke grote priemgetallen in 1 byte codeert?quote:Op vrijdag 22 juli 2005 16:15 schreef gelly het volgende:
http://www.free-space.us/primer/Applet1.html
Je kunt deze applet beter in een standalone viewer bekijken, zowel firefox als IE zweten nogal als het ingegeven getal erg groot wordt. Het loopt niet vast, al lijkt het wel zo.
Ja, ik sla namelijk niet de priemgetallen zelf op, alleen het hoeveelste Mersenne priemgetal het is.quote:Op vrijdag 22 juli 2005 16:25 schreef XoxIx het volgende:
[..]
Beweert die applet nu dat het zulke grote priemgetallen in 1 byte codeert?
Dan kan je dus nog theoretisch veel meer compressie halen door hierna nog eens Huffman compressie er overheen te halen (de zip-methode).quote:Op vrijdag 22 juli 2005 16:27 schreef gelly het volgende:
[..]
Ja, ik sla namelijk niet de priemgetallen zelf op, alleen het hoeveelste Mersenne priemgetal het is.
Mijn mixtape: labtones.com/listener/JSP
Ik zou wel eens willen kijken tot hoever die compressie gaat, het lijkt namelijk zo dat de compressie groter wordt naarmate de getallen groter worden. Over die 171 decimals deed mn comp 5 minuten, maar het is ook in Java geschreven.
Je rekent niet correct. Je input mag maar 10 verschillende waarden hebben (0..9), maar het rangnummer van je priemgetal kan best 1.000.000 zijn (dus 1 miljoen verschillende waarden).quote:Op vrijdag 22 juli 2005 16:27 schreef gelly het volgende:
[..]
Ja, ik sla namelijk niet de priemgetallen zelf op, alleen het hoeveelste Mersenne priemgetal het is.
Als je het goed wilt doen moet je dus berekenen hoe lang de decimale representatie is van je priemgetallen. Bijvoorbeeld:
121 = 101 + 19 + 2
Dat wordt niet: 3 voor 3 met geen compressie, maar 6 voor 3 is 100% verlies.
Zelfs nu wordt er nog wat gesjoemeld, maar niet meer zo erg als dat in het applet gebeurt.
Klopt, daarom werkt het ook niet bij kleine getallen, nou ja het werkt wel maar er is verlies. Ik gebruik enorm grote priemgetallen die in kleine notatie worden weergegeven. Test het maar in de applet, je zal zien dat hoe groter de getallen worden hoe groter de compressie wordt.quote:Op vrijdag 22 juli 2005 16:37 schreef XoxIx het volgende:
[..]
Je rekent niet correct. Je input mag maar 10 verschillende waarden hebben (0..9), maar het rangnummer van je priemgetal kan best 1.000.000 zijn (dus 1 miljoen verschillende waarden).
Als je het goed wilt doen moet je dus berekenen hoe lang de decimale representatie is van je priemgetallen. Bijvoorbeeld:
121 = 101 + 19 + 2
Dat wordt niet: 3 voor 3 met geen compressie, maar 6 voor 3 is 100% verlies.
Zelfs nu wordt er nog wat gesjoemeld, maar niet meer zo erg als dat in het applet gebeurt.
Als je je applet hebt aangepast. Je telt het aantal priemgetallen dat je gebruikt, niet het aantal tekens dat je gebruikt, terwijl je bij de input kijkt naar het aantal tekens.quote:Op vrijdag 22 juli 2005 16:42 schreef gelly het volgende:
[..]
Klopt, daarom werkt het ook niet bij kleine getallen, nou ja het werkt wel maar er is verlies. Ik gebruik enorm grote priemgetallen die in kleine notatie worden weergegeven. Test het maar in de applet, je zal zien dat hoe groter de getallen worden hoe groter de compressie wordt.
Hij heeft gelijk, ja. Als je het goed wil doen moet je alle 256 mogelijke karakters die je kunt maken met een byte accepteren. Het getal '121' kun je namelijk makkelijk in 1 byte kwijt, terwijl jij het in 3 stopt en er vervolgens weer 3 van maakt.quote:Op vrijdag 22 juli 2005 16:37 schreef XoxIx het volgende:
[..]
Je rekent niet correct. Je input mag maar 10 verschillende waarden hebben (0..9), maar het rangnummer van je priemgetal kan best 1.000.000 zijn (dus 1 miljoen verschillende waarden).
Als je het goed wilt doen moet je dus berekenen hoe lang de decimale representatie is van je priemgetallen. Bijvoorbeeld:
121 = 101 + 19 + 2
Dat wordt niet: 3 voor 3 met geen compressie, maar 6 voor 3 is 100% verlies.
Zelfs nu wordt er nog wat gesjoemeld, maar niet meer zo erg als dat in het applet gebeurt.
Mijn mixtape: labtones.com/listener/JSP
Ik kan elk gebruikt priemgetal opslaan in 1 byte, dus waarom zou ik daar rekening mee moeten houden ? Het integere getal dat je ingeeft is in feite de integere weergave van data. Het is niet zo dat dat getal in een bestand komt te staan.quote:Op vrijdag 22 juli 2005 16:44 schreef XoxIx het volgende:
[..]
Als je je applet hebt aangepast. Je telt het aantal priemgetallen dat je gebruikt, niet het aantal tekens dat je gebruikt, terwijl je bij de input kijkt naar het aantal tekens.
Zie mijn post. Je telt getallen tot 256 als 3 karakters/bytes in plaats van 1.quote:Op vrijdag 22 juli 2005 16:48 schreef gelly het volgende:
[..]
Ik kan elk gebruikt priemgetal opslaan in 1 byte, dus waarom zou ik daar rekening mee moeten houden ? Het integere getal dat je ingeeft is in feite de integere weergave van data. Het is niet zo dat dat getal in een bestand komt te staan.
Mijn mixtape: labtones.com/listener/JSP
Uhm nee. Ik kan met een byte aangeven welke plaats het priemgetal heeft in de index van Mesenne priemgetallen. Je moet die getallen niet als karakters zien maar als de integere weergave van bytes.quote:Op vrijdag 22 juli 2005 16:49 schreef BUG80 het volgende:
[..]
Zie mijn post. Je telt getallen tot 256 als 3 karakters/bytes in plaats van 1.
Juist. Maar in de invoer doe je dat niet en dat is niet eerlijk. De volgende invoer sequentie:quote:Op vrijdag 22 juli 2005 16:51 schreef gelly het volgende:
[..]
Uhm nee. Ik kan met een byte aangeven welke plaats het priemgetal heeft in de index van Mesenne priemgetallen. Je moet die getallen niet als karakters zien maar als de integere weergave van bytes.
100 255 8 1 3
is niet 9 bytes waard zoals jouw applet zou zeggen, maar 5. Vergeet niet dat een willekeurig bestand niet alleen bestaat uit de getallen 0-9 maar het complete ASCII alfabet. Als je dat omzet naar getallen kom je op sequenties als hierboven.
Kortom, je compressie is (helaas) niet zo goed als het lijkt.
Mijn mixtape: labtones.com/listener/JSP
Weet je wat, ik geef even een voorbeeld. Het volgende is een willekeurig bestand van 10 bytes:
Als ik dit omzet naar (ASCII) getallen wordt het:quote:N‹'³aÜÛ˜æ
In getallen 0-9 heeft het dus een lengte van 27 bytes. Jouw applet geeft:quote:78 139 39 179 97 220 219 152 127 230
Kortom, hij vergroot het bestand van 10 naar 21 bytes!!quote:Used primes : 21 for 27 decimals
Compression is 77 %
Mijn mixtape: labtones.com/listener/JSP
Heb dat boek (De Broncode) twee maandjes geleden voor 1,5 euro gekocht als afgeschreven boek bij m'n bieb... Raar dat het er toen al lag: in perfecte nieuwstaat en met een voorwoord van augustus 2004.
Hier nog een link naar een ietwat slordig geschreven Word document met daarin een verhaal waarin de auteur probeert uit te leggen dat er een kern van waarheid zou kunnen zitten in de verhalen van Sloot, hoewel hij wel stevig moest hebben overdreven volgens die theorie.
Mijn mixtape: labtones.com/listener/JSP
Maar wat heeft dat voor zin, dan kun je alleen data (getallen) van precies die vorm compressen, of anders maakt het restant wat je ook nog moet compressen het totaal groter dan het origineel.quote:Op vrijdag 22 juli 2005 16:27 schreef gelly het volgende:
Ja, ik sla namelijk niet de priemgetallen zelf op, alleen het hoeveelste Mersenne priemgetal het is.
Birthdays are good for you: the more you have, the longer you live.
Zie mijn voorbeeld.quote:Op vrijdag 22 juli 2005 17:37 schreef gnomaat het volgende:
[..]
Maar wat heeft dat voor zin, dan kun je alleen data (getallen) van precies die vorm compressen, of anders maakt het restant wat je ook nog moet compressen het totaal groter dan het origineel.
Het idee is mooi, dat wel.
Mijn mixtape: labtones.com/listener/JSP
Misschien had Sloot wel priemwoorden gevonden in plaats van priemgetallen
Mijn mixtape: labtones.com/listener/JSP
Dat is geen eerlijke vergelijking.quote:Op vrijdag 22 juli 2005 17:01 schreef BUG80 het volgende:
Weet je wat, ik geef even een voorbeeld. Het volgende is een willekeurig bestand van 10 bytes:
[..]
Als ik dit omzet naar (ASCII) getallen wordt het:
[..]
In getallen 0-9 heeft het dus een lengte van 27 bytes. Jouw applet geeft:
[..]
Kortom, hij vergroot het bestand van 10 naar 21 bytes!!
In je eerste stap, als je het omzet naar ASCII, zeg je "dit getal heeft een lengte van 27 bytes". Maar op die manier hangt het van de data af, als er veel bytes met ascii waarde onder de 100 in zitten worden het veelal getallen van 2 decimalen, en veel boven de 100, dan 3.
Je moet het hele bestand als één groot getal zien: 78 + 256*139 + 2562*39 + ... enz
Vervolgens, als hij een getal van 27 decimalen comprimeert naar 21 decimalen, kun je niet zeggen "dat zijn 21 bytes, en da's groter dan 10". Dat getal van 21 decimalen moet je dan weer splitsen in ASCII waarden en die bytes schrijf je weg. Dat zijn er dan veel minder dan 21. Zo begon je tenslotte ook met je oorspronkelijke bestand.
Dus je schrijft een byte weg met de waarde (getal mod 256), en vervolgens deel je het getal door 256 (afronden naar beneden). Dit herhaal je tot je nul overhoudt.
Overigens heeft deze methode van het interpreteren van een bestand als getal nog het probleem dat je geen verschil kunt zien tussen een bestand bestaande uit twee nul-bytes of uit tweehonderd nul-bytes.
Birthdays are good for you: the more you have, the longer you live.
Er is geen restant...quote:Op vrijdag 22 juli 2005 17:37 schreef gnomaat het volgende:
[..]
Maar wat heeft dat voor zin, dan kun je alleen data (getallen) van precies die vorm compressen, of anders maakt het restant wat je ook nog moet compressen het totaal groter dan het origineel.
Ik heb dit met een random generator gedaan, het viel toevallig hoog uit. De verwachtingswaarde voor de lengte van een ASCII getal is (100*1 + 100*2 + 56*3)/256 = 1,82 decimalen.quote:Op vrijdag 22 juli 2005 17:45 schreef gnomaat het volgende:
[..]
Dat is geen eerlijke vergelijking.
In je eerste stap, als je het omzet naar ASCII, zeg je "dit getal heeft een lengte van 27 bytes". Maar op die manier hangt het van de data af, als er veel bytes met ascii waarde onder de 100 in zitten worden het veelal getallen van 2 decimalen, en veel boven de 100, dan 3.
Dat doet het applet van Gelly ook precies, dus volgens mij is dit wel een eerlijke vergelijking.quote:Vervolgens, als hij een getal van 27 decimalen comprimeert naar 21 decimalen, kun je niet zeggen "dat zijn 21 bytes, en da's groter dan 10". Dat getal van 21 decimalen moet je dan weer splitsen in ASCII waarden en die bytes schrijf je weg. Dat zijn er dan veel minder dan 21. Zo begon je tenslotte ook met je oorspronkelijke bestand.
edit: Het applet van Gelly schrijft '186' dus weg als 1 ASCII byte i.p.v. "1", "8" en "6".
Mijn mixtape: labtones.com/listener/JSP
Hij bedoelt met restant: alles wat niet in de range 0-9 valt.quote:
Mijn mixtape: labtones.com/listener/JSP
Dat kan omdat dat 'karakter' onderdeel is van een groter getal.quote:Op vrijdag 22 juli 2005 17:50 schreef BUG80 het volgende:
[..]
edit: Het applet van Gelly schrijft '186' dus weg als 1 ASCII byte i.p.v. "1", "8" en "6".
Snap je wat ik bedoel met mijn getallenvoorbeeld? Dat bestand van 10 bytes?quote:Op vrijdag 22 juli 2005 17:56 schreef gelly het volgende:
[..]
Dat kan omdat dat 'karakter' onderdeel is van een groter getal.
Mijn mixtape: labtones.com/listener/JSP
hierbij geldt hetzelfde principe als hierboven al aangehaald. ik kan in een paar bytes een heel groot getal produceren, maar ik kan niet in een paar bytes elk groot getal produceren. zoiets valt via relatief eenvoudige logica te bewijzen.quote:Op donderdag 21 juli 2005 15:48 schreef Danny het volgende:
[..]
Veel getallen die je niet in 1 notatie samen kunt vatten kun je wellicht wel in meerdere wiskundige notaties samenvatten waar je dan na bewerking (optellen bv) WEL het juiste getal uitkrijgt.
Zelfs al zou je een getal van 20 miljoen cijfers dan moeten opdelen is 10.000 van die korte notaties heb je alsnog van 20Mb 100Kb gemaakt.
fotoboek.fok.nl/-erwin-
Ik heb geen respect voor gelovigen en hun geloof.
Mijn posts reflecteren niet noodzakelijkerwijs mijn mening.
Ik heb geen respect voor gelovigen en hun geloof.
Mijn posts reflecteren niet noodzakelijkerwijs mijn mening.
Klopt. Echter is 4kb daarvoor veel en veel te klein. Zelfs met 1 film kun je door alle scenes in andere volgordes te zetten al bijna genoeg verschillende mogelijkheden produceren om 4kb vol te krijgen. Laat staan dat je alle mogelijke films zou kunnen opslaan op die manier.quote:Op vrijdag 22 juli 2005 15:02 schreef BUG80 het volgende:
[..]
Wat dat betreft ben ik het helemaal met je eens, maar ben jij het met mij eens dat als je in het bezit bent van een soort super database/Huffman tree (die niet bestaat denk ik), het dan wel mogelijk moet zijn om veel verder te comprimeren dan dat, zolang je die database maar apart opslaat.
Voor mij staan een aantal zaken als een paal boven water.
1. Het is een lossy compressie.
2. 4kb is onmogelijk. Ordes in de tientallen danwel honderden megabytes lijken aannemelijker.
3. De grootte van de data ligt niet vast. Langere film betekent meer data.
4. Het systeem heeft waarschijnlijk nooit bestaan.
fotoboek.fok.nl/-erwin-
Ik heb geen respect voor gelovigen en hun geloof.
Mijn posts reflecteren niet noodzakelijkerwijs mijn mening.
Ik heb geen respect voor gelovigen en hun geloof.
Mijn posts reflecteren niet noodzakelijkerwijs mijn mening.
Okee, dan heb ik twee briljante manieren om files te compressen:quote:Op vrijdag 22 juli 2005 17:50 schreef BUG80 het volgende:
Ik heb dit met een random generator gedaan, het viel toevallig hoog uit. De verwachtingswaarde voor de lengte van een ASCII getal is (100*1 + 100*2 + 56*3)/256 = 1,82 decimalen.
1. Schrijf een bestand 1000 bytes uit als decimalen zoals bovenstaand. Naar verwachting krijg je dan zo'n 1828 decimalen (hangt natuurlijk van je bestand af, maar gemiddeld).
Aangezien je makkelijk 2 decimalen per byte kunt opslaan (dat worden bytes met ascii waarden 0 t/m 99) heb je dus 914 bytes nodig om die decimalen weer op te slaan. Blijft over: 914/1000 = 91%. Dit is recursief toepasbaar.
2. Voordat je dit doet tel je eerst de frequentie van alle bytes. Vervolgens verwissel je de bytes zodat de meest veelvoorkomende bytes de laagste ascii waarden krijgen. Op die manier heb je zoveel mogelijk bytes die zo min mogelijk decimalen kosten. Het verwisselen kost enkel een re-map tabel van 256 bytes, ongeacht hoe groot het bestand.
En, zie je al waar de fout zit?
Birthdays are good for you: the more you have, the longer you live.
Gelly, om inzicht te krijgen in het feit dat je methode niet doet wat je claimt stel ik voor dat je een willekeurig inputbestand genereert dat je vervolgens comprimeert met jou methode waarna je het decomprimeert en vergelijkt met het origineel. Kijk dan eens naar de compressie ratio.
Alleen als het precies een groot priemgetal is.quote:Op vrijdag 22 juli 2005 17:49 schreef gelly het volgende:
Er is geen restant...
Als de input data bijvoorbeeld 618970019642690137449562111 is, dan kun je volstaan met "89" (omdat 289-1 = dat getal), of zelfs "9" (omdat 289-1 het tiende Mersenne priemgetal is en je begint te tellen vanaf 0).
Maar dat is een zeer uitzonderlijke input. Wat nu als de input bijvoorbeeld 761825315945362690850838009 is?
Birthdays are good for you: the more you have, the longer you live.
Oh ja dit klopt trouwens ook niet helemaal:
Maar dat was niet eens de grootste fout in mijn "briljante" nieuwe compressiemethode van hierboven
Moet zijn (10*1 + 90*2 + 156*3)/256 = 2.57 decimalen gemiddeld per byte.quote:Op vrijdag 22 juli 2005 17:50 schreef BUG80 het volgende:
Ik heb dit met een random generator gedaan, het viel toevallig hoog uit. De verwachtingswaarde voor de lengte van een ASCII getal is (100*1 + 100*2 + 56*3)/256 = 1,82 decimalen.
Maar dat was niet eens de grootste fout in mijn "briljante" nieuwe compressiemethode van hierboven
Birthdays are good for you: the more you have, the longer you live.
Ehh nee. Volgens mij heb je zojuist gewoon een eerste opzet voor een Huffman tree ontworpen, alleen dan met behulp van bytes ipv bits of ik mis ietsquote:Op vrijdag 22 juli 2005 18:30 schreef gnomaat het volgende:
[..]
Okee, dan heb ik twee briljante manieren om files te compressen:
1. Schrijf een bestand 1000 bytes uit als decimalen zoals bovenstaand. Naar verwachting krijg je dan zo'n 1828 decimalen (hangt natuurlijk van je bestand af, maar gemiddeld).
Aangezien je makkelijk 2 decimalen per byte kunt opslaan (dat worden bytes met ascii waarden 0 t/m 99) heb je dus 914 bytes nodig om die decimalen weer op te slaan. Blijft over: 914/1000 = 91%. Dit is recursief toepasbaar.
2. Voordat je dit doet tel je eerst de frequentie van alle bytes. Vervolgens verwissel je de bytes zodat de meest veelvoorkomende bytes de laagste ascii waarden krijgen. Op die manier heb je zoveel mogelijk bytes die zo min mogelijk decimalen kosten. Het verwisselen kost enkel een re-map tabel van 256 bytes, ongeacht hoe groot het bestand.
En, zie je al waar de fout zit?
of ik mis ietsEn inderdaad de verwachtingswaarde voor de lengte in decimalen van een ASCII waarde is 2.57, mijn fout, sorry
[edit]Methode 1 vervalt dus al, aangezien gemiddeld genomen je bestanden groter worden met deze methode. Je bestand van 1000 bytes worden 2570 decimalen. Dit gedeeld door 2 = 1285[/edit]
Waar het verhaal van Gelly fout gaat is het volgende: hij comprimeert decimalen terug naar bytes met behulp van ontbinding in priemgetallen, in plaats van bytes naar bytes, wat veel eerlijker zou zijn. Dat is wat ik probeer duidelijk te maken.
[ Bericht 5% gewijzigd door BUG80 op 22-07-2005 19:13:49 ]
Mijn mixtape: labtones.com/listener/JSP
Probeer anders eens het volgende bestand te comprimeren met behulp van de methode van Gelly, je zult zien dat het groter wordt:
Ik heb expres 'leesbare' karakters gebruikt. Succes.quote:x6YNsgK#mJ
Mijn mixtape: labtones.com/listener/JSP
Nogmaals, volgens mij bedoelde hij niet restant als in "modulo", maar het restant als je alleen de decimalen in een bestand comprimeert. Een gemiddeld bestand bestaat namelijk uit veel meer dan alleen decimalen.quote:Op vrijdag 22 juli 2005 18:45 schreef gnomaat het volgende:
[..]
Alleen als het precies een groot priemgetal is.
Als de input data bijvoorbeeld 618970019642690137449562111 is, dan kun je volstaan met "89" (omdat 289-1 = dat getal), of zelfs "9" (omdat 289-1 het tiende Mersenne priemgetal is en je begint te tellen vanaf 0).
Maar dat is een zeer uitzonderlijke input. Wat nu als de input bijvoorbeeld 761825315945362690850838009 is?
Mijn mixtape: labtones.com/listener/JSP
Dit is ook een ruwe opzet hoor, ben nog druk bezig te kijken wat het beste werkt. Je kunt je voorstellen dat je door het scannen van datareeksen getallen tegenkomt die je door een veel kortere notatie kunt vervangen. Een combinatie van verschillende logaritmen moet zeker een forse compressie oplever mijns inziens.quote:Op vrijdag 22 juli 2005 18:45 schreef gnomaat het volgende:
[..]
Alleen als het precies een groot priemgetal is.
Als de input data bijvoorbeeld 618970019642690137449562111 is, dan kun je volstaan met "89" (omdat 289-1 = dat getal), of zelfs "9" (omdat 289-1 het tiende Mersenne priemgetal is en je begint te tellen vanaf 0).
Maar dat is een zeer uitzonderlijke input. Wat nu als de input bijvoorbeeld 761825315945362690850838009 is?
Gelly, please
Je vergelijkt appels met peren. Je begint met decimalen met een bandbreedte van 0-9, die je vervolgens ontbindt in priemgetallen, die je opslaat als bytes in bandbreedte 0-255. Vind je het gek dat je compressie bereikt.
Neem het volgende getal (lengte 22 decimalen):
179 28 73 102 92 83 38 39 238 2
Nou zijn het er ineens nog maar 10! Kortom met de hand bereik ik meer compressie dan met jouw methode!
Je vergelijkt appels met peren. Je begint met decimalen met een bandbreedte van 0-9, die je vervolgens ontbindt in priemgetallen, die je opslaat als bytes in bandbreedte 0-255. Vind je het gek dat je compressie bereikt.
Neem het volgende getal (lengte 22 decimalen):
Jouw applet maakt daar 16 priemgetallen van, die je opslaat als bytes met waarde 0-255. Met de hand kan ik er echter ook bytes van maken:quote:1792873102928338392382
179 28 73 102 92 83 38 39 238 2
Nou zijn het er ineens nog maar 10! Kortom met de hand bereik ik meer compressie dan met jouw methode!
Mijn mixtape: labtones.com/listener/JSP
Gemiddeld levert dat minder winst op dan de extra ruimte die het je kost om de metadata voor zo'n notatie op te slaan. Ongeacht je methode of het type korte notatie dat je gebruikt.quote:Op vrijdag 22 juli 2005 19:35 schreef gelly het volgende:
Dit is ook een ruwe opzet hoor, ben nog druk bezig te kijken wat het beste werkt. Je kunt je voorstellen dat je door het scannen van datareeksen getallen tegenkomt die je door een veel kortere notatie kunt vervangen. Een combinatie van verschillende logaritmen moet zeker een forse compressie oplever mijns inziens.
Maar goed, mijn challenge staat nog steeds, werk je idee gerust uit. Als je een appje weet te bakken dat mijn 10KB bestand onder de 9 KB krijgt (dus een file van maximaal 9216 bytes) dan
Birthdays are good for you: the more you have, the longer you live.
gnomaat, kun je deze vraag nog even beantwoorden?quote:Op vrijdag 22 juli 2005 18:30 schreef gnomaat het volgende:
En, zie je al waar de fout zit?
Mijn mixtape: labtones.com/listener/JSP
Hint: als het decimale getal 112131032202120121 is, van welke ascii waardes komt dat dan? (m.a.w. welke originele file hoort hierbij?)quote:Op vrijdag 22 juli 2005 20:22 schreef BUG80 het volgende:
gnomaat, kun je deze vraag nog even beantwoorden?
Birthdays are good for you: the more you have, the longer you live.
|
|
