<html>

<head>

<style><!--

.hmmessage P

{

margin:0px;

padding:0px

}

body.hmmessage

{

font-size: 10pt;

font-family:Tahoma

}

--></style></head>

<body class='hmmessage'><div dir='ltr'>

Buongiorno a tutti,<br>

<br>

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.<br>

<br>

Non so dove nè come metterci le mani, ma se volete (magari non avete tempo o voglia) posso provare a farlo anche io :)<br><br>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 :)).<br><br>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?<br>

<br>

Complimenti a tutti e buona giornata,<br>

<br>

Carlo<br>

<br>

<div class="moz-cite-prefix">Il 30/11/2012 11:04, a.furieri@lqt.it ha scritto:<br>

</div>

<blockquote cite="mid:%3C968e4bd3b509b24c2b87be7fca02deb4@lqt.it%3E" type="cite">On Fri, 30 Nov 2012 10:19:22 +0100, Andrea Peri wrote:

  <br>

  <blockquote type="cite">Questo , abbinato al fatto che si usano una notazione binaria, porta

<br>alla conseguenza ultima che mentre molti numeri sono rappresentabili

<br>esattamente, ce ne sono alcuni (non pochi per la verità) che sono 

espressi

<br>solo approssimatamente.

<br>

<br>Sono emsepi di questi numeri non esattamente rappresentabili in 

double

<br>notation i seguenti:

<br>

<br>0.01 , espresso in singola precisione (float) diviene

<br>0.009999999776482582092285156250

<br>

<br>http://www.binaryconvert.com/

<br>

<br>0.1

<br>la sua rappresentazione in binario a doppia precisione 64 bit di

<br>precision (FP64 o double precision) è la seguente:

<br>

<br>(0.1)10 -> (0x3FB999999999999A)16 -> (00111111 10111001 10011001

<br>10011001 10011001 10011001 10011001 10011010)2

<br>

<br>La quale riportata in decimale esprime il valore seguente:

<br>

<br>1.00000000000000005551115123126E-1

<br>

<br>cioe'

<br>0.100000000000000005551115123126

<br>

<br></blockquote>

  <br>

Andrea,

  <br>

  <br>

le tue sono Sante Parole: aggiungo solo che quanto tu dici vale

  <br>

solo in un idilliaco mondo ideale del tutto teorico.

  <br>

la dura realta' del mondo fisico e' ancora peggiore :-D

  <br>

  <br>

perche' occorre mettere nel conto le diverse implementazioni delle

  <br>

librerie di runtime (che sono sempre e comunque alla base di tutto

  <br>

quanto il sw, a prescindere del linguaggio usato).

  <br>

e qua si scopre inevitabilmente che diverse versioni e/o diverse

  <br>

implementazioni forniscono risultati leggermente differenti.

  <br>

  <br>

giusto per fare un banale esempio in C:

  <br>

  <br>

...

  <br>

double x = atof("1.2");

  <br>

printf("%1.16f\n", x);

  <br>

...

  <br>

  <br>

a seconda della piattaforma che usi scoprirai che puoi ottenere

  <br>

(piu' o meno a casaccio):

  <br>

1.2000000000000000

  <br>

1.2000000000000001

  <br>

1.1999999999999999

  <br>

  <br>

te lo dico con assoluta certezza di causa, visto che ho perso le

  <br>

ultime settimane per mettere a punto la test-coverage di splite.

  <br>

  <br>

e ti assicuro che ho dovuto sudare le mitiche sette camicie prima

  <br>

di riuscire faticosamente a mettere a punto una serie di test numerici

  <br>

(coordinate) che tornassero sempre e comunque gli stessi identici

  <br>

risultati su Debian, Fedora e WinOZ sia a 32 che a 64 bit.

  <br>

  <br>

con un'ultima insospettata regressione finale quando poi ho fatto

  <br>

girare tutta quanta la test-coverage sotto Valgrind, ed ho cosi'

  <br>

inopinatamente scoperto che in questo ambiente di test alcuni

  <br>

testcases ritornano ancora altri valori differenti :-P

  <br>

(non del tutto sorprendente, visto che Valgrind in pratica non

  <br>

usa la CPU fisica ma usa una macchina virtuale sua propria che

  <br>

emula i codici macchina x86).

  <br>

  <br>

ciao Sandro

  <br>

  <br>

  <br>

  <br>

  <br>

  <br>

</blockquote>

                                          </div></body>

</html>