[Gfoss] Grass double precision field

[a.furieri a lqt.it]

On Fri, 30 Nov 2012 10:19:22 +0100, Andrea Peri wrote:
> Questo , abbinato al fatto che si usano una notazione binaria, porta
> alla conseguenza ultima che mentre molti numeri sono rappresentabili
> esattamente, ce ne sono alcuni (non pochi per la verità) che sono 
> espressi
> solo approssimatamente.
>
> Sono emsepi di questi numeri non esattamente rappresentabili in 
> double
> notation i seguenti:
>
> 0.01 , espresso in singola precisione (float) diviene
> 0.009999999776482582092285156250
>
> http://www.binaryconvert.com/
>
> 0.1
> la sua rappresentazione in binario a doppia precisione 64 bit di
> precision (FP64 o double precision) è la seguente:
>
> (0.1)10 -> (0x3FB999999999999A)16 -> (00111111 10111001 10011001
> 10011001 10011001 10011001 10011001 10011010)2
>
> La quale riportata in decimale esprime il valore seguente:
>
> 1.00000000000000005551115123126E-1
>
> cioe'
> 0.100000000000000005551115123126
>

Andrea,

le tue sono Sante Parole: aggiungo solo che quanto tu dici vale
solo in un idilliaco mondo ideale del tutto teorico.
la dura realta' del mondo fisico e' ancora peggiore :-D

perche' occorre mettere nel conto le diverse implementazioni delle
librerie di runtime (che sono sempre e comunque alla base di tutto
quanto il sw, a prescindere del linguaggio usato).
e qua si scopre inevitabilmente che diverse versioni e/o diverse
implementazioni forniscono risultati leggermente differenti.

giusto per fare un banale esempio in C:

...
double x = atof("1.2");
printf("%1.16f\n", x);
...

a seconda della piattaforma che usi scoprirai che puoi ottenere
(piu' o meno a casaccio):
1.2000000000000000
1.2000000000000001
1.1999999999999999

te lo dico con assoluta certezza di causa, visto che ho perso le
ultime settimane per mettere a punto la test-coverage di splite.

e ti assicuro che ho dovuto sudare le mitiche sette camicie prima
di riuscire faticosamente a mettere a punto una serie di test numerici
(coordinate) che tornassero sempre e comunque gli stessi identici
risultati su Debian, Fedora e WinOZ sia a 32 che a 64 bit.

con un'ultima insospettata regressione finale quando poi ho fatto
girare tutta quanta la test-coverage sotto Valgrind, ed ho cosi'
inopinatamente scoperto che in questo ambiente di test alcuni
testcases ritornano ancora altri valori differenti :-P
(non del tutto sorprendente, visto che Valgrind in pratica non
usa la CPU fisica ma usa una macchina virtuale sua propria che
emula i codici macchina x86).

ciao Sandro





-- 
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.