Springen naar inhoud

Effectiever opslaan van niet(-gebruikte) bits


  • Log in om te kunnen reageren

#1

pieter_vl

    pieter_vl


  • 0 - 25 berichten
  • 3 berichten
  • Gebruiker

Geplaatst op 19 juni 2009 - 13:58

Normaal gebruik je 256 bits voor één byte. Nu is het momenteel zo dat ik alleen gebruik maak van de eerste 220 bits van de zgn. ASCII table.

Bestaat er in mijn geval een mogelijkheid om effectiever gebruik te maken van het binair stelsel door die overige 36 bits niet mee te rekenen?
Het lijkt mij namelijk dat je kunt besparen bij 8 bytes van 220 hebt ten opzichte van 8 bytes van 256. 8 maal het verschil van 36 is namelijk 288. Klopt dat?

Veranderd door pieter_vl, 19 juni 2009 - 14:01


Dit forum kan gratis blijven vanwege banners als deze. Door te registeren zal de onderstaande banner overigens verdwijnen.

#2

jadatis

    jadatis


  • >250 berichten
  • 347 berichten
  • Ervaren gebruiker

Geplaatst op 19 juni 2009 - 14:17

Het is dacht ik 8, 16, of 32 bits wat gebruikt wordt, 8 bits geeft 256 mogelijkheden zal je bedoelen.
Dit is wat vroeger voor letters en datums gedaan werd, en waardoor min of meer het mileniumprobleem ontstaan is.
Dus het is mogelijk . er werd gekeken naar de hoeveelste dag van het jaar of zelfs vanaf bijvoorbeeld 1900 en dat werd als getal verder verwerkt, en later zo nodig weer terug gerekent.
Soortgelijk met de letters waardoor je in 2 bytes 3 letters kon krijgen.
Weet het niet meer precies, dus kan nog iets anders zijn, maar wel van die strekking.
Met de huidige computercapaciteit dus gelukkig niet meer nodig, maar destijds moest iedere byte ten volle benut worden.
Met jouw voorbeeld zou je dus theoretisch 256 tekens in 220 bytes kunnen proppen.

Veranderd door jadatis, 19 juni 2009 - 14:25


#3

pieter_vl

    pieter_vl


  • 0 - 25 berichten
  • 3 berichten
  • Gebruiker

Geplaatst op 19 juni 2009 - 15:14

Dank voor je reactie.

Misschien een fictief voorbeeld ter verduidelijking.

1: 00000001 = A
2: 00000010 = B
etc.....
220: 11011100 = Z

Maar alles boven de 220 gebruik ik niet. Dus bijvoorbeeld 253 zal nooit voorkomen.
221: 11011101 = altijd leeg
tot
256: 11111111 = altijd leeg

Die laatste 36 mogelijkheden gebruik ik dus nooit. En zoals jij ook al aangaf wil ik juist elke byte benutten.

Nu zat ik zelf te denken aan de mogelijkheid om er dubbele combinatie in te stoppen:
221: AB
222: AC
etc....
256: BF

Maar ja, dan nog is de vraag of deze combinaties voorkomen in mijn reeks met bytes. En ik kan vooraf helaas niet bepalen welke combinaties er wel of niet in voorkomen.

Waar ik eigenlijk op hoop is dat ik effectief die laatste 36 bits kan gebruiken. Bijvoorbeeld door middel van de eerste 36 bits van de 2e byte mee te laten tellen in de vrije ruimte van de eerste byte.

#4

jadatis

    jadatis


  • >250 berichten
  • 347 berichten
  • Ervaren gebruiker

Geplaatst op 19 juni 2009 - 16:16

256 tekens in 220 bytes is hetzelfde als 64 tekens in 55 bytes.
Dan zou je met een klein programmatje dat aanzienlijk minder ruimte inneemt dan de winst die je er mee behaalt, en dat is niet moeilijk bij grote bestanden, per serie van 64 tekens de ASCI code van deze met elkaar vermenigvuldigen en dat getal past dan altijd in de 55 bytes.
Je werkt dan wel met zeer grote getallen. edit: zie nu al weer dat dit niet zo kan werken, zal wel net iets anders gaan, maar idee blijft overeind.
Er werden dan ook wel tekens, die voor het doel toch niet gebruikt werden, weggelaten om zo met minder tekens het in nog minder bytes te kunnen proppen. Daardoor werd het dan bij buitenlandse namen wat moeilijker en moest daar weer een lettercombinatie gebruikt worden. Denk aan ö wat dan eu werd.
Je hebt dan wel enige ruimte nodig om de boel uit te pakken, maar bij grote bestanden toch een flinke winst.

Veranderd door jadatis, 19 juni 2009 - 16:28


#5

jadatis

    jadatis


  • >250 berichten
  • 347 berichten
  • Ervaren gebruiker

