---

Hej.

Er der nogen sammenhæng mellem et tals cifre i to forskellige talsystemer.
F.eks. hvis jeg har et tal i tre-talssystemet og i binært - vil jeg kunne
finde et af cifrene i den ene representation ved at se på cifrene i den
anden?

Min idé er at man kunne lave et computerprogram der kan "pakke" tallister,
hvor det er kendt at tallene er i et bestemt interval. F.eks. har man tal i
intervallet [0-122]. Disse kan forståes som cifre i et (stort) tal i et
123-talssystem. Hvis man regner dette tal ud binært har man det data man kan
gemme i en fil. Det var teorien. Nu kommer så det praktiske. For hvis jeg
åbner en af mine data-filer (og man kan læse et antal bytes ind ad gangen),
vil jeg være i stand til at opbygge min talrække i korrekt rækkefølge?
Det må jo forudsætte at information om tallene i talrækken (i den binære
representation - filen) ligger fra bit 0-a, a-b, b-c, etc.

Hvis man f.eks. ser på det hexedecimale talssystem og det binære er der jo
en klar sammenhæng: Det skal fire bits til et hexedecimalt ciffer. Det er jo
logisk eftersom 2^4 = 16. Men når man har to talsystemer, der ikke har samme
fællesnævner, f.eks. 123 og 2, så skal der måske ln(123)/ln(2) = 6,94 bits
til ét ciffer. Det bliver jo blot bøvlet eftersom man ikke kan dele en bit
op. Men måske der stadig er en sammenhæng? Det kunne jo tænkes at det første
ciffer ligger fra bit 0-6, det næste fra bit 6-13, 13-20, etc. Men hvordan
man rent faktisk dekoder cifferet fra bit 13-20, kan jeg ikke regne ud. Om
det overhovedet forholder sig sådan, er jeg i tvivl om.

Håber nogen kan hjælpe mig med mine spørgsmål. På forhånd tak!

Mvh.
Bjarke

---

"Bjarke Walling Petersen" <bwp@bwp.dk> skrev i en meddelelse news:41650b1f$0$248$edfadb0f@dread12.news.tele.dk...
>
> Er der nogen sammenhæng mellem et tals cifre i to forskellige talsystemer.
> F.eks. hvis jeg har et tal i tre-talssystemet og i binært - vil jeg kunne
> finde et af cifrene i den ene representation ved at se på cifrene i den
> anden?

Ja?

> Min idé er at man kunne lave et computerprogram der kan "pakke" tallister,
> hvor det er kendt at tallene er i et bestemt interval. F.eks. har man tal i
> intervallet [0-122].

Det "normale" ville være at afsætte et passende antal bytes (1 i dit tilfælde).

Mvh
Martin

---

Martin Larsen <mlarsen@post7.tele.dk> skrev:
>> Er der nogen sammenhæng mellem et tals cifre i to forskellige
>> talsystemer.
>> F.eks. hvis jeg har et tal i tre-talssystemet og i binært - vil jeg kunne
>> finde et af cifrene i den ene representation ved at se på cifrene i den
>> anden?
>
> Ja?

Okay, hvilken?

>> Min idé er at man kunne lave et computerprogram der kan "pakke"
>> tallister,
>> hvor det er kendt at tallene er i et bestemt interval. F.eks. har man tal
>> i
>> intervallet [0-122].
>
> Det "normale" ville være at afsætte et passende antal bytes (1 i dit
> tilfælde).

Ja, jeg ved godt at det er normalt og måske den bedste måde, hvis man
hurtigt vil læse tallene. Men hvordan gør jeg det andet?
Der er jo ingen udfordring i at gemme ét tal pr. et bestemt antal bits, vel?


Mvh.
Bjarke

---

On Thu, 7 Oct 2004 11:23:43 +0200 Bjarke Walling Petersen wrote:

