Newsgroup: it.comp.appl.access
Titolo: Problema di arrotondamento in campo calcolato

Ciao a tutti .Volevo scomodarvi perv un problema (vecchio come la
notte dei tempi) e cioe' l'arrotondamento dei decimali.Lo so che si
e'
risolto tutto con la funzione di Karl a riguardo del round ma io non
riesco ad applicarla.Esempio campo calcolato "Totale" composto dal
campo importo (prop. numerico precisione doppia formato € decimali 2)
e dal campo "percentuale" (proprieta' testo). Il campo calcolato a
sua
volta ha il formato €  a 2 decimali. Svolgendo il calcolo come tu ben
sai Access mi arrotonda per eccesso.Esempio pratico. Campo "importo"=
€ 75 - campo "Percentuale"=5,25 totale = 3,94 mentre svolgendo il
calcolo con la calcolatrice mi da 3,93.
Ecco volevo sapere come poter correggere il tutto magari attraverso
una funzione che intervenga anche nei campi calcolati.
NB:Vi anticipo il problema non e' il campo testo, lo da anche se
tutti
icampi sono numerici a precisione doppia o valuta.
Come si puo' fare????
Grazie in anticipo
Dino


http://www.donkarl.com/it/
    faq 2.1

Dino formulated the question :

L'esempio che porti mi pare a dir poco infelice!
75 * 5.25/100 = 3.9375  (risultato esatto, non arrotondato).
Quale sarà mai quella calcolatrice  che richiesta di arrotondare (non 
troncare) alla seconda cifra, produce 3.93???
Perché se possono esservi dubbi circa l'arrotondamento di 3.9350 (una 
volta, ante Euro, noi avremmo arrotondato a 3.93 mentre tutto il mondo 
- o quasi - arrotondava a 3.94 ma ora anche noi arrotondiamo a 3.94) 
dubbi proprio non ve ne sono per 3.9375: tutto il mondo - noi compresi 
- ha sempre arrotondato a 3.94=
Ciò premesso Access arrotonda correttamente (secondo il principio che 
0.5 va arrotondato per eccesso) posto che abbia a che fare con VarType 
Currency ovvero Decimal.
Se usi Single ovvero Double (o qualsiasi altro VarType che lavori in 
FloatingPoint) puoi aspettarti di tutto!
Bruno

 - Mostra testo citato -
Ciao Bruno e grazie per la risposta.Allora il calcolo che hai
riportato e' corretto.In effetti la calcolatrice da 
3.9375.Se
 in
questo caso volessi i due decimali pero' sarebbe
3,93.Poi permettimi "secondo il principio che 0.5 va arrtondato per
eccesso"....Chi la stabilito???Se ipotizzi di avere una fattura di 100
voci dove ogni voce arrotondiamo per eccesso in questo modo tu
convieni con me che il totale fattura alla fine ha una variazione da
prendere in condiserazione o no???
Altro dubbio i discorsi sulla sistemazione della funzione Round con la
famosa funzione di Karl non dovrebbero servire per risolvere il
problema che sto sottolineando???
Ad ogni modo il mio non vuole essere un tono polemico (io voglio
ancora sottolineare la tua disponibilita') ma solo un cercare di
capire una volta per tutte come impostare correttamente il processo di
calcolo.
Ad ogni modo tu dici che va bene così e soprattutto l'impostazione che
vado a dare nella proprieta' di campo e corretta??(cioe' numerico
precisione doppia?) o sarebbe meglio altro???.
Grazie mille

