---

hejsa
jeg sidder og prøver at "printe" et unsigned long int array ud som
indeholder følgende: test1.xl[0] = 0x00000000;
test1.xl[1] = 0x00000000;
test1.xl[2] = 0x00000001;

eller:
test2.xl[0] = 0xFFFFFFFF ;
test2.xl[1] = 0xFFFFFF01;
test2.xl[2] = 0xFFFFFFFF;

Det skal skrives ud som decimal tal så [0] = første del af tallet [1]
er anden del og [2] er tredje del. hvordan får jeg det skrevet ud som
decimal?

jeg prøvede at lave noget kode som ser således ud, men der er vist helt
fu.... up.

void XLprint(XLong x){
#define XLprintbuflength 1000
   int i = XLprintbuflength - 1;
   int j, rem;
   long int c, newx;
   XLong res;
   char buffer[XLprintbuflength];
   XLpush(x);
   if (x.xl[0] < 0) {
      putchar('-');
      XLneg();
   }
   if (XLiszero())
      buffer[i--] = '0';
   else
      for (j=0;j<XLLength;j++){
         c= x.xl[j];
         while (c != 0 && i>=0) {
            newx=c/10;
            rem=c-newx*10;
//            buffer[i--]=i2c(rem);
            putchar(i2c(rem));
            c=newx;
         }
      }




i2c laver en integer om til char 1='1' osv. og XLiszero finder ud af om
den er lige med 0. Resten er vist selvforklarende.

Det skal bruges til en opgave hvor jeg skal lave et bibliotek der skal
kunne klare 96bit store tal og resten af koden + en makefil kan findes
her: http://www.kampsax.dtu.dk/~schulz/xlong


Nogen der kan hjælpe mig med denne sidste del af opgaven?

MVH
Kim Schulz

--
www.schulz.dk - En nørds bekendelser | Humor in the Court: Q. Were
www.guadec.org - tapas, beer and gnome | you aquainted with the
| deceased? A. Yes, sir. Q.

---

Kim Schulz <kim@schulz.dk> skrev:
>
> hejsa
> jeg sidder og prøver at "printe" et unsigned long int array ud som
> indeholder følgende: test1.xl[0] = 0x00000000;
> test1.xl[1] = 0x00000000;
> test1.xl[2] = 0x00000001;
>
> eller:
> test2.xl[0] = 0xFFFFFFFF ;
> test2.xl[1] = 0xFFFFFF01;
> test2.xl[2] = 0xFFFFFFFF;
>
> Det skal skrives ud som decimal tal så [0] = første del af tallet [1]
> er anden del og [2] er tredje del. hvordan får jeg det skrevet ud som
> decimal?
>
> jeg prøvede at lave noget kode som ser således ud, men der er vist helt
> fu.... up.

Jeg synes at det ser ud til at du prøver på at behandle de 3 dele
af tallet som skal skrives ud, hver for sig. Det tror jeg ikke at
man kan.

Det er fint nok at finde et decimalt ciffer ad gangen ved
successivt at dividere med 10 og tage divisionsresten, men det er
/hele/ tallet du skal dividere med 10, ikke kun en del af det.

---

On Fri, 8 Mar 2002 22:25:27 +0100, Kim Schulz <kim@schulz.dk> wrote:

>
>hejsa
> jeg sidder og prøver at "printe" et unsigned long int array ud som
> indeholder følgende: test1.xl[0] = 0x00000000;
> test1.xl[1] = 0x00000000;
> test1.xl[2] = 0x00000001;
>
> eller:
> test2.xl[0] = 0xFFFFFFFF ;
> test2.xl[1] = 0xFFFFFF01;
> test2.xl[2] = 0xFFFFFFFF;
>
> Det skal skrives ud som decimal tal så [0] = første del af tallet [1]
>er anden del og [2] er tredje del. hvordan får jeg det skrevet ud som
> decimal?

Hej Kim, hvis du vil skrive MEGET store integers (>32 bit) ud til en
standard strøm, kan du nok ikke bruge de indbyggede funktioner,men du
skal nok have fat i nogle multi-precisions algoritmer.

Jeg har selv rodet lidt med det, og har da også fundet en, måske lidt
simpel metode, men den virker da.

Du bliver nok nød til at lave en 96 bit division for at kunne løse dit
problem. Det kunne jo gøres ved at lave nogle SUB, ADD, DIV og MUL
rutiner, som kan håndtere 96 bit ord.

---

> Hej Kim, hvis du vil skrive MEGET store integers (>32 bit) ud til en
> standard strøm, kan du nok ikke bruge de indbyggede funktioner,men du
> skal nok have fat i nogle multi-precisions algoritmer.
>
> Jeg har selv rodet lidt med det, og har da også fundet en, måske lidt
> simpel metode, men den virker da.
>
> Du bliver nok nød til at lave en 96 bit division for at kunne løse dit
> problem. Det kunne jo gøres ved at lave nogle SUB, ADD, DIV og MUL
> rutiner, som kan håndtere 96 bit ord.

Det har jeg skam også og disse benyttes også i min nye kode på

www.kampsax.dtu.dk/~schulz/xlong/

nu hænger den dog bare i en uendelig løkke et eller andet sted og jeg
kan ikke helt se hvorfor.

MVH
Kim Schulz



--
www.schulz.dk - En nørds bekendelser | Your aim is high and to the
www.guadec.org - tapas, beer and gnome | right.
|

---

Kim Schulz wrote:

Hvis du bruger gcc som har datatypen 'long double' kan du benytte dig af,
at 'long double' er stor nok til at rumme 96 bits tal i heltalsrepræsen-
tation:

-------------------------------------------------------------------------
#include <iostream>
#include <iomanip>

void skriv(unsigned n1, unsigned n2, unsigned n3) {
const long double k16 = 1 << 16;
const long double k32 = k16 * k16;
const long double k64 = k32 * k32;

long double d = k64 * n1 + k32 * n2 + n3;

int old_precision = cout.precision(29);
cout << d << endl;
cout.precision(old_precision);
}

void main(void) {
for (int i = 0; i < 96; ++i) {
int n1 = 0;
int n2 = 0;
int n3 = 0;

if (i < 32)
n3 = 1 << i;
else if (i < 64)
n2 = 1 << (i - 32);
else
n1 = 1 << (i - 64);

cout << "2^" << setw(2) << i << ": " << setw(29);
skriv(n1, n2, n3);
}
}
-------------------------------------------------------------------------

-Claus

---

On Sat, 09 Mar 2002 17:18:25 +0100
Claus Rasmussen <clr@cc-consult.dk> wrote:
> Kim Schulz wrote:
>
> Hvis du bruger gcc som har datatypen 'long double' kan du benytte dig
> af, at 'long double' er stor nok til at rumme 96 bits tal i
> heltalsrepræsen- tation:
>
> ---------------------------------------------------------------------
> ----#include <iostream>
> #include <iomanip>
>
> void skriv(unsigned n1, unsigned n2, unsigned n3) {
> const long double k16 = 1 << 16;
> const long double k32 = k16 * k16;
> const long double k64 = k32 * k32;
>
> long double d = k64 * n1 + k32 * n2 + n3;
>
> int old_precision = cout.precision(29);
> cout << d << endl;
> cout.precision(old_precision);
> }
>
> void main(void) {
> for (int i = 0; i < 96; ++i) {
> int n1 = 0;
> int n2 = 0;
> int n3 = 0;
>
> if (i < 32)
> n3 = 1 << i;
> else if (i < 64)
> n2 = 1 << (i - 32);
> else
> n1 = 1 << (i - 64);
>
> cout << "2^" << setw(2) << i << ": " << setw(29);
> skriv(n1, n2, n3);
> }
> }

så falder hele opgaven ligesom til jorden, da den går ud på at lave det
selv. MVH
Kim Schulz


--
www.schulz.dk - En nørds bekendelser | The smallest worm will turn
www.guadec.org - tapas, beer and gnome | being trodden on. --
| William Shakespeare, "Henry

---

Kim Schulz wrote:

> så falder hele opgaven ligesom til jorden, da den går ud på at lave det
> selv.

Det synes jeg lyder som en lidt åndssvag opgave, når 96 bits heltalsope-
rationer er en del af C standarden.

Men hvis du insisterer er der ikke anden vej end at lave en division i
hånden og så bruge standardalgoritmen til at konvertere til decimaltal:

----------------------------------------------------------------------
#include <iostream>

bool digit_seen;

void do_write(unsigned n) {
unsigned digit = n % 10;
n = n / 10;

if (n)
do_write(n);

if (digit || digit_seen) {
cout << digit;
digit_seen = true;
}
}

void write(unsigned n) {
digit_seen = false;
do_write(n);
if (!digit_seen)
cout << "0";
}

int main() {
write(1234567);
}
----------------------------------------------------------------------

-Claus

---

Claus Rasmussen <clr@cc-consult.dk> skrev:
> Kim Schulz wrote:
>
>> så falder hele opgaven ligesom til jorden, da den går ud på at lave det
>> selv.
>
> Det synes jeg lyder som en lidt åndssvag opgave, når 96 bits heltalsope-
> rationer er en del af C standarden.

96 bits heltal er på ingen måde en del af C-standarden.

C-standarden (C99) siger at "long long" mindst skal være på 64 bit
og en "long double" skal have en præcision på mindst 10 decimale
cifre. ISO-standarden fra 1990 (var det vist) garanterer kun 32
bit i heltal i en "long".

Men selv hvis 96-bits variabler var garanteret, er det da ikke
åndsvagt at lave en øvelse. Øvelsen kunne vel også lige så godt
have omfattet endnu større tal.

---

Byrial Jensen wrote:

> Claus Rasmussen <clr@cc-consult.dk> skrev:
>>
>> Det synes jeg lyder som en lidt åndssvag opgave, når 96 bits heltalsope-
>> rationer er en del af C standarden.
>
> 96 bits heltal er på ingen måde en del af C-standarden.

Jo, via 'long double'. Se s. 467 af http://www.ucalgary.ca/~bgwong/n869.pdf
hvor det specificeres, at floating point i C /kan/ følge en række IEC/IEEE
standarder. Specielt

F.2.1 Recommended practice

The long double type should match an IEC 60559 extended format.

[...]

> Men selv hvis 96-bits variabler var garanteret, er det da ikke
> åndsvagt at lave en øvelse. Øvelsen kunne vel også lige så godt
> have omfattet endnu større tal.

Øvelsen /burde/ efter min mening have brugt et (betydeligt) større tal. Nu
har vi i stedet en generation af ingeniører, der tror, at hvis man skal
bruge 96 bits heltal i C, så skal man selv flikke noget sammen.

-Claus

---

"Claus Rasmussen" <clr@cc-consult.dk> wrote in message
news:a6dt6i$avo$1@sunsite.dk...
> Byrial Jensen wrote:
>
> > Claus Rasmussen <clr@cc-consult.dk> skrev:
> >>
> >> Det synes jeg lyder som en lidt åndssvag opgave, når 96 bits
heltalsope-
> >> rationer er en del af C standarden.
> >
> > 96 bits heltal er på ingen måde en del af C-standarden.
>
> Jo, via 'long double'. Se s. 467 af
http://www.ucalgary.ca/~bgwong/n869.pdf
> hvor det specificeres, at floating point i C /kan/ følge en række IEC/IEEE
> standarder. Specielt

det er så floating point, men det drejede sig om heltal, hvis du har en 96
bits float, kan du
vel ikke sige at du kan bruge den til at repræsentere en 96 bit heltal med?
Min oversætter siger desuden at en long double er 64bit, hvilket måske har
noget at gøre
med at den /kan/ og ikke /skal/.

---

Jonas Meyer Rasmussen wrote:

> det er så floating point, men det drejede sig om heltal, hvis du har en 96
> bits float, kan du vel ikke sige at du kan bruge den til at repræsentere
> en 96 bit heltal med?

Jeg tog fejl. Hvis man har en 96 bits IEEE long double (som man normalt
har) kan man /ikke/ bruge det til at repræsentere et vilkårligt 96 bits
tal.

Men kan kan med sikkerhed bruge det til at repræsentere et 64 bits tal
(og også flere end 64 bit men jeg kan ikke huske hvor mange). Det ligger
i IEEE standarden.


> Min oversætter siger desuden at en long double er 64bit, hvilket
> måske har noget at gøre
> med at den /kan/ og ikke /skal/.

Ja. Men ellers tror jeg, at de fleste (intel) compilere bruger 96 bits
long.

-Claus

---

Claus Rasmussen <clr@cc-consult.dk> skrev:
> Byrial Jensen wrote:
>
>> Claus Rasmussen <clr@cc-consult.dk> skrev:
>>>
>>> Det synes jeg lyder som en lidt åndssvag opgave, når 96 bits heltalsope-
>>> rationer er en del af C standarden.
>>
>> 96 bits heltal er på ingen måde en del af C-standarden.
>
> Jo, via 'long double'. Se s. 467 af http://www.ucalgary.ca/~bgwong/n869.pdf
> hvor det specificeres, at floating point i C /kan/ følge en række IEC/IEEE
> standarder. Specielt

Ja, de kan. Der er faktisk ingen øvre grænse for hvor store
taltyper man må have i en C-implementation.

Men de skal ikke. C garanterer heltal på mindst 64 bit. Større
typer end 64 bit er ikke et krav, så 96 bit er ikke en del af
C-standarden.

>> Men selv hvis 96-bits variabler var garanteret, er det da ikke
>> åndsvagt at lave en øvelse. Øvelsen kunne vel også lige så godt
>> have omfattet endnu større tal.
>
> Øvelsen /burde/ efter min mening have brugt et (betydeligt) større tal. Nu
> har vi i stedet en generation af ingeniører, der tror, at hvis man skal
> bruge 96 bits heltal i C, så skal man selv flikke noget sammen.

Det skal man også i mange tilfælde. Der er masser af
implementationer som ikke tilbyder 96-bit beregninger.

---

> Øvelsen /burde/ efter min mening have brugt et (betydeligt) større
> tal. Nu har vi i stedet en generation af ingeniører, der tror, at hvis
> man skal bruge 96 bits heltal i C, så skal man selv flikke noget
> sammen.

jeg kan sætte den til hvad jeg lyster af længde i en #define konstant
som bare skal sættes inden kompile time. Jeg kan snildt benytte det med
128bit eller 256bit

MVH
Kim Schulz


--
www.schulz.dk - En nørds bekendelser | For good, return good. For
www.guadec.org - tapas, beer and gnome | evil, return justice.
|