[Gfoss] Grass double precision field

[Andrea Peri]

Furieri wrote:
>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
>

Intendi il conteggio svolto su FP64 ?

Ho volutamente accorciato il discorso altrimenti facevo notte.

In realta' andrebbe messo nel conteggio che non esiste solo la
specifica IEEE754,
ma ne esistono alcune varianti che garantiscono una maggiore precisione.
Poi andrebbe messo nel conto che sulle piattaforme Intel i moderni
(per modo di dire vale dal 486) processori dispongon di un
coprocessore interno
a 80 bit per cui hanno una accuratezza rappresentativa maggiore che
gli consente di realizzare dei conti piu' accurati.

Poi andrebbe conteggiato pure che le piattaforme intel sono
Little-Endian mentre se ad esmepio si va su Mac si troverebbe anche
roba BigEndian.
Ora forse gli ultimi MacBook sono passati a LittleEndian non saprei.

Ovviamente qui l'argomento è archiviazione di dati e non sviluppo di formule.
Per cui si puo' rimuovere il discorso sul coprocessore.
Altreis si puo' rimuovere il discorso su BigEdian e LittleEndian.

LA specifica DBIV dice di usare sempre LittleEndian, quindi anche su
piattaforma Mac.

Ma indubbiamente non dice niente su come il dato va memorizzato su un
campo Double .
Quesot perche' all'epoca non esistevano tante codifiche ne esisteva
una o al massimo due.

Termino con una opinione:
Secondo me in un sistema di archiviazione come il DBF (o un DBMS,
spatialite compreso) è preferibile usare il formato NUMERIC ovvero la
metodica che salva i dati come stringa testuale.
In questa maniera ci si garantisce la coerenza del valore su qualsiasi
piattaforma.
E ci si separa dall'errore introdotto in fase di computazione.

Una volta i BIT di un disco rigido avevano un costo non indifferente,
ora costano molto meno e quindi archiviare in forma testuale come fa'
il DBFIII con il tipo NUMERIC
anche se consume piu' spazio non introduce un costo eccessivo e pero'
garantisce l'esattezza del valore archiviato.
Indipendentemente dalla piattaforma e dalla libreria usata.

Andrea.

>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


-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------