[Gfoss] Grass double precision field

[Andrea Peri]

furieri wrote:
>Marco,
>
>le variabili "double precision" sono numeri binari a virgola mobile
>conformi allo standard IEEE 754:
>http://it.wikipedia.org/wiki/IEEE_754
>
>come puoi vedere, proprio in quanto "a virgola mobile", non hanno
>un numero predeterminato di cifre intere e decimali, dipende tutto
>dal valore che viene effettivamente memorizzato.
>approssimativamente, la somma delle cifre decimali e di quelle
>intere e' 17 o 18 (non aspettarti un valore esatto, perche' essendo
>un formato binario non ha un'esatta corrispondenza in base10)
>
>dato che per qualsiasi sw e' del tutto impossibile sapere a priori
>quante cifre decimali (precisione) sono effettivamente disponibili,
>si usa sempre visualizzare una rappresentazione approssimativa ed
>arrotondata che utilizza un numero limitato di cifre decimali:
>tipicamente 4 oppure 6, molto piu' raramente 8.
>

Salve,

dopo attenta analisi e alcune prove per verificare la mia teoria.
Intervengo nel discorso.

Infatti si è formato un equivoco.

Quello che dice Furieri è tutto vero, ma non siapplica a questo caso.
Guiducci parla del file DBF.
Qui si entra in una zona dove le "scorie" sono molte e molti sono i
problemi, anche se temo che quasi nessuno ne abbia realmente
percezione.

Cerco di essere breve.

Il formato DBF è statao definito da Ahton-tate tanti anni fa'.
Negli anni si sono susseguiti tante versioni successive.
Il formato che universalmente piu' di ogni altro ha realizzato la
massima divulgazione nel mondo informatico è il cosidetto
dbf formato DBaseIII (III sta per 3).

Poi pero' ce ne sono stati altri, DBaseIV, e addirittura una versione
"DBF Clipper " e una versione "DBF Paradox".

Purtroppo esri quando ha deciso di usare il formato DBF, anziche dire
"fate riferimento alle specifiche aston-tate originali", ha ritenuto
piu' furbo reiterarle.
nel fare questo ha alimentato alcuni fraintendimenti, non avendole
scritte troppo bene, ma saltando a piè pari alcuni "dettagli".
Pero' dichiare che tali specifiche sono atitnenti al formato "DBF DbaseIII".

Per cui faccio riferimento ad esse.

Nel DBF non esiste un formato DOUBLE, ne' esiste il formato FLOAT.
Esiste solo il formato NUMERIC in cui si mette parte intera e parte decimale.

Tale valore viene fissato in fase di creazione del DBF

E NON PUO' ESSERE MODIFICATO ! A meno di non voler riscrivere il file
dbf stesso.

Infatti la modifica di tali valori comporterebbe la modifica della
dimensione del file.
Proprio perche' il formato DBF ha una costruzione che riempe
preventivamente i campi.

Per cui se Grass definisce un campo di tipo
18.5 fissa nel DBF uno spazio di 5 digit per la parte decimale.
Al che' se anche io ci scrivo un valore cosidetto Double, le cifre
decimale oltre la quinta vanno irrimediabilmente perse.

Questo nel dbf formato DBaseIII.

Invece, se si considera le specifiche del DBaseIV, in esso fu' defiito
il formato "double".
Ovvero una memorizzazione binaria del dato numerico.

Li' è vero quello che dice Furieri.
Ma questo ripeto vale solo se si considera un file dbf in formato DBase IV.

Per essere ancora piu' conciso:
nel formato DBIII non esisterebbe il double, ma solo il numeric con
indicazione di parte intera e parte decimale.
E come dice la specifica:
http://www.dbase.com/Knowledgebase/INT/db7_file_fmt.htm
Nel caso del campo numeric:

N 	Numeric 	Number stored as a string, right justified, and padded
with blanks to the width of the field.

Il numero è memorizzato come stringa di testo.

Da qui nasce anche una certa debolezza dle formato shapefile.
Infatti a giro si trovano a volte dei file dbf che sono rispettosi
della specifica DBIII e altri che rispettano la specifica DBIV.

Se in essi ci sta un campo numerico di tipo double, li' cominciano i dolori.

Tornando al nostro caso:
Nel caso della tabella qgis.
In realtà la tabella mostra tutti i decimali.
E se ne mostra 5 e' solo perche' dentro il file si stanno numeri con
solo 5 decimali perche' si tratta di un campo Numerics.

Questo perche' Grass crea un file dbf nel formato DBIII e definisce il
campo Numeric 18.5.

Saluti,

Andrea.


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