> en klar sammenhæng: Det skal fire bits til et hexedecimalt ciffer. Det er jo
> logisk eftersom 2^4 = 16. Men når man har to talsystemer, der ikke har samme
> fællesnævner, f.eks. 123 og 2, så skal der måske ln(123)/ln(2) = 6,94 bits
> til ét ciffer. Det bliver jo blot bøvlet eftersom man ikke kan dele en bit
> op.

Det kan man vel godt. Hvis vi nu siger at vi vil gemme to tal A og B i
området [0;4], kan vi jo bare gemme dem som 5*A+B, hvilket kun kræver 5
bit.

--
41 6E 64 65 72 73

---

Anders Bo Rasmussen <fuzz01@spamfilter.dk> skrev:
> Det kan man vel godt. Hvis vi nu siger at vi vil gemme to tal A og B i
> området [0;4], kan vi jo bare gemme dem som 5*A+B, hvilket kun kræver 5
> bit.

Jo, det er jeg helt med på. Det er også det jeg vil. Problemet opstår først
når man vil gemme, lad os sige, 1000 tal i området [0-4]. Man kan hurtigt
regne ud at det vil fylde ceil(ln(5)/ln(2)*1000/8) = 291 bytes, men hvad
sammenhængen mellem de bytes og de reele tal er, kan jeg ikke regne ud. Det
vil kræve alt for meget at regne hele tallet ud og efterfølgende gemme det
binært. Det vil være nemmere hvis man kunne regne f.eks. en bytes ud ad
gangen. Og også omvendt at konvertere en byte til de cifre, der ligger i det
område. Ja, såfremt at cifrene overhovedet ligger efter hinanden i andre
tal-representationer.

Mvh.
Bjarke

---

Bjarke Walling Petersen wrote:
> Min idé er at man kunne lave et computerprogram der kan "pakke" tallister,
> hvor det er kendt at tallene er i et bestemt interval. F.eks. har man tal
> i intervallet [0-122]. Disse kan forståes som cifre i et (stort) tal i et
> 123-talssystem.

Det lyder lidt som om du forsøger at genopfinde aritmetisk kompression.
http://www.eee.bham.ac.uk/WoolleySI/All7/arith_1.htm

> Det kunne jo tænkes at det første ciffer ligger fra bit 0-6, det næste
> fra bit 6-13, 13-20, etc. Men hvordan man rent faktisk dekoder cifferet
> fra bit 13-20, kan jeg ikke regne ud.

