[Gfoss] Grass double precision field

carlo cormio carlocormio a hotmail.it
Ven 30 Nov 2012 12:24:29 CET


Buongiorno a tutti,



questa discussione sul formato dei dati è molto interessante, mi ci sono
 imbattuto spesso e nella maggior parte dei casi ho abbozzato. Sarebbe 
molto bello ed utile creare una pagina con le osservazioni di Andrea ed 
Alessandro, su GFOSS.it o altrove, dove più opportuno.



Non so dove nè come metterci le mani, ma se volete (magari non avete tempo o voglia) posso provare a farlo anche io :)

A proposito, sto seguendo un tesista nell'aggiornamento del database nazionale dei siti minerari (un progetto ISPRA - Università di Bologna), che oltre all'implementazione di nuove funzionalità specifiche prevede il passaggio da MS Access a SQLite / Spatialite (yeah!!!), con l'obiettivo finale di renderlo accessibile tramite webgis, QGIS, tablet, ecc, ecc (un passo alla volta :)).

Dopo una lunga (ed in parte sofferta) analisi dei data type in SQLite siamo arrivati alla conclusione che i dati numerici nelle tabelle avranno sempre diverse cifre decimali, anche quando non necessarie (in termini di precisione del dato), e che se vogliamo visualizzare un dato "arrorondato" basta usare un'opportuna query SQL. E? tutto giusto o sto sbagliando un bel po' di cose?



Complimenti a tutti e buona giornata,



Carlo



Il 30/11/2012 11:04, a.furieri a lqt.it ha scritto:


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
  


  


  


  


  


  




 		 	   		  
-------------- parte successiva --------------
Un allegato HTML ? stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20121130/25fef028/attachment.html>


Maggiori informazioni sulla lista Gfoss