|
U0
Se ha gia' un'idea di quali sono le sezioni del programma che potrebbero servire per la sua attivita' possiamo fare dei test con 9-10 decimali per testarne il funzionamento. In linea di massima posso dirle che il problema principale e' dovuto al fatto che il numero di cifre significative e' limitato.
Le faccio un esempio che magari la aiuta a capire il problema. Supponiamo di gestire le quantita' di magazzino a 10 decimali. -Creo un nuovo articolo -carico a magazzino una quantita' di questo articolo di 0,0000000001 (grammi?)
fin qui tutto bene
-carico a magazzino un'ulteriore quantita' di 0,0000000006 -a magazzino mi risulta una quantita' totale di 0,0000000007
e anche fino a qui tutto bene.
-Ora supponiamo di caricare a magazzino una quantita' di 1'200'000 (unmilioneduecentomila). -su Ready a magazzino mi risultera' una quantita' totale di 1'200'000 (invece di 1'200'000,0000000007)
In pratica finche' lavoro su quell'articolo sempre con cifre dello stesso ordine di grandezza tutto ok. Se vado pero' a sommare (o a sottrarre) quantita' di un'altro ordine di grandezza, i decimali li perdo.
-stesso discorso se carico a magazzino una quantita' di 1'200'000 e poi scarico 0,0000000001. Il risultato corretto dovrebbe essere 1'199'999,9999999999 ed invece il programma visualizzera' sempre un magazzino di 1'200'000
Indicativamente posso dirle che la perdita di precisione dovrebbe esserci quando parliamo di carichi e scarichi che differiscono quantitativamente tra loro per 16-17 ordini di grandezza. Comunque sia prima di utilizzarlo in un ambiente di produzione andrebbe tutto collaudato per un po' di tempo ed in maniera rigorosa
|