Du kan tænke på det første ciffer som et interval, nemmeligt alle de tal
der har starter med det ciffer, efterfulgt af alle mulige andre sekvenser
af cifre, f.eks. er 0.1xxxxx (i 10talssystemet) = [0.1:0.2[. Det andet
ciffer som et delinterval af det første, og så videre. F.eks. er 0.12xxxx
delintervallet [0.12:0.13[.

(du kan antage at alle symboler/tal har lige store intervaller for
at holde det simpelt. Men dette slet ikke nødvendigt, og udgør tricket
bag aritmetisk kompression.)

Hvis du entydigt vil identificere det første ciffer, så skal du indlæse
nok bits til at du ved at tallet ligger i det tilsvarende del interval.
Du kan så gentage processen med det andet delinterval (det andet ciffer),
osv.

Men du kan ikke få decimal 2 ud uden først at havde fået decimal 1, med
mindre der går et helt antal bits per ciffer.

N.b. for at implementerer det er det praktisk at efter hvert ciffer er
identificeret så at lave en scaling transformation, der transformere
delintervallet til [0:1].

F.eks. med a=[0.0:0.1[ og b=[0.1:1] (tallene er i binær), så svarer
enhver sekvens af a og b cifre til et interval mellem 0 og 1. Og du kan
hurtigt udregne hvilket interval der svarer til sekvensn ababbxxxxx.
Når du dekoder så hver gang du læser et a, kan du blot gange interval
grænserne med 2 for at komme til [0:1], mens har du læst b så er det
grænserne (x-0.1)*2.

Samme princip kan anvendes hvis du har flere decimaler. Derved kan du
finde det N'te ciffer, uden at huske de N-1 foregående cifre.

--
Mvh. Carsten Svaneborg
http://www.softwarepatenter.dk

---

Carsten Svaneborg <zqex@sted.i.tyskland.de> skrev:
> Det lyder lidt som om du forsøger at genopfinde aritmetisk kompression.
> http://www.eee.bham.ac.uk/WoolleySI/All7/arith_1.htm

Ah, det ser spændende ud. Det er en lidt anden tilgang til problemet, end
jeg havde.

[klip]
> Hvis du entydigt vil identificere det første ciffer, så skal du indlæse
> nok bits til at du ved at tallet ligger i det tilsvarende del interval.
> Du kan så gentage processen med det andet delinterval (det andet ciffer),
> osv.

Hvis jeg har fem tal i ti-talssystemet (3, 4, 1, 7, 2) kan dette skrives om
til tallet 0,34172. Dette tal omregnes nu til binært og her skal jeg tage
nok bits med til at nøjagtigheden er stor nok - dette antal vil være
log(base)/log(2)*N. Har jeg forstået det korrekt?

Men det er stadig ikke helt problemløst. Lad os sige jeg har cifre i et
5-talssystem - tre cifre (a_0, a_1 og a_2). Hvis disse skal gemmes i bits
b_x, så må der gælde følgende:

a_0/5 + a_1/5^2 + a_2/5^3 = b_0/2 + b_1/2^2 + b_2/2^3 + b_3/2^4 + b_4/2^5 +
b_5/2^5 + ...

Hvis a_0=4 så er der ingen tvivl om at a_1 og a_2 ikke kan ændre på det
faktum at b_0=1, da 4/5 > 1/2. Problemet opstår hvis f.eks. a_0=2. Her vil
a_1 og evt. a_2 få betydning for værdien af b_0. Dette er ikke særlig godt i
den process hvor du er ved at kode dine cifre til binært. Men måske det kan
løses?

Det er straks nemmere, når man skal læse cifrene ind igen - her havde du
beskrevet en metode. Det forudsætter selvfølgelig at du læser din fil fra
starten, men det er ikke noget problem.

Mvh.
Bjarke

---

"Bjarke Walling Petersen" <bwp@bwp.dk> writes:

> Hej.
>
> Er der nogen sammenhæng mellem et tals cifre i to forskellige talsystemer.
> F.eks. hvis jeg har et tal i tre-talssystemet og i binært - vil jeg kunne
> finde et af cifrene i den ene representation ved at se på cifrene i den
> anden?
>
> Min idé er at man kunne lave et computerprogram der kan "pakke" tallister,
> hvor det er kendt at tallene er i et bestemt interval. F.eks. har man tal i
> intervallet [0-122]. Disse kan forståes som cifre i et (stort) tal i et
> 123-talssystem. Hvis man regner dette tal ud binært har man det data man kan
> gemme i en fil. Det var teorien. Nu kommer så det praktiske. For hvis jeg
> åbner en af mine data-filer (og man kan læse et antal bytes ind ad gangen),
> vil jeg være i stand til at opbygge min talrække i korrekt rækkefølge?
> Det må jo forudsætte at information om tallene i talrækken (i den binære
> representation - filen) ligger fra bit 0-a, a-b, b-c, etc.

Jeg støtter Carsten Svaneborg's forslag om at se på aritmetisk
kodning, men den kan også klares med heltal uden at bruge reelle tal
(som er normen i aritmetisk kodning).

Hvis du har en række tal x0,...,xn, som hver ligger i intervallet
0..(b-1), så kan du konvertere talrækken til et enkelt heltal T =
x0+b*(x1+b*(x2+...b*xn)), eller med andre ord T =
x0+b*x1+b^2*x2+...+b^n*xn. Du kan finde xi fra T som (T/(b^i)) mod b.

Hvis b er en potens af to, kan man både dividere med b^i og finde
divisionsresten med b bare ved at udtrække bit, så det er nemt og
effektivt. Men hvis man f.eks. skal dividere med 3^i eller finde rest
med 3, så kan man blive nødt til at se på alle bits i tallet, da
ethvert bit kan have betydning for begge tal.

> Hvis man f.eks. ser på det hexedecimale talssystem og det binære er der jo
> en klar sammenhæng: Det skal fire bits til et hexedecimalt ciffer. Det er jo
> logisk eftersom 2^4 = 16. Men når man har to talsystemer, der ikke har samme
> fællesnævner, f.eks. 123 og 2, så skal der måske ln(123)/ln(2) = 6,94 bits
> til ét ciffer. Det bliver jo blot bøvlet eftersom man ikke kan dele en bit
> op. Men måske der stadig er en sammenhæng? Det kunne jo tænkes at det første
> ciffer ligger fra bit 0-6, det næste fra bit 6-13, 13-20, etc. Men hvordan
> man rent faktisk dekoder cifferet fra bit 13-20, kan jeg ikke regne ud. Om
> det overhovedet forholder sig sådan, er jeg i tvivl om.

Som nævnt, kan man ikke nøjes med at se på et lille interval af bits,
med mindre basen er en potens af to. Hvis man vil begrænse antallet
af bits, man vil se på, kan man runde basen op til en toerpotens. I
dit eksempel med basen 123, kan man runde op til 128, så man bruger
eksakt 7 bits per "ciffer". Spildet fra 6,94 til 7 er ikke så stort
(mindre end 1%), så det vil ofte være acceptabelt. Værre er det hvis
basen ligger lige over en toerpotens, f.eks. 129. En oprunding fra
lidt over 7 bits til 8 bits per ciffer giver et spild på 14%, hvilket
er betragteligt større end før. Men så kan man prøve at pakke to
eller flere cifre sammen i et helt antal bits. 129^2 = 16641 kan
ligge i 15 bits, så spildet er allerede nu kun 7%. 129^3 = 2146689
kan ligge i 22 bits, så spildet er nu nede på 4.6%. Ved at pakke
flere cifre sammen, kan man bringe spildet vilkårligt langt ned, men
udpakningen bliver tilsvarende dyrere, da man også øger antallet af
bit, man skal behandle for at finde cifret. De mindste spild findes
ved antal cifre n, hvor n*log(base)/log(2) ligger lige under et
heltal.

   Torben

---

Torben Ægidius Mogensen <torbenm@diku.dk> skrev:
> Hvis du har en række tal x0,...,xn, som hver ligger i intervallet
> 0..(b-1), så kan du konvertere talrækken til et enkelt heltal T =
> x0+b*(x1+b*(x2+...b*xn)), eller med andre ord T =
> x0+b*x1+b^2*x2+...+b^n*xn. Du kan finde xi fra T som (T/(b^i)) mod b.

Det er også sådan jeg først tænkte det. Lidt i modsætning til aritmetisk
kodning, hvor mit tal er x_0/b+x_1/b^2+...+x_n/b^n (sådan som jeg har
forstået det). Jeg kan ikke umiddelbart se om der er nogen sammenhæng mellem
aritmetisk kodning eller den anden form. Hvis man f.eks. regnede cifrene i
et tal om til binært ved at udregne T (jævnfør din formel) eller aritmetisk
kodning. Ville man opnå de samme bits?

> Hvis b er en potens af to, kan man både dividere med b^i og finde
> divisionsresten med b bare ved at udtrække bit, så det er nemt og
> effektivt. Men hvis man f.eks. skal dividere med 3^i eller finde rest
> med 3, så kan man blive nødt til at se på alle bits i tallet, da
> ethvert bit kan have betydning for begge tal.

Ja, det var lidt den sidste erkendelse jeg manglede - at ethvert bit kan
have betydning for et ciffer, når basen ikke er 2.

Men det undrer mig dog lidt at det ikke er muligt at læse cifferne ind ét
efter ét fra ens binære fil, når man bruger denne heltalsmetode, men det er
ved aritmetisk kodning. Eller har jeg ikke ret i det?

> Som nævnt, kan man ikke nøjes med at se på et lille interval af bits,
> med mindre basen er en potens af to. Hvis man vil begrænse antallet
> af bits, man vil se på, kan man runde basen op til en toerpotens.
[klip]

Ja, den metode har jeg også tænkt lidt på - og den kan jeg også rimelig nemt
finde ud af at implementere for et begrænset antal cifre. Indtil jeg skrev
mit første indlæg har jeg dog grublet over om det er den eneste metode der
var at bruge. Det lader dog til at det kan lade sig gøre med aritmetisk
kodning. Nu må jeg lige se lidt nærmere på det. Jeg synes det er "sjovere"
at pakke alle cifferne sammen i ét tal, hvis du forstår - dvs. den mest
pakkede form.

Mvh.
Bjarke

---

"Bjarke Walling Petersen" <bwp@bwp.dk> writes:

> Er der nogen sammenhæng mellem et tals cifre i to forskellige talsystemer.
> F.eks. hvis jeg har et tal i tre-talssystemet og i binært - vil jeg kunne
> finde et af cifrene i den ene representation ved at se på cifrene i den
> anden?

Jeg faldt lige i anden sammenhæng over denne pdf-fil som et stykke
inde forklarer Base85 ganske grundigt. Det er sikker noget i den stil du
leder efter.
http://www.morello.co.uk/binaryencoding.pdf

Eller du kan se på afsnit 5 i
http://www.faqs.org/rfcs/rfc1924.html

--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Vadgårdsvej 3, 2.tv. | /,`.-´` -. ;:-. | Jeopardy.
2860 Søborg | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Tlf: 39 56 24 37 | '---''(_/--' `-'\_) | spørgsmålet.

---

Kim Hansen <k-spam2003@oek.dk> skrev:
> Jeg faldt lige i anden sammenhæng over denne pdf-fil som et stykke
> inde forklarer Base85 ganske grundigt. Det er sikker noget i den stil du
> leder efter.
> http://www.morello.co.uk/binaryencoding.pdf
>
> Eller du kan se på afsnit 5 i
> http://www.faqs.org/rfcs/rfc1924.html

Tak. Du har ret - det er et stykke af vejen. Men det er mere den generelle
kodningsmetode jeg søger end et specialtilfælde - her Base85, hvor de altid
koder 5 cifre ad gangen. Jeg ønsker at kode et vilkårligt antal cifre.

Men tak for dit svar alligevel!

Mvh.
Bjarke

---

"Bjarke Walling Petersen" <bwp@bwp.dk> writes:

> Tak. Du har ret - det er et stykke af vejen. Men det er mere den generelle
> kodningsmetode jeg søger end et specialtilfælde - her Base85, hvor de altid
> koder 5 cifre ad gangen. Jeg ønsker at kode et vilkårligt antal cifre.

Ok, jeg havde bare bidt mærke i dit base123 eksempel uden rigtig at
læse dit spørgsmål ordentligt.

Jeg ved ikke helt om dette her er foreslået endnu. I dit
base123-eksempel kunne du gøre det at du læste de første 6 bit som
binært og derefter så på tallet om det var så stort at der ikke var
brug for den 7. bit. Det ville give et forbrug på:
0-59 7 bit
60-63 6 bit
64-123 7 bit
124-127 findes ikke

Fordelen ved dette frem for de store gangestykker er at man undgår
gange og divider, til gengæld er der en del bit-fedteri og valg som
måske gør det ineffektivt.

Bliver denne metode brugt i nogen kendte formater?

--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Vadgårdsvej 3, 2.tv. | /,`.-´` -. ;:-. | Jeopardy.
2860 Søborg | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Tlf: 39 56 24 37 | '---''(_/--' `-'\_) | spørgsmålet.

---

Kim Hansen <k-spam2003@oek.dk> skrev:
> Ok, jeg havde bare bidt mærke i dit base123 eksempel uden rigtig at
> læse dit spørgsmål ordentligt.

Det er i orden.

> Jeg ved ikke helt om dette her er foreslået endnu. I dit
> base123-eksempel kunne du gøre det at du læste de første 6 bit som
> binært og derefter så på tallet om det var så stort at der ikke var
> brug for den 7. bit. Det ville give et forbrug på:
> 0-59 7 bit
> 60-63 6 bit
> 64-123 7 bit
> 124-127 findes ikke
[klip]

Selvom det ikke har noget med at konvertere mellem talsystemer, lyder det
alligevel lidt spændende. Men sådan som jeg forstår den virker metoden
desværre ikke. F.eks. hvis jeg har et tal, lad os sige 120 og koder dette
binært. Herved får jeg 7 bits: 1111000. Når jeg dekoder det vil jeg læse de
første 6 bits og her får jeg tallet 60 - og jeg skal ifølge tabellen ikke
læse den 7. bit. Har jeg forstået det forkert?

Mvh.
Bjarke

---

"Bjarke Walling Petersen" <bwp@bwp.dk> writes:

> Kim Hansen <k-spam2003@oek.dk> skrev:
> > Ok, jeg havde bare bidt mærke i dit base123 eksempel uden rigtig at
> > læse dit spørgsmål ordentligt.
>
> Det er i orden.
>
> > Jeg ved ikke helt om dette her er foreslået endnu. I dit
> > base123-eksempel kunne du gøre det at du læste de første 6 bit som
> > binært og derefter så på tallet om det var så stort at der ikke var
> > brug for den 7. bit. Det ville give et forbrug på:
> > 0-59 7 bit
> > 60-63 6 bit
> > 64-123 7 bit
> > 124-127 findes ikke
> [klip]
>
> Selvom det ikke har noget med at konvertere mellem talsystemer, lyder det
> alligevel lidt spændende. Men sådan som jeg forstår den virker metoden

Det jeg har beskrevet er en konvereting mellem 2-talssytemet og
123-talssystemet, og det kan uden de store problemer laves til en
generel omskrivning mellem 2-talssystemet til N-talssystemet. Jeg kan
ikke lige overskue om det kan udvides til at være helt generelt, men
det har jeg ikke haft brug for.

> desværre ikke. F.eks. hvis jeg har et tal, lad os sige 120 og koder dette
> binært. Herved får jeg 7 bits: 1111000. Når jeg dekoder det vil jeg læse de
> første 6 bits og her får jeg tallet 60 - og jeg skal ifølge tabellen ikke
> læse den 7. bit. Har jeg forstået det forkert?

Ja, du skal læse tallet fra den anden ende, så de første 6 bits er
tallet 111000, dvs. 56 som derfor skal have en ekstra bit med der
viser at tallet var 120.

60 kodes som 111100, som dekodes til 60 der ikke skal bruge den
7. bit.

Besparelsen ved metoden er ret lav når man regner i 123-talssystemet,
men afprøv det med 65-talssystemet så ser regnskabet straks bedre ud.

--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Vadgårdsvej 3, 2.tv. | /,`.-´` -. ;:-. | Jeopardy.
2860 Søborg | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Tlf: 39 56 24 37 | '---''(_/--' `-'\_) | spørgsmålet.

---

Kim Hansen <k-spam2003@oek.dk> writes:

> Jeg ved ikke helt om dette her er foreslået endnu. I dit
> base123-eksempel kunne du gøre det at du læste de første 6 bit som
> binært og derefter så på tallet om det var så stort at der ikke var
> brug for den 7. bit. Det ville give et forbrug på:
> 0-59 7 bit
> 60-63 6 bit
> 64-123 7 bit
> 124-127 findes ikke
>
> Fordelen ved dette frem for de store gangestykker er at man undgår
> gange og divider, til gengæld er der en del bit-fedteri og valg som
> måske gør det ineffektivt.
>
> Bliver denne metode brugt i nogen kendte formater?

Efter at have kigget på det lidt mere så kan jeg se at det er en
simpel Huffman kodning med det fladest mulige træ.

--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Vadgårdsvej 3, 2.tv. | /,`.-´` -. ;:-. | Jeopardy.
2860 Søborg | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Tlf: 39 56 24 37 | '---''(_/--' `-'\_) | spørgsmålet.

---

Bjarke Walling Petersen wrote:

> Er der nogen sammenhæng mellem et tals cifre i to forskellige talsystemer.
> F.eks. hvis jeg har et tal i tre-talssystemet og i binært - vil jeg kunne
> finde et af cifrene i den ene representation ved at se på cifrene i den
> anden?

Forslaget med aritmetisk kompression lyder spændede. En mere jordnær
tilgang ville være at se på algoritmer, der omregner fra en basis til
en anden.

På engelsk hedder basisomregnen "radix conversion". Hvis du har en Knuth
i nærheden så find afsnit 4.4. i andet bind.

På nettet var det første nogenlunde brugbare jeg kunne finde:
<http://www.cut-the-knot.org/recurrence/conversion.shtml>

--
Jens Axel Søgaard

---

Jens Axel Søgaard <usenet@soegaard.net> skrev:
> Forslaget med aritmetisk kompression lyder spændede. En mere jordnær
> tilgang ville være at se på algoritmer, der omregner fra en basis til
> en anden.
>
> På engelsk hedder basisomregnen "radix conversion". Hvis du har en Knuth
> i nærheden så find afsnit 4.4. i andet bind.
>
> På nettet var det første nogenlunde brugbare jeg kunne finde:
> <http://www.cut-the-knot.org/recurrence/conversion.shtml>

Jeg kan godt regne mellem forskellige talsystemer eller baser om man vil.
Problematikken er mest omkring det at omregne mange tal fra en base til en
anden. Hvis du f.eks. har 1000 cifre i et tal med base 5 vil det største tal
du kan frembringe indeholde 2322 cifre i en binær representation. Hvis det
er et alm. program på en pc man taler om vil en normal heltalsvariabel kunne
indeholde et sted mellem 32 og 64 bits. Så jeg kan ikke fortage
konverteringen i ét skridt. Jeg efterlyser altså en anden metode, hvor der
foretages en konvertering mellem base X og base 2 (og den anden vej, når man
læser data ind igen) - og denne metode må ikke kræve at man kan have hele
tallet (dvs. hele filen) i én variabel.

Men jeg vil kigge lidt mere på aritmetisk kodning. Det vil måske løse det.

Mvh.
Bjarke

---

"Bjarke Walling Petersen" <bwp@bwp.dk> writes:


> Jeg kan godt regne mellem forskellige talsystemer eller baser om man vil.
> Problematikken er mest omkring det at omregne mange tal fra en base til en
> anden. Hvis du f.eks. har 1000 cifre i et tal med base 5 vil det største tal
> du kan frembringe indeholde 2322 cifre i en binær representation. Hvis det
> er et alm. program på en pc man taler om vil en normal heltalsvariabel kunne
> indeholde et sted mellem 32 og 64 bits.

Det afhænger af, hvilket sprog man bruger til at lave sine programmer
i. Der er sprog (som f.eks. Scheme
(http://www.swiss.ai.mit.edu/projects/scheme/) og Haskell
(http://www.haskell.org/)), hvor heltals størrelse kun er begrænset af
lagerkapaciteten. Man kan også lave pakker til store heltal i sprog
som C eller Basic, men det er noget besværligere at regne med.

   Torben

---

Bjarke Walling Petersen wrote:
>
> Er der nogen sammenhæng mellem et tals cifre i to forskellige talsystemer.
[...]
> Hvis man f.eks. ser på det hexedecimale talssystem og det binære er der jo
> en klar sammenhæng: Det skal fire bits til et hexedecimalt ciffer. Det er jo
> logisk eftersom 2^4 = 16.

Jeg er ikke helt sikker på om jeg forstår spørgsmålet.

Hvis vi har et reelt tal x, kan det udvikles efter to forskellige
grundtal (baser) b og c (hvor b og c er naturlige tal over 1).

Spørgsmålet er vist om kendskab alene til et ciffer eller en lille blok
af cifre »langt inde« i tallet x udviklet efter grundtal b giver kend-
skab til et ciffer i x udviklet efter grundtal c. Jeg tror nok svaret er
nej.

Hvis du fx vidste at cifrene nr. 1.000.000.000 til 1.000.000.005 i
tallet pi udviklet decimalt (b=10) var »739024« (fiktivt eksempel),
så tror jeg ikke du kunne bruge dét til at finde et eneste ciffer
(en eneste bit) i den binære udvikling af pi med (c=2).

Som du selv er inde på, findes der særlige tilfælde hvor man godt kan.
Dit eget eksempel kan i det mindste generaliseres til at hvis der
findes naturlige tal k og j sådan at

b^k = c^j

så virker det. For eksempel kan man omregne mellem b=216 og c=36 fordi
216²=36³. Så to cifre i det ene system svarer på simpel måde til tre
cifre i det andet, i dette eksempel.

--
Jeppe Stig Nielsen <URL:http://jeppesn.dk/>. «

"Je n'ai pas eu besoin de cette hypothèse (I had no need of that
hypothesis)" --- Laplace (1749-1827)

---

Jeppe Stig Nielsen <mail@jeppesn.dk> skrev:
[klip]
> Hvis du fx vidste at cifrene nr. 1.000.000.000 til 1.000.000.005 i
> tallet pi udviklet decimalt (b=10) var »739024« (fiktivt eksempel),
> så tror jeg ikke du kunne bruge dét til at finde et eneste ciffer
> (en eneste bit) i den binære udvikling af pi med (c=2).

Ja, det var en god formulering. Hvorfor forholder det sig således? Hvordan
kan det være at der ikke er denne sammenhæng? Nu har flere indlæg bekræftet
at ovenstående gælder - at der ikke er nogen sammenhæng i cifrene undtaget
nogle specialtilfælde du selv er inde på nedenfor (og som jeg også skrev
kort om).

MEN jeg tror nu at ovenstående analogi ikke holder helt. Du glemmer nemlig
at jeg på forhånd har læst de første 999.999.999 cifre af pi og har fundet
de x første cifre af pi i binært (og opdateret mine registre som det nu er
passende i mit program). Og nu er jeg altså kommet til ciffer 1.000.000.000.
Kan jeg så finde det næste binære ciffer af pi? Kan jeg konstruere mit
program på en måde så det kan lade sig gøre?

> Som du selv er inde på, findes der særlige tilfælde hvor man godt kan.
> Dit eget eksempel kan i det mindste generaliseres til at hvis der
> findes naturlige tal k og j sådan at
>
> b^k = c^j
>
> så virker det. For eksempel kan man omregne mellem b=216 og c=36 fordi
> 216²=36³. Så to cifre i det ene system svarer på simpel måde til tre
> cifre i det andet, i dette eksempel.

Jeg havde ikke lige overvejet denne sammenhæng, men det har du da ret i!

Mvh.
Bjarke