Newsgroup: it.comp.lang.visual-basic
Titolo: Visual basic e la matematica......

dove posso trovare un sito che parli di applicazioni scientifiche fatte con
il visual basic (matematica, fisica, ecc...)?
Grazie
--
Saxy The Madman
To be end of time


Per VB la matematica e' un'opinione...
Ricordo a tutti che CDbl(CSng(1.08))<>1.08
Se non ci credete fatene un debug.print...
Ciaotutti,
*

 Ricordo a tutti che CDbl(CSng(1.08))<>1.08
Purtroppo non è colpa di VB :(
La riconferma?
Scrivi in C
bool r = (((double)(float)(1.08) == (1.08)));
r = False!
Perchè  (double)(float)(1.08) = 1.08000004291534;
Purtroppo i valori a virgola mobile non sono affidabili.
Nei confronti poi non puoi fidarti dell'uso di tipi misti nelle stesse
operazioni/confronti.
Qualcuno del NG mi aveva dato un bell'indirizzo della SUN dove si spiegava
tutto il perchè e il percome...
Ciao


Si' ma e' evidentemente un bug del modo in cui vengono convertiti, perche'
il formato double NON ha come limite intrinseco l'impossibilita' di
formalizzare 1.08, dato che definendo una costante 1.08 as double si ha
1.08, quale che sia l'operazione compiuta...
Ciaotutti,
*

 Ciaotutti,
no purtroppo non è un bug........
in realtà il funzionamento in virgola mobile non è mai stato corretto.
Questo succede anche se usi assembler per microprocessori.
Sul sito SUN fai un search per i numeri reali e ne vedrai delle
belle..........
Ciao!!!!!
Marcello

 formalizzare 1.08
MA come cazzo parli :)))))))))))))))))))))))))  (pronunciata come si pronuncia "Ma come cazzo porti sti capilli" Zelig docet)
Ciao SImo
--
__________________
www.sasim.cjb.net

orca trota quanto siamo pignoli ragazzi...le vacanze vi hanno intestardito ! :)
cmq...nulla...da dire sul modo di scrivere....solo..un pò....direi ...mm....Banfoso...(non so se sapete cosa voglia dire..)
Salutoni....Simo
--
__________________
www.sasim.cjb.net


Ma che cavolo dici non è mica colpa di VB!!!
Anche se fai ste cose con Matlab (software per calcoli
matematici) o Derive succede.
Ma anche in C, Pascal etc etc.
Non è un limite software è un limite Hardware.
Numeri che sono rappresentabili con un numero finito di
cifre in decimale non è detto che lo siano in binario così
se converti un decimale in un binario perdi qualcosa e se lo riconverti
non è che ciò che perdi lo ritrovi.
                                                                    danilo
Se trovo un mio vecchio post dove spiegavo la cosa lo rimando.


Non mi convince.
Se 1.08 non fosse rappresentabile in double sarebbe diverso, ma siccome e'
rappresentabile in modo esatto sia in float/single sia in double e' evidente
che la conversione da single a double si inventa delle cifre e questo e'
male.
Scusa, se io scrivo una costante double del valore di 1.08 e sommo e
sottraggo a un altro double qualsiasi ho ancora 1.08 (purche' il double sia
dello stesso ordine di grandezza, altrimenti perdo di precisione e vado a
0), perche' se scrivo una costante single del valore di 1.08 e la converto
in double devo avere delle cifre in piu'?
Capirei se da double a single 1,0799999999999999 diventasse 1,8, ho ridotto
la precisione e perdo cifre, ma non e' che aumentandola debba trovare delle
cifre in piu'...
E' evidentemente un bug, perche' se posso convertire il numero decimale in
un double corretto e il numero single in un decimale corretto dovrei poter
convertire il numero single in un double corretto, non trovi?
Tant'e' vero che
debug.print cdbl(cstr(csng(1.08)))
restituisce correttamente 1.08
Ciaotutti,
*

 Tant'e' che cdbl(cstr(csng(1.08))) restituisce correttamente 1.08
Ti sembra, perché il numero di cifre del numero (1.08) č basso,
ma č comunque un valore approssimato rispetto al contenuto della
memoria. Se tu avessi un numero con un numero infinito di cifre
(esempio: PI/4) la conversione che dici peggiorerebbe ancora di
piů le cose; perderesti una cifra significativa in piů rispetto
alla conversione diretta.
Ciao.
Mauro


