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 _______________________________________________ Gfoss@lists.gfoss.it http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013