Geplaatst op 19 juni 2009 - 16:37

Ik kom er al meer uit nu.
bijvoorbeeld de eerste 7 bits van Byte 1 worden voor de eerste letter gebruikt.
Bit 8van Byte 1 en Bit 1 tm 6 van Byte2 voor letter 2
Bit 7 en 8 van Byte 2 en Bit 1 tm 5 van Byte 3 voor letter 3. ENZ.
Dit dient dan door een klein programmatje geregeld te worden, alleen hoe dat precies gedaan werdt kan ik nu niet meer reproduceren.

Zo hoef je dus geen dubbellettercombinaties te maken, die je dan ook weer zelden gebruikt.
En hoe minder letters je gebruikt , hoe meer winst 64 tekens heb je 6 bits voor nodig, Genoeg voor kleine en hoofdletters en de cijfers (net niet). De X en de Q en de Y werden dan soms weg gelaten en in de zin veranderd in Ks Ku en IJ.

Veranderd door jadatis, 19 juni 2009 - 16:42


#6

pieter_vl

    pieter_vl


  • 0 - 25 berichten
  • 3 berichten
  • Gebruiker

Geplaatst op 19 juni 2009 - 17:08

Ik begrijp je helemaal. Echter gaat je voorbeeld niet op in mijn verhaal.

Dit omdat die laatste bit van mijn byte al in gebruik is. Met andere woorden, ik gebruik alle bits wel, maar er zijn nog lege 'opties'.

Stel dat ik nu 120 combinaties wil maken, dan klopt je voorbeeld inderdaad. 120 valt binnen 128 (2^7) mogelijkheden. En dus zou ik die laatste bit kunnen gebruiken voor de 2e byte.

Nu wil ik 220 combinaties maken, dus moet ik gebruik maken van 256(2^8). Die laatste bit kan ik dus niet gebruiken voor een 2e byte, want hij is al in gebruik.

Die 220 mogelijkheden passen dus netjes in die 8 bits, echter heb ik nog 36 plaatsen over. En het feit dat ik ze niet gebruik vind ik zonde, dus ik wil iets met die 36 mogelijkheden doen.

Veranderd door pieter_vl, 19 juni 2009 - 17:11


#7

Gesp

    Gesp


  • >250 berichten
  • 339 berichten
  • Ervaren gebruiker

Geplaatst op 20 juni 2009 - 09:55

Inderdaad blijft er ruimte over, maar dat is minder dan je denkt. Want als je 2 tekens wilt weergeven, wil je eigenlijk alle mogelijke combinaties van die 2 tekens kunnen weergeven = 220^2. (220 staat voor 0 tot 219).
Als je dus 8 tekens wilt weergeven wordt dat 220^8 combinaties. Als je bytes gebruikt, kost dat 8 bytes (want 8^8 = 1.8e+19, en 220^8= 5.4e+18). Met 8 bytes kun je dus alle combinaties weergeven (en nog wat extra).

8 bits vormen een code die naar 1 teken verwijzen. Met reeksen van 8 bits vorm je een reeks bytes die naar een reeks tekens verwijzen. Je kunt ook losse bits naar een reeks tekens laten verwijzen, bv 8 tekens lang. Een unieke combinatie van bits verwijst naar een unieke combinatie van tekens. Maar bij 8 tekens win je maar 1 bit (63 bits ipv 8 byte). Want 2^63= 9.2e18 en 2^62=4.6e18.
Je wint pas 8 bits bij 37 tekens, want kun je toe met 288 bits ipv 296.

* Je kunt meer winnen door nog eens naar je tekenset te kijken, en deze verder te beperken. Als je maar 210 tekens nodig zou hebben, dan zou je dezelfde 8-bits winst al bij sets van 28 tekens (ipv 37) boeken.
* Je zou eventueel extra winst kunnen halen door bepaalde tekencombinaties weg te laten die nooit voorkomen.
* Als er een basisset is, kleiner dan 2^6 waarmee je in zeg 90% van de gevallen toekunt, zou je een hybride systeem kunnen ontwerpen: als het begint met een nulbit, dan zijn de volgende 6 bits voor teken X, anders de volgende 8 bits.
* Daarnaast kun je natuurlijk extra winst boeken door achteraf te comprimeren (zippen).

Maar er blijft altijd enige informatie-ruimte die niet gebruikt wordt.

#8

TD

    TD


  • >5k berichten
  • 24049 berichten
  • VIP

Geplaatst op 20 juni 2009 - 12:45

Verplaatst naar programmeren.
"Malgré moi, l'infini me tourmente." (Alfred de Musset)

#9

Cycloon

    Cycloon


  • >1k berichten
  • 4810 berichten
  • VIP

Geplaatst op 20 juni 2009 - 15:13