Poi permettimi "secondo il principio che 0.5 va arrtondato per
eccesso"....Chi la stabilito???
------------------
Uhm...č semplicemente una regola matematica... punto.
"L'arrotondamento consiste nel prendere, tra due valori precedenti, quello 
piů prossimo al valore originale.
Nel caso in cui il valore originale sia equidistante dall'arrotondamento per 
difetto e da quello per eccesso (p.e.: 13,65 o 13,75 con arrotondamento a 
tre cifre, o al primo decimale), si sceglie quello la cui ultima cifra č 
pari (nell'esempio: 13,6 e 13,8); con questo accorgimento, si preserva 
l'equilibrio statistico tra i due arrotondamenti." (cit.) 

 l'equilibrio statistico tra i due arrotondamenti." (cit.)
Ok.Quindi per rispondere alla mia scelta della proprieta' numerico -
precisione doppia cosa dici Ok o e' meglio numerico - decimale ecc.
E poi a riguardo della funzione Round dei suoi prob. di arrotondamento
e della funzione di Karl per sistemare il tutto??
Tu cosa usi e cosa mi consigli???
Dino

 ha scritto nel messaggio 
news:87332a3a-55d6-4289...@z9g2000yqz.googlegroups.com...

Io non uso alcuna funzione...sono solito usare campi a precisione doppia con 
5 cifre decimali (lo standard usato dai programmi di contabilità) in modo 
tale da trovare quanta più vicinanza possibile della cifra calcolata a 
quella vera non arrotondata...

 - Mostra testo citato -
Ok.Quindi confermi la mia scelta.Solo che io di solito utilizzo(come
vuole lo standard in € ) i due decimali dopo la virgola.
Dino

 - Mostra testo citato -
Ok.Quindi confermi la mia scelta.Solo che io di solito utilizzo(come
vuole lo standard in � ) i due decimali dopo la virgola.
---------------
lo standard in � � un conto, i calcoli son altro... io utilizzerei quanti 
pi� decimali possibili (5 o 6) per poi ridurne a 2 in fase di 
visualizzazione... questo per affinare quanto pi� possibile i calcoli. Il 
risultato poi lo puoi mostrare come ti pare da 0 cifre a 1000 cifre dopo la 
virgola. 


wrote:

OK Pabli.Preciso ed esauriente prorpio come un vero "GUAGLIONE"
Dino

 ha scritto nel messaggio 
news:3a1ceb0a-3659-4b5a...@g16g2000yqb.googlegroups.com...

eh magari!!!!! 

 precisione doppia?) o sarebbe meglio altro???.
Ho proprio detto il contrario:
Numero Currency o Decimal, mai Single o Double.
Questi ultimi due lavorano in FloatingPoint e non sono per nulla 
affidabili se devi ottenere calcoli decimali esatti.
Il Currency (Valuta) è l'ideale per l'uso contabile, porta fino a 4 
cifre decimali.
Il tipo Decimal consente un numero ancora maggiore di cifre (decimali o 
non - vedi Help.
Circa le funzioni di arrotondamento, io ne uso una homemade:
===============================================================
Public Function EuroRound(ByVal ValueToRound, Optional DecimalDigit As 
Byte = 2)
ValueToRound = CDec(ValueToRound)
EuroRound = (Sgn(ValueToRound) * (Fix(Abs(ValueToRound) * _
            10 ^ DecimalDigit + 0.5) / 10 ^ DecimalDigit))
End Function
================================================================
ma ne trovi in giro a volontà, tutte ben funzionanti!
Bruno

 
perche' non usare variabili floating point per registrare soldi:
Dim dbl1 As Double, dbl2 As Double, dbl3 As Double
dbl1 = 54
dbl2 = 0.03
dbl3 = 0 + dbl1 + dbl2
MsgBox(dbl3 - dbl1 - dbl2)
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 MsgBox(dbl3 - dbl1 - dbl2)
La storia è lunga e complicata.
Guardati un po' in giro dalla finestra di Google, per esempio:
http://en.wikipedia.org/wiki/Floating_point
 (leggitelo bene!)
etc, etc.
Ed anche:
Dim d as Double, i as Integer
d = 0
For i = 1 To 10000
    d = d + 1 / 10000
Next
Msgbox d
Oppure fatti un programma di contabilità dove tu possa avere una bella 
sfilza di valori decimali (Euro) semplicemente da sommare... provare 
per credere!
Bruno

 Bruno
Io ce l'ho... precisione doppia con 5 decimali... e funzia da sempre. 

 
finora hai avuto fortuna.
e non per opinione personale, ma per specifica del tipo dati.
ripeto: non e' un'opinione, ma un comportamento previsto by design dal 
prodotto.
se usi il campo double NON registri il valore che inserisci ma una sua 
approssimazione (non 'la' sua approssimazione, ma una di quelle 
possibili) piu' vicina, con tutto cio' che questo comporta.
solitamente quando sono in ballo soldi non interessa avere tanti decimali 
(la legge stabilisce che ne bastino due, mi pare) quanto che il valore 
digitato venga registrato esattamente come l'utente lo inserisce.
e che se lo leggo domani o tra 5 secondi sia quello che ho digitato io, 
non una sua approssimazione, per quanto vicina.
riporto ancora il codice d'esempio:
Dim dbl1 As Double, dbl2 As Double, dbl3 As Double
dbl1 = 54
dbl2 = 0.03
dbl3 = 0 + dbl1 + dbl2
MsgBox(dbl3 - dbl1 - dbl2)
esegue operazioni banalissime, ma il risultato non e' proprio quello che 
ti aspetteresti...
giusto per info, ecco un po' di documentazione ms al riguardo:
http://msdn.microsoft.com/it-it/library/system.double%28v=VS.80%29.aspx
in particolare il paragrafo 'Utilizzo dei numeri a virgola mobile'.
