sciencetalk

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?

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.

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.

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.

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.

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.

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.

Verplaatst naar programmeren.

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)

Cycloon schreef: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.

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).

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)

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

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.

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.