Si ma il problema e' che la conversione da single a double aggiunge le cifre
nel posto sbagliato!
In sostanza dovrebbe scalare il numero di tante posizioni quante sono le
cifre aggiunte, quindi incrementare l'esponente in modo da riavere lo stesso
1.08 che c'era nel single.
A ritroso la conversione dovrebbe tenere conto del fatto che le cifre
iniziali sono zeri e riscalare il numero in modo da mantenere tutte le cifre
significative.
Gli zeri prima della virgola non sono significativi, quelli dopo la virgola
si', e a quanto pare la conversione aggiunge zeri (binari) dopo la virgola e
non prima, anche se non ne comprendo il motivo visto che logica vorrebbe
facesse il contrario.
Ciaotutti,
*

Come giustamente rilevato, le limitazioni dei tipi in virgola mobile
sono fisiche e non dipendono dalla follia di qualche ingegnere
dell' Intel.
Su MSDN ci sono tre articoli che aiutano a schiarirsi le idee ed
approfondiscono i concetti gia' esposti da danilo e Mauro:
1.
HOWTO: Work Around Floating-Point Accuracy/Comparison Problems 
Q69333
http://support.microsoft.com/support/kb/articles/Q69/3/33.ASP
da cui estraggo questo incipit:
To reliably test whether two floating-point variables or expressions are equal 
(using IEEE format or MBF), you must subtract the two variables being compared 
and test whether their difference is less than a value chosen at the limits 
of significance for single or double precision. 
NO OTHER TEST FOR EQUALITY WILL BE RELIABLE. 
2.
INFO: IEEE Floating-Point Representation and MS Languages 
Q36068
http://support.microsoft.com/support/kb/articles/Q36/0/68.ASP
3.
(Complete) Tutorial to Understand IEEE Floating-Point Errors 
Q42980
http://support.microsoft.com/support/kb/articles/Q42/9/80.ASP
 
hth, hal

 Guardalo in binario: 1.08 Dec = 1.(00010100011110101110) Bin
Per la precisione, viene memorizzato in standard IEEE,
in pratica hai 64 bit, uno per il segno, 11 per l'esponente e
52 per la mantissa; quindi 1.08 viene rappresentato come:
0 01111111111 0001010001111010111000010100011110101110000101001000
Notare, rispetto al periodo riportato sopra, l'approssimazione delle
ultime cifre.
-- 
Samuele Battarra
prova il mio newsreader:
http://digilander.iol.it/battarsa/programmi/news/


Porc.... Vuoi dire che l'1 iniziale e' sottinteso?
Questo spiegherebbe l'errore: non si puo' scalare se c'e' un 1 iniziale
sottinteso, percui la cifra di guardia, che in single viene interpretate
correttamente, in double viene considerata cifra valida...
Ciaotutti,
*

*Alessandro* ha scritto:

Cioe'?
L'uno iniziale e sottointeso sia nei double che nei single.



Quando sei costretto ad approsimare (in qualunque base) si tende a
considerare le ultime X cifre come qualcosa di relativamente imperfetto,
danneggiato da errori di troncamento o arrotondamento di qualche tipo.
Quando si fanno calcoli di una certa complessita' si tende a utilizzare una
precisione piu' alta del risultato finale e alla fine ad arrotondare tale
risultato, cosa che per quanto possa sembrare strano garantisce una miglior
precisione che usare il risultato non arrotondato (vedi 1.08 che viene letto
come 1.08 quando viene convertito direttamente in single o in double)
Il formato single ha n cifre di mantissa, il formato double qualcosa come il
doppio, diciamo
n+m; il modo piu' corretto di tradurre un formato nell'altro sarebbe
trasformare
s nnnnnnnnnn eeee
in
s 0000000nnnnnnnnnn eeeeee
usando un numero m di zeri posti prima della virgola e scalando l'esponente
di un uguale numero m, in modo che la cifra di guardia del single venga
riportata come cifra di guardia anche nel double. Questo pero' non e'
possibile se il primo 1 e' sottinteso, il che impone di trasformare
s nnnnnnnnnn eeee
in
s nnnnnnnnnn0000000 eeeeee
aggiungendo zeri in fondo e trasformando la cifra si guardia in una cifra
valida, il che introduce quello 00000084 o quanto era che si ritrova nella
conversione da single a double di 1.08...
Commento finale:
DOH! :P
Ciaotutti,
*