Informasjonsteori Skrevet av Joakim von Brandis, 18.09.200 1 Bits og bytes Fundamentalt for informasjonsteori er at all informasjon (signaler, lyd, bilde, dokumenter, tekst, etc) kan representeres som BIT = BInary digits, som hver har verdien 0 eller 1. Det gjør vi ved å la alle typer informasjon representeres ved symboler fra et visst sett av tegn. I dagens datamaskiner deler vi informasjon opp i bytes, som representeres ved åtte bit. Antall mulige tegn i et alfabet er tegn. Tabell 1 Symbol Tallverdi Binærverdi a 61 00111101 b 62 00111110... A 41 00101001 B 42 00101010... 0 0 00011110 1 1 00011111 2 2 00100000... På denne måten kan vi representere f.eks. teksten i dette dokumentet som en lang rekke bytes (hver byte på 8 bit), som tilsammen inneholder informasjonen i dette dokumentet. 2 Informasjon Når vi nå kan representere alt mulig ved hjelp av bits, så vil vi gjerne kunne sende denne informasjonen til andre, eller lagre informasjonen digitalt. Her melder det seg imidlertid et nytt behov; å sende data krever nettverkskapasitet, så vi er interessert i å sende minst mulig. Skal vi lagre på harddisk ønsker vi også at det skal ta så lite plass som mulig. Så istedet for bare ukritisk å lagre de binære data som dokumentet vårt utgjør, så kan vi se på informasjonen dokumentet inneholder. La oss først anta at vi har et litt mindre alfabet av mulige tegn: altså er " # tegn. 1
G D D Vi har en melding &%(')*%,+-*%(.)-/-/-/*%102 der alle tegn i meldingen er hentet fra alfabetet. Det samme kan vi skrive i matematisk notasjon slik: %154 Meldingen er 100 tegn lang, altså 7698:4,;</-/-/=5?>-; ; Tabell 2 Vi kan angi de 8 forskjellige tegnene med bit hver. Vi analyserer meldingen, 8 og @ angir hvor stor andel av tegnene i meldingen som består av tegnet. Dette skal vi bruke litt senere. Symbol Binærverdi @ A 000 0.5 ( >A) ) B 001 0.25 ( >ACB ) C 010 0.125 ( >A)# ) D 011 0.0125 ( >A)D ) E 100 0.0125 ( >A)D ) F 101 0.0125 ( >A)D ) G 110 0.015625 ( >A)ËB ) H 111 0.015625 ( >A)ËB ) Dersom vi sender meldingen med symboler fra, der tegnene er kodet med binærverdiene fra tabell 2 over, ville meldingen ta opp F HG. For en melding på 100 tegn blir det altså F?>-; ; DI D); ; bit.. Entropi Eksempel: Si at du har et dokument som inneholder 100.000 A er. Hvor mye informasjon inneholder det dokumentet? >-; ;J/K; ; ; For det første kan vi beskrive det dokumentet på langt mindre enn G bit ( bit dersom vi bruker alfabetet definert over) Bruker vi vanlige bytes for å gjengi dokumentet, kan vi si at setningen Dokumentet inneholder 100.000 A er, en streng på 4 tegn, dvs. 4 bytes, eller 272 bit, beskriver dokumentet nøyaktig Altså er det veldig mye redundant informasjon (dvs. informasjon som gjentas) i dokumentet. I virkeligheten er informasjonsinnholdet enda mye mindre. Ser vi på et vanlig dokument bestående av vanlig norsk tekst, ser vi at også der er det mye overflødig informasjon. Vi har satt av 8 bit til hvert tegn, men det er noen tegn som brukes mye mer enn andre, og noen tegn brukes ikke overhodet. For eksempel brukes e og a svært ofte i det norske språk, mens w og c brukes svært sjelden (bortsett fra å skrive ordet wc kanskje...) Da kan vi si at noen tegn inneholder mye 2
. @ F mer informasjon enn andre. Det kommer ikke som en overraskelse når det dukker opp en e i et ord, mens c er mye mer spesielt Kan vi bruke dette til å kode en melding mer effektivt enn i tabell 2? Dersom vi bruker et ulikt antall bit på de ulike symbolene, så kan vi forsøke å bruke få bit på de symbolene som opptrer ofte, og litt flere bit på de symbolene som opptrer sjeldnere. På denne måten kan vi få en lavere gjennomsnittlig bit-rate, siden de tegnene som opptrer ofte bruker færre bit, mens de tegnene som bruker flere bit ikke opptrer så ofte, og dermed heller ikke drar opp gjennomsnittet så mye. Derfor sier vi at jo oftere et symbol opptrer, jo mindre informasjon bærer det. Trukket til ytterpunktet får vi at når et symbol opptrer med sannsynlighet 1, så bærer det ingen informasjon Tenk på det slik: dersom vi på forhånd vet at noe skal skje, så er det ikke mye informasjon i å opplyse at det har skjedd (Ser du ut av vinduet fra hybelen din i Trondheim en mandag morgen og oppdager at det regner, så inneholder ikke den opplysningen mye informasjon... det gjør jo stort sett det her i byen...;) Formel 1 Målet på informasjonsinnhold kalles entropi, og defineres formelt: 9L NM FPOQ.SR UT bit 76V8:4 der @ 8 er sannsynligheten for at et tegn er symbolet. Dette forutsetter at hvert tegn er uavhengig av andre tegn. 8 Altså; for hvert symbol har vi at entropien for symbolet er gitt ved 2-logaritmen av @, med negativt fortegn. For å regne ut, så husker vi fra matematikken at. RXW TY F = RXW T = RST Merk også at dersom et symbol opptrer med sannsynlighet nær 0, så vil et slikt symbol inneholde svært mye informasjon Altså kan vi måle informasjonsinnholdet i et symbol 8 ut fra @ Ser vi på meldingen og alfabetet, kan vi regne ut hvor mye informasjon hvert tegn representerer, dersom vi kjenner @ 8 for hvert symbol. Tips:@ (for denne spesifikke meldingen) kan vi regne ut ved å telle antall forekomster av hvert tegn i meldingen. I tabell 2 over har vi angitt verdien av @ for hvert tegn. Denne angir at i meldingen vår utgjør A en andel på 0.5 av alle tegnene, B en andel på 0.125 etc. Vi har da at f.eks. [Z\?M FXOCQ.SR >A)ST]?> bit
n o o o poo w @ v v vv Altså er informasjonsinnholdet i symbolet A bare på 1 bit Til sammenlikning er ^_?M. R >A)ËB T` Et symbol H bærer 6 ganger så mye informasjon som et symbol A i denne meldingen Videre kan vi finne ut hva det gjennomsnittlige informasjonsinnholdet per tegn i meldingen er. bit Formel 2 Gjennomsnittlig informasjonsinnhold per tegn er gitt som der @ er som før. [abced*afc< gmih Med andre ord er gjennomsnittlig entropi lik summen av entropien multiplisert med sannsynligheten, for hvert symbol i alfabetet. @.SR jt Regner vi ut akbkcldmakfkc for meldingen vår får vi at akbkced*akfkc NM >A)rq.SR >A)ST s >ACBIq.SR >ACB T s >A)#q. R >A)#ST s DtqS>A)D rq.sr >A)D ST stqs>a)ëb"q.sr >A)ËB T ukv x/k;sdj>& bit/tegn Vi skal altså ideelt klare å få ned plassforbruket til gjennomsnittlig 2.0 bit per tegn, altså 20 bit for vår melding. Husk at med like mange bit per symbol klarer vi ikke komme under bit per symbol, når vårt alfabet har 8 symboler. Klarer vi å finne en kode som gjennomsnittlig bruker mindre enn bit per tegn da? Ifølge vår utregning inneholder symbolet A 1 bit med informasjon, mens symbolet H inneholder 6. Vi lar disse tallene være et hint om hvor mange bit vi skal representere symbolene med. Samtidig er det viktig at bit-mønstrene vi representerer ulike symboler med, er unike (er ikke symbolet entydig gitt ved bitmønsteret, vil det bli umulig å gjenvinne meldingen). For å finne det rette bitmønsteret for hvert symbol, bruker vi Huffman-algoritmen. Resultatet er treet vist i figur 1. 1. La alle symboler være noder (sammenknytningspunkter). Disse skal vi koble sammen som vist i figur 1. 2. Velg to foreldreløse noder med lavest sannsynlighet (@ ).. Lag en foreldrenode til disse to nodene 4. Gi denne noden sannsynlighet lik summen til de to barna. 5. Gjenta fra punkt 2 helt til kun en foreldreløs node gjenstår Deretter gir hver nodene på første barnenivå en-bits koder, nodene på neste nivå tobits koder, tre-bits koder på tredje nivå, etc, og ender opp med bit-koding av hver node 4
y F G % % 0 A 1 00 B 01 000 C 001 0000 0001 00000 D 00001 E 00010 F 00011 G 000000 H 000001 Figur 1: Bitmønster for tegnene i vårt alfabet som vist i figur 1. (Merk: topp-noden representerer ikke noe valg, og får derfor ikke noe bit) Vi foreslår dermed en bit-koding av hvert tegn (bit-kodingen leser vi ut fra treet): Tabell 8 Symbol Bit-kode A 1 B 01 C 001 D 00001 E 00010 F 00011 G 000000 H 000001 Legg merke til at bit-kodene for symbolene er unike Vi kan også se at en bit-streng som begynner med 1 er en A, siden alle andre symboler begynner med 0. Og du vet at en bit-streng 01 er en B, siden alle symboler (bortsett fra A) begynner med 00, osv. Altså er hvert symbol entydig gitt ved bit-kodingen. Med denne bit-kodingen og @ som gitt i tabell 2 over, kan vi regne ut antall bit for : denne meldingen F, ved hjelp av gjennomsnittlig bit-lengde per tegn; y % R >A)q >T s R >ACB"qST s R >A)#rqCDST s R Dqz>A)D rq ST s Rqz>A)ËBq STY x/k;sdj>&?>-; ; xg{y x/k;sdj>& );SD bit 5
G abced*afc Vi regnet ut for vår melding, som angir det gjennomsnittlige informasjonsinnholdet per bit. Dette er den teoretisk sett laveste gjennomsnittlige bit-lengden per tegn som er mulig uten å miste informasjon. Siden akbkced*akfkc Gg x/k;sdj>& >-; ;} );SD bit, ser vi det ikke er mulig å kode meldingen mer effektivt enn dette (Dette gjelder så lenge forutsetningene om uavhengighet mellom symbolene stemmer. Se neste avsnitt for mer om dette). 4 Komprimering av bilder, video og lyd Under forutsetningene listet opp i formel 1, kan vi altså nøyaktig angi informasjonsinnholdet i en melding, og derav finne den mest effektive kodingen av denne meldingen, uten at vi taper noe informasjon. Mye av det som idag skal lagres og sendes på nettet, er multimedia-dokumenter, altså bilder, lyd og video. Disse kodes også med koder for å gjøre dem minst mulig. Men her er det mulig å finne en mer effektiv koding enn den skissert over. Husk at i formel 1 forutsetter vi at tegnene i meldingen er uavhengige. I bilder, lyd og video er ikke dette lenger sant To bildepunkter som ligger ved siden av hverandre, har en ganske stor sannsynlighet for å være like, eventuelt ha en veldig liten forskjell. Det er altså en viss avhengighet mellom punkter som ligger nær hverandre, og denne ekstra redundante informasjonen kan utnyttes for å kode dokument enda mer effektivt. I et lydspor er det derimot avhengighet i tid, som kan utnyttes for å komprimere lyden bedre. I video er det avhengighet både i rom og tid, som åpner for at video kan komprimeres forholdsmessig langt mer enn både lyd og stillbilde. (Men så er jo videofiler også mye større i utgangspunktet...) Likevel, selv med en slik koding er informasjonsinnholdet i en fullkvalitets videofil enormt, og alle moderne kodingsformater for lyd og bilde innebærer et visst tap av informasjon. Dermed kan man komme godt under den nedre grensen for gjennomsnittlig bit-rate, fordi man faktisk utelater endel informasjon. Denne informasjonen kan ikke rekonstrueres, men med litt intelligente kodingssystemer, velges den informasjonen som tas bort slik at det merkes minst mulig. k 5 Oppsummering Hovedpunktene er altså Vi kan se på det faktiske informasjonsinnholdet per tegn i en melding Informasjonsinnhold kalles entropi og måles i bit/tegn Entropien gir en nedre grense for hvor effektiv en melding kan kodes uten tap 6
For multimediafiler kan vi utnytte ekstra redundans i rom og tid, og dermed kode enda mer effektivt Multimediafiler kodes generelt til en bit-rate under dokumentets faktiske entropi Dette betyr at vi isåfall taper informasjon, som vi ikke kan få tilbake Den informasjonen som tapes må velges slik at brukeren merker minst mulig 7