[Gfoss] Risoluzione spaziale dataset

[a.furieri a lqt.it]

On Wed, 12 Feb 2014 12:11:06 +0100, Jody Marca wrote:
> Come fare a risolvere questi problemi? Semplice non utilizzare il
> double per la memorizzazione come del resto si fa in molti contesti
> dove gli errori di rappresentazione non sono ammessi. Pur esistendoci
> dei tipi di dato sostitutivi (es Bigdecimal.... ) non credo sia
> pensabile risolvere definitivamente tale problema a breve poichè
> questo implicherebbe abbandonare gli shapefile e soprattutto
> aggiornare la maggior parte dei software commerciali e non.
>

... mi permetto di aggiungere una "piccola" nota a margine per
quanto riguarda l'efficienza di calcolo.

moltissimi algoritmi di uso molto frequente in ambito GeoSpatial
(lunghezze ed aree, minima distanza, intersezioni etc) richiedono
montagne di calcoli trigonometrici in Floating Point.

tutti i moderni microprocessori supportano direttamente in HW
questo tipo di operazioni, e sono in grado di macinare un
numero veramente impressionante di operazioni per secondo;
e tutte le librerie matematiche di base (su qualsiasi sistema
operativo) sono ottimizzate per spremere anche l'ultima
goccia della potenza di calcolo offerta dall'HW

per gli ultimi Intel i7 multicore (un processore normalmente
usato per i PC di fascia alta) parliamo di circa 70/100 GigaFLOPS,
cioe' quasi un centinaio di miliardi di operazioni al secondo.
eppure (notoriamente) molte operazioni di calcolo GIS sono pur
sempre di una lentezza mortale ;-)

usare formati alternativi (Decimal, BigDeccimal) risolverebbe
certamente qualsiasi problema di precisione ed arrotondamento,
ma al prezzo di un rallentamento mortale della velocita' di
calcolo, visto che occorrerebbe rinunciare a sfruttare il
supporto HW floating point per usare piuttosto delle routines
completamente implementate via sw e capaci di preservare
inalterata una precisione di calcolo infinita.

cioe' si tornerebbe sostanzialmente indietro nel tempo alla
situazione tipica degli anni '70 ed '80 quando le CPU non
offrivano nessun supporto HW per il floating point, che
veniva piuttosto implementato tramite emulazione sw; oppure
occorreva spendere un bel po' di soldini per acquistare a
parte un co-processore math in grado di offrire supporto hw

se la memoria non mi inganna, la differenza nella velocita'
di calcolo tra "full HW" ed emulazione SW era di oltre cento
volte :-D

siamo veramente sicuri che un miglioramento marginale della
precisione ultra-fine valga la pena di un siffatto handicap
prestazionale ?

... e mi astengo volutamente da qualsiasi considerazione
relativa agli spazi necessari per l'archiviazione dati, che
ovviamente "gonfierebbero" in modo impressionante.

ciao Sandro