Newsgroup: it.comp.lang.c
Titolo: numeri grandi in C

Salve a tutti. Dovendo stampare numeri molto grandi con decimali, ho provato
ad utilizzare una variabile "long double". Come risultato, verificato con la
printf, ottengo un numero inesatto sulle ultime due cifre.
Come posso ovviare?Qual'è il limite consentito dallo C per i numeri grandi??
Il numero in questione è:
1234567890123456789


Penso che lo superi il limite massimo...
dovresti usare la libreria per calcoli complessi, che si chiama...
orf...non ricordo!
--------------------------------
Inviato via 
http://usenet.libero.it

 orf...non ricordo!
Me ne ricordo una che si dovrebbe chiamare BIGNUM o qualcosa del genere,
però mi par di ricordare che faccia calcoli sugli interi.
Tentar non nuoce...
Saluti a tutti,
Gigi.

 Tentar non nuoce...
vedi un pò se può esserti utile
http://www.csc.fi/math_topics/Mail/FAQ/msg00015.html
Saluti a tutti,
Gigi.

 Come posso ovviare?Qual'? il limite consentito dallo C per i numeri grandi??
Il C99 introduce un tipo scalare a  64bit: il long long int. Il range va
da -(2^63 - 1)  a 2^63 - 1. Il corrispondente unsigned va da  0 a 2^64 -
1. E` abbastanza grande per contenere il numero che hai postato.
Il problema e` che  su macchine a 32bit (es. x86)  le operazioni su long
long  sono  relativamente  lente[1]  e  soprattutto  non  sono  atomiche
(potresti avere sorprese se usi piu` threads).
Luca
[1] Solitamente piu` veloci delle operazioni di una libreria a
precisione arbitraria, ma piu` lente delle operazioni sugli altri
scalari.
-- 
Home: 
http://kronoz.cjb.net
Not an editor command: Wq

 (potresti avere sorprese se usi piu` threads).
mi spieghi un po questi problemi ???
ciao

 1234567890123456789
Il tipo 'long double' ha una precisione di 19~20 digit (19 cifre 
"pulite" piu' qualcosina).
Il tuo numero ne ha 19 di digit e quindi dovrebbe starci !!!
long double val = 1234567890123456789;
printf ("%Lf\n", val);
Questo dovrebbe stampare:
1234567890123456789.000000
Ciao

 ha scritto:

La lettura/scrittura di  numeri a 64bit richiede due  accessi in memoria
(i  registri sono  a 32bit). Se  piu`  thread leggono  e scrivono  sulla
stessa variabile long long possono capitare grossi pasticci.
Supponi  che il  thread  1  vogli scrivere  mentre  il  thread 2  voglia
leggere.   eax  contiene   l'indirizzo   della  variabile. Supponi   che
l'esecuzione avvenga in questo modo:
Thread 1                        Thread 2
                                movl (%eax), %ecx
movl $123456789, (%eax)          
movl $111112222, 4(%eax)
                                movl 4(%eax), %ebx
Quello che accade  e` che il secondo thread legge  mezza variabile prima
della scrittura  e mezza dopo,  il valore che  viene fuori e`  del tutto
insensato. Nel caso di variabili a 32bit questo non potrebbe accadere, o
viene letto il valore prima della scrittura oppure viene letto il valore
dopo la scrittura.
La lentezza e` dovuta al fatto che servono due operazioni per affettuare
l'addizione. Supponendo che  la prima  variabile sia  in %eax:%edx  e la
seconda in %ecx:%ebx:
addl %ecx, %eax
adcl %ebx, %edx (come add ma considera anche il flag carry)
La moltiplicazione e` ancora piu` divertente ;)
Il tempo di esecuzione e`  raddoppiato, le istruzioni non possono essere
eseguite in  parallelo perche`  la seconda  dipende dal  risultato della
prima. Inoltre  (e non  e`  un  fatto da  trascurare)  la pressione  sui
registri e`  al limite. Degli 8 GPR  2 non possono essere  usati (%ebp e
%esp), 2 hanno funzioni particolari (%esi,  %edi - al limite si potrebbe
usarli per dei puntatori o per dei valori temporanei) e gli altri 4 sono
occupati dai due long long.  Registri disponibili: zero.
Kronos
-- 
Home: 
http://kronoz.cjb.net
Runtime error 6D at f000:a12f : user incompetente

 dopo la scrittura.
[cut]
capito tutto ... ma tutto si risolverebbe con i normali mutex o semafori no
??? ;-)
ciao

 ??? ;-)
Si`, ma questo significa ulteriore overhead :)
Kronos
-- 
Home: 
http://kronoz.cjb.net
It can't rain forever,
but you can die before seeing the sun again.

 Si`, ma questo significa ulteriore overhead :)
se vabbe ... all'ora che famo vuoi la botte piena e la moglie ubriaca ???
cioe' per un test su un mutex non bloccante non perdi nulla in tempo 1-7
cicli (in base alla cache) e puoi benissimo usare i numeri grossi senza
errori di incongruenze ...
ciao

 e puoi benissimo usare i numeri grossi senza errori di incongruenze
Dipende  dal  tipo  di  operazioni   che  vengono  fatte. Se  si  tratta
di  incrementi/decrementi  allora  siamo   d'accordo. Se  si  tratta  di
moltiplicazioni,  divisioni  od  operazioni bitwise  allora  i  problemi
potrebbero essere grossi.
Kronos
PS: stiamo andato un po' OT :)
-- 
Home: 
http://kronoz.cjb.net
K.R.O.N.O.S
Kinetic Replicant Optimized for Nocturnal Observation and Sabotage