Newsgroup: it.comp.appl.access
Titolo: Problema Approssimazione Decimale

Vorrei sottoporvi questo quesito che riguarda un programma che gestisce un
bilancio economico creato ad hoc dal sottoscritto in Access 97.
Viene inserito un importo in EURO, quindi previsto con due decimali;
quindi vi sono due campi PERCENTUALI (complementari) e i rispettivi campi
calcolati sulle percentuali indicate.
Esempio.
Inserimento di EURO 20.122,21
poi PERCENTUALE 1 = 50%
e, per calcolo, PERCENTUALE2 = 50%
La maschera calcola i rispettivi valori in base alle percentuali definite.
Tutti i valori sono memorizzati in una tabella COSTI, con tutti i valori
numerici impostati a Precisione Doppia (altrimenti mi gestisce una sola
virgola decimale, e 2 cifre decimali.
Il problema è abbastanza chiaro : il 50% di 20.122,21 è 10061,105!!!
Trattandosi di un DB che uso per stampare dei tabulati/report di bilancio mi
ritrovo, un "errore impercettibile" che si presenta nella 2° cifra decimale
: l'errore sta nel fatto che sommando le singole voci sul report, le stesse
calcolate, non ho corrispondenza perfetta con il totale calcolato dal
report.
Ho provato a troncare i valori nei campi calcolati con una contorta
procedura che converte in stringa, cerca virgola, prende solo due decimali,
riconverte in numerico e assegna nuovamente a campo. Ho notato che i valori
calcolati diventano cose del tipo 10,11000001045, che dal punto di vista dei
totali non crea alcun problema.
Non riesco ad obbligare access a memorizzare il valore calcolato con 2 cife
decimali, bensì il valore ne presenta 3.
Vorrei sapere se qualcuno riesce a risolvere il problema in altro modo.
Ciao
Dinho

 report.
Probabilmente mi sfugge qualcosa...
Se semplicemente nel campo calcolato del report utilizzi una funzione Round,
per esempio =Round([Importo]*[Percentuale];2), e chiaramente adegui la somma
nel piè di report, per esempio =Sum(Round([Importo]*[Percentuale];2)), quale
sarebbe il problema?
Avresti i campi correttamente riportati per ogni record, e la somma tornerebbe
con questi campi...
Fammi sapere cosa non ho capito.
Ciao. Claudio.


Il tipo di dati a virgola mobile (Precisione doppia o Precisione singola)
sono approssimati al numero piů vicino consentito dal metodo binario, č
consigliabile utilizzare per i calcoli monetari  il tipo di dato Decimale
nella tabella e Currency in VBA per fare i calcoli. (Non ricordo se in
Access97 esisteva il tipo decimale)
Spero di esserti stato utile.
Ciao Giorgio

 report.
Verosimilmente le percentuali che utilizzi sono valori a precisione singola
(o doppia): gli scarti d'arrotondamento che ottieni sono in linea con la
natura dei campi suddetti.
Per normalizzare i risultati dei calcoli passa attraverso il "sottotipo"
decimal:
[Valore Currency]*CDec([Valore Precisione Singola])

 Vorrei sapere se qualcuno riesce a risolvere il problema in altro modo.
        CCur(Format$(10061.105,"0.00"))
        -Int(-10061.105*100)/100
danno tutte come risultato:
        10061,11
se invece vuoi ottenere:
        10061,1
allora:
        Int(10061.105*100)/100
--
Ciao :-)
Maurizio
--------
?SPQR(C)
 X
--------

 approfondisca l'argomento.
Secondo me il problema contro cui sta sbattendo la testa sono gli scarti
d'arrotondamento generati da calcoli con tipi numerici misti (currency con
Single o double).

> "warp" news:XMhl9.23123$e31.4...@twister2.libero.it...:

    Vero, ma quella frase "tutti i valori numerici impostati a Precisione
Doppia" ecc. *deve* allarmare. L'amico avra' anche qualche problema nel
sistemare le tegole ma a me, d'istinto, viene di buttare prima un occhio
alle fondamenta. Nel caso particolare poi c'e' una strettissima relazione
fra il non aver digerito i tipi dei campi ed il sorprendersi che un numero
debba essere arrotondato.


