Problema di arrotondamento in campo calcolato
Dino
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
Lolince
http://www.donkarl.com/it/ faq 2.1
Bruno Campanini
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
Dino
>
> - 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
Pablitomf (da casa)
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.)
Dino
wrote:
> Poi permettimi "secondo il principio che 0.5 va arrtondato per
> eccesso"....Chi la stabilito???
>
> ------------------
>
>
> "L'arrotondamento consiste nel prendere, tra due valori precedenti, quello
> 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
> 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
Pablitomf (da casa)
"Dino" <verreng...@alice.it> 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...
Dino
wrote:
> "Dino" <verrengia.d...@alice.it> ha scritto nel messaggionews:87332a3a-55d6-4289...@z9g2000yqz.googlegroups.com...
>
>
>
>
>
> > On 15 Nov, 20:31, "Pablitomf \(da casa\)" <pablit...@hotmail.it>
> > wrote:
> >> 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.)
>
> > 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???
>
> Io non uso alcuna funzione...sono solito usare campi a precisione doppia con
> tale da trovare quanta pi vicinanza possibile della cifra calcolata a
> quella vera non arrotondata...- Nascondi testo citato
>
> - 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
Pablitomf (da casa)
>
> 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...- Nascondi testo citato
>
> - 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.
Dino
wrote:
OK Pabli.Preciso ed esauriente prorpio come un vero "GUAGLIONE"
Dino
Pablitomf (da casa)
eh magari!!!!!
Bruno Campanini
> 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.
Quando dici "volessi due decimali" io direi che intendi "volessi
l'arrotondamenteo alla seconda cifra decimale".
Ché mi sembrerebbe strano che da 3.9099 tu volessi per esempio ottenere
3.90 e non 3.91; se invece fosse proprio quello il tuo intendimento,
dovresti dire che vuoi il troncamento (e non l'arrotondamento) alla
seconda cifra.
>Poi permettimi "secondo il principio che 0.5 va arrtondato per
> eccesso"....Chi la stabilito???
Il principio - più correttamente: la convenzione - dell'arrotondamento
per eccesso dello 0.5 su tutti gli importi monetari sui quali sia
richiesto un arrotondamento è stato definito per legge in previsione
dell'introduzione dell'Euro (non farmela andare a cercare...)
> 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???
Analogamente se l'arrotondamente fosse per difetto!
Comunque nessuno ti vieta di esprimere i valori di una fattura in Euro
con 3, 4 o anche 10 decimali, padronissimo di farlo.
Però alla fine il totale dovrà ben essere espresso in Euro con al
massimo due decimali (poiché la minima moneta divisionaria è il
centesimo e non il millesimo o il decimillesimo...)
E se dunque l'arrotondamento finale è necessario il modo per farlo è
quello definito per legge.
> 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???.
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
Paolo opg
$4faf...@reader2.news.tin.it:
[cut]
>
>> 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???.
>
> 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.
>
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
--
Bruno Campanini
> 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)
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
Pablitomf (da casa)
> sfilza di valori decimali (Euro) semplicemente da sommare... provare per
> credere!
>
> Bruno
Io ce l'ho... precisione doppia con 5 decimali... e funzia da sempre.
Paolo opg
news:TuBEo.1329$Eb....@twister2.libero.it:
>> Oppure fatti un programma di contabilit� dove tu possa avere una
>> bella sfilza di valori decimali (Euro) semplicemente da sommare...
>> provare per credere!
>>
>> 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'.