Newsgroup: it.comp.lang.delphi
Titolo: Come limitare un float nella tabella parte 2

Ri ciao a tutti,
   come sempre non mi sono spiegato bene, quindi scusa a tutti per la 
superficialita'.
 
Ripropongo il quesito in altra forma, spero in modo corretto.
 
Durante la creazione run-time di una tabella devo definire un campo float.
Il campo float ha la funzione di salvare il prezzo di un articolo in euro 
con due decimali, il prezzo si ottiene da un file esterno che, invece, e' 
fornito con 6 decimali.
Quindi se il prezzo fornito e' 12.359465, nella tabella devo salvare il 
prezzo come 12.36 (comunque arrotondato per eccesso o difetto).
Nella creazione della tabella il campo prezzo e' definito come float, ma lo 
devo limitare a 2 decimali.
Il perche' dei due decimali e' ovvio, tutti i prezzi di acquisto sono 
riportati ai 2 decimali, l'unica eccezione, credo, e' il prezzo della 
benzina che di decimali ne ha 4;
 
Se questo non e' possibile, l'unica alternativa che mi e' venuta in mente e' 
quella di salvare il prezzo in una stringa.
 
In conclusione, non sto cercando un modo di visualizzare un float con due 
decimali, sto cercando il modo di salvare il float limitato a 2 decimali 
nella tabella (se possibile);
 
Spero di essere stato un po piu' chiaro rispetto al messaggio precedente.
 
Grazie a tutti per le eventuali risposte.
 
Ciao,
 
Daniele 
 

> Durante la creazione run-time di una tabella devo definire un campo float.
 
Una tabella DI COSA? SU COSA? SU QUALE DB?
 
A.
 

 fornito con 6 decimali.
 
Secondo me hai scelto un tipo di dato infausto per questo campo, in quanto il *float* non è adatto a salvare valute, proprio perché subisce l'errore di precisione della CPU nella gestione dei valori a virgola mobile.
 
Ti conviene passare a un NUMERIC o DECIMAL, ma per essere più precisi dovresti indicare il database che stai utilizzando.
 
Ciao,
  Marco.
 
-- 
MARCO BREVEGLIERI
#Home: 
http://www.marco.breveglieri.name
 
#Blog: 
http://www.compilaquindiva.net
 

 decimali nella tabella (se possibile);
 
Come gi� espresso da Marco, tutti i numeri in virgola mobile altrimenti 
detti floating point (FP), siano essi float o double, hanno il problema 
degli arrotondamenti che dipendono dall'architettura hardware della CPU. [1]
 
Per evitare di infilarti in ragionamenti troppo complessi e magari 
inutili per il tuo specifico caso (hai 6 decimali che sono pochi per un 
FP) , ti suggerisco di fare in questo modo:
1. converti il prezzo a 2 decimali con RoundTo
2. lo moltiplichi per 100
3. lo memorizzi in un campo integer
4. quando lo rileggi lo dividi per 100 (ovviamente)
 
Da notare che anche la ALU quasi sempre per ottimizzare i calcoli 
trasforma i floating point in interi, effettua il calcolo, e ritorna al 
fp di partenza.
 
Sembra un barba-trucco ma resta il miglior espediente per fare calcoli 
senza perdere precisione.
 
[1] 
http://en.wikipedia.org/wiki/Floating_point
 
-- 
morde
Android
QT 4.7
Delphi (5,6,7.. expired)
Firebird Database
 

 4. quando lo rileggi lo dividi per 100 (ovviamente)
 
Ciao,
giï¿œ che siamo sull'argomento...come vi comportate quando di mezzo c'ï¿œ 
l'interazione con un registratore di cassa?
 
Entrando piï¿œ nel dettaglio, diciamo che nel mio applicativo ho bisogno 
di piï¿œ di due cifre decimali e che la cassa invece ne accetti soltanto 
due.
Ora se sulla cassa invio solamente il totale della vendita non ci sono 
problemi, se invece invio i singoli articoli potrei avere una 
discrepanza sul totale dovuta agli arrotondamenti.
 
Qualcuno ci si ï¿œ imbattuto?
 
-- 
Emanuele Desideri
 
 

 Emanuele Desideri
 

 a 2.
 
Eh alla fine ho preso la strada di mostrare di doppi importi, avvisando 
che la discrepanza è data dagli arrotondamenti.
 
A livello amministrativo non ho mai approfondito la questione, ma se ci 
fosse qualcuno che ha esperienza in merito sarei curioso di saperne di 
più!
 
-- 
Emanuele Desideri
 
 

Io utilizzo la separazione dei decimali della precisione tra prezzi (unitari) ed importi (prezzi per quantità).
 
Il prezzo può avere i decimali che desideri (ad esempio nel caso di tipografie il costo a foglio può essere anche con 6 decimali), ma quando passi all'importo, cioè moltiplichi per la quantità, ritorni al numero di decimali previsti dalla normativa vigente (quindi per l'euro 2 decimali). 
 
(Nell'esempio della tipografia la fornitura tipica prevede almeno qualche migliaio di fogli)
 
Ovviamente dovrai gestire un arrotondamento dei valori al momento del calcolo dell'importo: io fornisco al possibilità di configurare se arrotondare per eccesso, per difetto, con il valore di mezzo per eccesso, con il valore di mezzo per difetto (per capire il significato degli ultimi due casi considera 0,005) 
 
Quando andrai a fare i totali dovrai sempre considerare gli importi
 
Nel caso dei registratori di cassa normalmente il valore che viene passato è un intero moltiplicando i valori per 100
 
Se fai tu il flusso di comunicazione verso il registratore puoi passare direttamente l'importo finale (già a due decimali), oppure puoi passare il prezzo (che in questo caso sarà a due decimali) e la quantità.
 
Ovviamente i due casi produrranno dei valori leggermente diversi proprio a causa degli arrotondamenti.
 
Di solito il committente di un sistema collegato a registratore di cassa è comunque al corrente della problematica e ti da già indicazione di quale strada seguire:
nel primo caso (invio importi), a volte mi chiedono di riportare nella descrizione l'informazione della q.tà
nel secondo caso (invio prezzi e q.tà) di solito i prezzi vengono preventivamente arrotondati a due decimali ed il problema non si pone