Newsgroup: it.comp.appl.access
Titolo: Somma strana

Ho una tabella del tipo
Prodotto        Quantità (numerico singola precisione)
A                    12
B                    56,83
A                    3
C                    13
Ho eseguito una query di raggruppamento dei vari prodotti e che mi esegua la
somma corrispondente della quantità per ogni prodotto.Non riesco a capire
perchè di B mi dia come somma
56,8300018310547 invece di semplicemente 56,83.
Grazie per gli eventuali aiuti. Ciao.

 ha scritto nel messaggio
news:ebcp5.128411$dF5.2...@news.infostrada.it...

Come sicuramente saprai in un PC i numeri sono contenuti non in base 10
bensì in base 2 (ovvero in binario); non so se sai che non tutti i numeri in
base dieci sono perfettamente rappresentabili inbase 2.
A quanto pare uno di questi è 56,83.
Resta il fatto che al momento che li digiti indichi anche implicitamente un
formato al campo, che maschera tutti i decimali che ci sono in più: però
quando fai una somma e il risultato lo collochi in un campo o controllo non
esplicitamente formattati, ti appare questa inesattezza; se invece imposti
un formato che ti mostra solo due decimali, rivedrai il tuo 56,83 , ma è
solo apparenza; insomma faresti valere il vecchio adagio "occhio non vede,
cuore non duole" , ma il problema resta in tutta la sua sostanza, e penso
che ancora non si stia pensando di abbandonare il codice binario all'interno
dei computer.  :o)
Roberto

56,8300018310547 invece di semplicemente 56,83.
con le variabili a virgola mobile è normale un'approssimazione di quel
tipo, fa parte del modo in cui sono immagazzinate.
--
make it idiot proof and someone will make a better idiot.
--
il sito comune di it.comp.appl.access:
http://members.xoom.it/it_db_access/

A quanto pare uno di questi è 56,83.
scusa Roberto, io sono ignorante in materia per cui potrei sbagliare,
ma questo non dipende dal fatto che per i numeri a virgola mobile si
usa un sistema esponente-mantissa con tutte le approssimazioni del
caso?  
inoltre intuitivamente mi risulta difficile da credere che non si
possano esperimere gli stessi numeri (anche con parte frazionaria -
per non dire *decimale*...) con sistemi a base diversa... voglio dire,
un numero è un numero!
ok, tu mi dirai, esprimi 1/3 decimale...  boh, comunque non mi
convince.
comunque, ripeto, non conosco la materia, per cui se vuoi darmi
qualche chiarimento mi fai un favore.



Per quelle che sono le mie reminiscenze da studente (ma di tempo ne è
passato tanto) cambiando la base di espressione di un numero e avendo un
numero finito e non infinito di cifre è posibile che una quantità non sia
perfettamente rappresentata (vedi ad esempio la quantità di mm. contenuti in
un pollice); resta il fatto che anche il concetto di infinito è relativo,
per cui moltiplicando il raggio per un pi greco con 2 decimali si dice che
si riesce a conoscere la circonferenza di un cerchio (ma sai che in assoluto
non è vero).
Roberto

 A quanto pare uno di questi è 56,83.


 ha scritto nel messaggio
news:Zpxp5.134230$dF5.2...@news.infostrada.it...

La mia affermazione era sicuramente ironica, e pensavo di averlo indicato
con la faccina ghignante.
Quanto alla soluzione, è quella di impostare il formato con due decimali,
come ti avevo detto; penso che avere un risultato giusto al miglionesimo
dell'unità non è poi così male.
Se poi questa precisione non ti basta, puoi lavorare con valori interi ma
moltiplicati per 100 e poi dividi la somma per 100. Onestamente mi sembra
eccessivo: comunque decidi tu.
Roberto

56,8300018310547 invece di semplicemente 56,83.
Usa il tipo di dati valuta.
--
Lorenzo Coronati
--
<<Io studio ing gestionale e dei non laureati 
che mi sputano in faccia mi faccio beffe.>>
(Andrea "Mr Bad Guy", 10/07/2000)
--

--
adesso ce n'è una più divertente sulle macro...


adesso ce n'č una piů divertente sulle macro...
Gia' provveduto ;-)
--
Lorenzo Coronati
--
<<Si perché forse Ilbo (ed altri come lui) sono 
convinti che noi poveri principianti (nel senso 
ironico) scrivano le domande senza pensare.>>
(Ivan Lelli, 25/08/2000)
--

 un numero è un numero!
Dipende, (da che cosa dipende? da che lato guardi il mondo tutto dipende!)
Il problema e' la conversione del numero da base 10 a base 2.
Per la parte intera il problema non si pone, come dici, un numero e' un
numero.
Il problema nasce per la parte fratta.
Immaginiamo di convertire 0,8:
Abbiamo 0,1100 periodico (per chi non ricorda *periodico* significa
o,110011001100.. all'infinito)
Ricordo che la conversione dei numeri interi si ottiene allineando i resti
che si ottengono dividendo piu' volte per 2 il numero da convertire mentre
la conversione dei decimali si ottiene allineando la parte itera del numero
che si ottiene moltiplicando piu' volte per due la parte fratta del
risultato:
0,8 x 2 = 1,6 -> 1
0,6 x 2 = 1,2 -> 1
0,2 x 2 = 0,4 -> 0
0,4 x 2 = 0,8 -> 0
e si ricomincia.
E' chiaro che, non potendosi memorizzare un numero periodico, si ha perdita
di informazione.
Lo stesso problema (e da qui nasce lo stupore di chi affronta queste
problematiche sui PC) non si verifica sulle calcolatrici. Cio' per la
differente filosofia con cui operano le calcolatrici.
Quando andavo a scuola il professore di elettronica industriale ci spiego'
che le calcolatrici (almeno allora!) lavorano su una simulazione della base
dieci. in pratica 15 in binario sarebbe 1111, ma le calcolatrici memorizzano
0001 - 0101 (1 - 5)
In questo modo, nonostante i numeri siano rappresentati da 0 e 1 (i livelli
alto e basso dei transistor) le operazioni avvengono praticamente su base
dieci.
Ciao, Sib