Scusate l'assenza dal dibattito che mi riguarda direttamente per il caso da
me proposto.
Ringrazio indistintamente tutti per i suggerimenti.
Probabilmente ho esposto il problema frettolosamente e senza precisione.
Il programma è in ACCESS 97 ( non ha funzione Round, neppure il tipo
Decimal, mi pare...)
L'operatore inserisce l'importo in EURO nel campo IMPORTO (precisione doppia
e 2 cifre decimali in tabella) e le due percentuali per sdoppiare l'importo
stesso.
IMPORTO = EURO 20.122,21
Quindi, ad esempio, 50% e 50% tanto per semplificare.
Il risultato corretto (matematicamente) sarebbe IMPORTO P1 = 10061,105 e
IMPORTO P2 = 10061,105
La cui somma, altrettanto correttamente, dovrebbe fornire l'importo
iniziale.
Entrambi gli importi sono memorizzati in tabella (precisione doppia e 2
cifre decimali). in maschera il formato è standard a due cifre decimali.
Trattandosi comunque di valori monetari, dovrei arrotondare alla seconda
decimale, stiamo parlando di EURO e non si devono usare i valori alla terza
cifra decimale. La regola dovrebbe essere questa.
In realtà, in maschera e in tabella vedo il valore arrotondato 10061.11,
mentre cliccando sul campo la visualizzazione cambia e  ottengo
10061.105...poi esco e torna a due cifre.
Per come è fatto ora il problema si presenta sul report riepilogativo che
opera sulla tabella.
Il report presenta la lista di tutti gli inserimenti e dei valri IMPORTO P1
e IMPORTO P2.
Questo report somma tutti i valori presenti in IMPORTO (quello inserito
dall'operatore) e i valori di IMPORTO P1 e IMPORTO P2, presentando i totali
a piè pagina.
Anche il report è impostato per visualizzare due cifre decimali in formato
standard (vi ricordo ACCESS 97!!!)
Tuttavia succede che, smmando manualmente i singoli valori della colonna
IMPORTO P1 (o P2 è lo stesso) ottengo un risultato che si discosta dal
risultato fornito dal report.
Sto parlando di errore di 1 centesimo di EURO....ma trattandosi di un
programma di Bilancio...
La mia interpretazione è dunque :
I valori calcolati sono memorizzati erroneamente a 3 cifre e non arrotondati
a due...come si dovrebbe fare per i monetari
Questo comporta una serie di ulteriori arrotondamenti da parte della
funzione REPORT che mi generano l'errore di cui sopra.
La mia domanda non è puramente di natura tecnica, ma anche economica. Sto
operando nella direzione giusta cercando di forzare la memorizzazione a due
cifre, in tal caso avrei
IMPORTO 20.122,21
 e
IMPORTO P1 = 10061,11
IMPORTO P2 = 10061,11
La cui somma dà origine a uno scarto ulteriore infatti ottengo 20.122,22
Ciao
Dinho

 La cui somma dà origine a uno scarto ulteriore infatti ottengo 20.122,22
    ... che dovrai correggere all'atto della ripartizione.
    Per esempio potresti, se la somma delle due parti non e' uguale
all'intero, operare un arrotondamento per eccesso ed uno per difetto... Vedi
sempre mio post.


 ha scritto nel messaggio
news:QiVl9.161090$ub2.3...@news1.tin.it...

Un campo di tipo precisione doppia è a virgola mobile, il numero di decimali
che imposti non influisce sul contenuto del campo ma solo sulla sua
visualizzazione.
Devi arrotondare tu gli importi  se non hai la funzione round la più
semplice e affidabile è quella di Maurizio Borrelli CCur(Format$(P1,"0.00"))
ovviamente in P2 deve andare la differenza Tra IMPORTO - P1.
In ogni caso in una gestione contabile i problemi di questo genere vengono
risolti utilizzando il Conto arrotondamenti passivi o attivi (dovresti
consultare un contabile).
IMPORTO P1 = 10061,10
IMPORTO P2 = 10061,10
ARROTONDAMENTI = 0,01
e il bilancio torna.
Ciao Giorgio.

 debba essere arrotondato.
Avevi visto giusto :-)

 Decimal, mi pare...)
Non era questo il tuo problema, comunque Decimal č supportato come sottotipo
di Variant e la funzione CDec fa il suo dovere.
Ciao: Silvio

 Devi arrotondare tu gli importi  se non hai la funzione round
La funzione Round di A>'97 effettua un arrotondamento matematico e non
commerciale (differentemente dalla Round di Excel), quindi è meglio lasciar
perdere.
La cosa è documentata anche sulla kb
http://support.microsoft.com/default.aspx?scid=kb;US;q225330


Dimenticavo...
La tua esposizione mi ricorda il problema dei costi deducibili al 50%, tieni
presente che č meglio pagare le tasse su pochi centesimi che vedersi
contestare il bilancio in fase di verifica fiscale, quindi se P1 č la parte
deducibile assegnerai il valore  = 10061,10 e in P2 (Indeducibile)
assegnerai 10061,11. In ogni caso questo esula dai problemi trattati in
questo NG.
Ciao Giorgio.

 Dinho
