Newsgroup: it.comp.lang.visual-basic
Titolo: arrotondamento strano

Che calcolo fa questa routine di VB ?
E' normale ?Sono gli arrotondamenti?
Ad esempio : imponibile 128,74   da un'iva  di  25,75
ma anche l'imponibile 128,75  da un'iva di 25,75 !
Quindi se faccio il calcolo della liquidazione iva posso ottenere 
squadrature di 1 centesimo :
Esempio usando un codice iva con indetraibilità al 50%  e scrivendo queste 
due righe :
128,74        25,75
128,74        25,75
Ottengo dopo il calcolo lo spostamento di un centesimo :
 ----------------------------------------------------------------
 Imponibile detraib.     Imposta detr. Imponib.indetraib.   Imposta ind.
------------------------------------------------------------------
  128,74                   25,74                  128,74     25,76
saluti e grazie

 ma anche l'imponibile 128,75  da un'iva di 25,75 !
scusa gabriele, qui visual basic non c'entra, serve soltanto saper
usare una calcolatrice:
128,74 x 20% = 25,748 --> arrotondato al centesimo: 25,75
128,75 x 20% = 25,75  --> non c'e` nulla da arrondare
-- 
ciao, hal

gabriele ha usato la sua tastiera per scrivere :

E' abbastanza ovvio che l'ultimo valore sia ricavato per differenza, e 
non per aliquota.
Semmai, potresti porti il dubbio che sia corretto quel 25.74, ma ci 
sono indicazioni normative ben precise su come arrotondare. Dal punto 
di vista di VB, esso offre diverse funzioni di arrotondamento, sta allo 
sviluppatore scegliere quella che risponda alla normativa a cui si fa 
riferimento.
Ciao
Alberto
-- 
A questo punto hanno trovato un muro,
un muro duro, molto molto duro,
che siamo noi.

 indicazioni normative ben precise su come arrotondare.
fa cosě : 128,74 \ 2 = 64.37
64,37\100 x 20 = 12,874   arrotondato a  12,87
12,87 X 2 = 25,74  !
Diciamo che non dovrebbe arrotondare prima di aver fatto la moltiplicazione 
.....
grazie dello spunto che mi hai dato ! 

 Diciamo che non dovrebbe arrotondare prima di aver fatto la moltiplicazione 
Allora è stato sbagliato l'uso dei tipi.
Un classico dei principianti.
Non considerano i passaggi intermedi delle elaborazioni, e non si 
rendono conto che ad un certo punto un certo risultato viene troncato, 
e i decimali tagliati sarebbero tornati utili nel proseguio del 
calcolo.
Un altro errore, è anche quello di partire verso il basso: visto che 
moltiplicazioni e divisioni possono essere fatte in ogni ordine, 
occorre sempre fare prima le moltiplicazioni e lasciare le divisioni 
alla fine.


 sempre fare prima le moltiplicazioni e lasciare le divisioni alla fine.
questo tipo di errore non l'ho capito.....
ciao 

 questo tipo di errore non l'ho capito.....
Perché aumenta l'errore finale, o anche lo può creare dove altrimenti
non vi sarebbe.
Le divisioni introducono (o possono introdurre) errori di troncamento,
dovuto al fatto che i risultati (anche quelli pariali) sono registrati
con un numero di cifre binarie finito.
Inoltre moltiplicando "dopo" finisci per moltiplicare anche l'errore
che hai commesso con le divisioni precedenti.
Ciao.
Mauro


gia` usando il sistema decimale c'e` il problema dei resti o, meglio,
del numero di decimali da usare per fare i calcoli.
comunque vada, si tratta pero` sempre di un numero finito di cifre
decimali: pensa ad esempio a ricostruire il punto di partenza in un
calcolo come questo:
1 / 3 * 3 = ?
rischi di ottenere "quasi" 1, ma non piu` uno
se, invece, cambi cosi`:
1 * 3 / 3 = ?
ottieni certamente 1
a quanto sopra si aggiunge il fatto che il computer non usa il sistema
decimale, ma il binario, con la traduzione della parte decimale secondo
regole stabilite dallo standard IEEE.
penso che, prima di approfondire, convenga condividere il contenuto
(Complete) Tutorial to Understand IEEE Floating-Point Errors
http://support.microsoft.com/default.aspx?kbid=42980
-- 
ciao, hal

 ottieni certamente 1
Aggiungo che il tipo di dati "migliore" per trattare "prezzi" e "iva" e' il 
currency, dato che non è a virgola mobile.
hth,
Lokar 

currency, dato che non è a virgola mobile.
Io, dopo brutte esperienze con ferramenta (dove gli importi unitari
sono notoriamente molto bassi), ho preso l'abitudine di utilizzare il
Double e da allora non ho piu' problemi.
Per le applicazioni standard (ovvero dove gli importi sono con 2
decimali) sicuramente il Currency la maggior parte delle volte puo'
comunque andare bene.

 Double e da allora non ho piu' problemi.
Sarà, ma io le rappresentazioni a virgola mobile per
trattare numeri "fiscali" preferisco evitarle comunque =)
Anche perchè anche in casi come quello del "ferramenta"
è sufficiente usare fattori di moltiplicazione (10, 100, 1000)
e giocare con la visualizzazione del numero.
Just my 2 eurocent,
Lokar 

 currency, dato che non è a virgola mobile.
Sicuramente, il Currency è un ottimo strumento per 'memorizzare' i 
dati, siano essi l'input o l'output di una formula.
Ma i passaggi intermedi vanno valutati, in funzione dell'ordine di 
grandezza su cui si opera, della precisione desiderata, e delle 
eventuali normative a cui ci si debba attenere.
E' del tutto normale (anzi, è indispensabile qualora i numeri lo 
richiedano) utilizzare dei Cast espliciti all'interno delle formule, il 
forzare le costanti sul tipo. Ad esempio, quando si opera con le 
percentuali, capita di dover moltiplicare o dividere per 100. Beh, se 
io scrivo 100 *.... opero in un modo, se scrivo 100# *...., opero in un 
altro, se scrivo 100@ *... opero in un altro ancora. In linea di 
principio (ma in realtà sono flessibile caso per caso), io effettuo un 
cast a Double al primo passaggio, con 100# *...


 passaggio, con 100# *...
A Double? O_o
Lokar.perplesso 

Nel suo scritto precedente, Lokar ha sostenuto :

Come tipo *intermedio*, male non fa, anzi.
Sono molti di più i casi in cui il non usarlo ti genera incongruenze.