Je kan ook gewoon gaan rekenen in een 220 tallig stelsel, daarna reken je dat om naar een binair getal en sla het zo op.

AA zou bv 1*220^1+1*220^0 = 221 zijn (deze kan je opslaan in 1 byte)
AAA dan weer 1*220^2+1*220^1+1*220^0 = 48621 (wat in 2 bytes kan, oorspronkelijk had je er 3 nodig)

#10

Gesp

    Gesp


  • >250 berichten
  • 339 berichten
  • Ervaren gebruiker

Geplaatst op 20 juni 2009 - 20:24

Je kan ook gewoon gaan rekenen in een 220 tallig stelsel, daarna reken je dat om naar een binair getal en sla het zo op.

AA zou bv 1*220^1+1*220^0 = 221 zijn (deze kan je opslaan in 1 byte)
AAA dan weer 1*220^2+1*220^1+1*220^0 = 48621 (wat in 2 bytes kan, oorspronkelijk had je er 3 nodig)

Dit is wat ik ook bedoelde. Het voorbeeld ziet er alleen gunstiger uit, omdat je de simpelste reeks van 3 tekens wilt opslaan, terwijl ik uitging van het ingewikkeldste. 219*220^2 + 219*220^1 + 219*220^0 = 10 647 999. Daar heb je wel degelijk 24 bits voor nodig, oftewel 3 byte, want 2^24=16 777 216.

#11

Cycloon

    Cycloon


  • >1k berichten
  • 4810 berichten
  • VIP

Geplaatst op 20 juni 2009 - 21:54

Ja ok, maar dat komt omdat er slechts 1 letter 'ruimte' is om de ~8.5 tekens. Als je dus telkens in het slechtste geval zit spaar je na 8.5 tekens wel 1 byte uit. In de betere gevallen kan je het vaak zelf al vroeger met 1 byte minder doen (maar alles hangt af van het meest beduidende teken).

#12

qrnlk

    qrnlk


  • >5k berichten
  • 5079 berichten
  • Lorentziaan

Geplaatst op 21 juni 2009 - 07:19

Je kunt nog verder gaan dacht ik. De letter "e" wordt vaker gebruikt dan de letter "q". Wellicht zou je kortere code kunnen gebruiken voor veel gebruikte letters en lagere codes voor zelden gebruikte letters? ( voorbeeld)
Any sufficiently analyzed magic is indistinguishable from science.
Any sufficiently advanced technology is indistinguishable from magic.

There is no theory of protecting content other than keeping secrets – Steve Jobs

#13

Cycloon

    Cycloon


  • >1k berichten
  • 4810 berichten
  • VIP

Geplaatst op 21 juni 2009 - 09:14

Je kan daar nauwelijks wat mee winnen hoor, maximaal 1 byte aan het begin.

#14

jadatis

    jadatis


  • >250 berichten
  • 347 berichten
  • Ervaren gebruiker

Geplaatst op 23 juni 2009 - 11:26

Wat Cycloon schrijft dat is het, met dat 220 tallig stelsel.
Van het getal dat in 55 bytes past rekent het kleine programmaatje dan alsvolgt.
X/220 dan getal voor de komma is de ASCI code van de eerste letter.
Trek dan 63x220 van X af en die met die rest herhaal je het vorige.
Met Excell zou je dit al kunnen doen.
Dan krijg je een lijst van 64 gehele getallen van 0 tot 219 die de tekens vertegenwoordigen.
Kan zijn dat het eerste 64 moet zijn, maar het gaat even om het idee.

Andersom laat ik aan de anderen over, van tekens naar dat ene getal toe rekenen.

Veranderd door jadatis, 23 juni 2009 - 11:31


#15

jadatis

    jadatis


  • >250 berichten
  • 347 berichten
  • Ervaren gebruiker

Geplaatst op 23 juni 2009 - 11:45

Ook zou je kunnen overwegen om een kleiner verlies op de koop toe te nemen. 32 tekens in 28 bytes( 0,5 bite verlies tov ideaal) of 16 tekens in 14 bytes( 0,25 byte verlies),wat het eindgetal een stuk kleiner maakt .
van die verloren ruimte kun je dan een begin en eindgetal toevoegen om de series van elkaar te scheiden.
Komt nog om de hoek kijken dat een computer maar met een bepaalde grootte getallen kan rekenen, dus wordt het te groot dan werkt het niet.
Ook het aantal cijfers achter de komma kan een probleem worden, maar dat kan opgevangen worden door de manier van steeds de hele getallen van elkaar af te trekken.

Veranderd door jadatis, 23 juni 2009 - 11:56






0 gebruiker(s) lezen dit onderwerp

0 leden, 0 bezoekers, 0 anonieme gebruikers

Ook adverteren op onze website? Lees hier meer!

Gesponsorde vacatures

Vacatures