Newsgroup: it.comp.lang.javascript
Titolo: parseFloat : Why do I get the wrong answer

parseFloat : Why do I get the wrong answer
I am trying to calculate a total of dynamically created text boxes. I am
getting the wrong values when I use the "parseFloat" function.
The Code:
~~~~~~~~~
var f = document.forms.item("frmCalculate")
  var total = 0;
  for (var i = 0; i < f.length; i++)
  {
    var e = f.elements(i)
    if (
e.name
 == "Per_Value")
    {
      total += parseFloat(e.value)      //Tried parseFloat(e.value,10)
      alert(total)
    }
  }
  alert(total)
The Values:
~~~~~~~~~~~
   1.  62.84
   2.  32.43
   3.  4.73
The result:
~~~~~~~~~~~
   100.00000000000001
The function works, and I know the result should be 100, but why is it not??
See:
http://www.experts-exchange.com/Web/Web_Languages/JavaScript/Q_20343444.html

real convertion, pc intel was born with this issue....
total=Math.round(total*100)/100;

 real convertion, pc intel was born with this issue....
Il Pentium non c'entra nulla, e'che JS fa le operazioni in binario.
Infatti ottieni gli stessi risultati anche su Mac (prova a fare la 
sottrazione 4.72-4 e stamparti il risultato)
Esegui la stessa operazione in VBS, su Pentium, non hai di tali 
"problemi" (anche se e' una definizione impropria).
-- 
C'ya,
ZER0
  :. job profile - coder.gfxer.webDesigner
"When you have eliminated the impossible, whatever remains,
however improbable, must be the truth." (S.H.)

Intendevo dire che è un problema che avevo anche ai tempi del pascal nei
calcoli in virgola mobile, e che quindi "abbraccia" tutti i personal
computer di ogni generazione

 ha
scritto:
Ho malinterpretato io la risposta, allora, scusami (non me ne stupisco,
ultimamente sono un po' rintro per via del sonno :) ), ma in ogni caso e' un
problema relativo alla matematica binaria e non tanto di "pc intel",
potrebbe essere fuorviante.
--------------------------------
Inviato via 
http://usenet.libero.it

 "problemi" (anche se e' una definizione impropria).
Non posso verificare questa affermazione, però qualche dubbio ce l'ho. Molti
linguaggi mascherano bene il risultato limitando il numero di cifre
visualizzate.
Solo i linguaggi che adottano la codifica BCD sono esenti da questi errori.
Purtroppo questa codifica rallenta molto le operazioni di calcolo per cui
viene evitata. A mia memoria solo il basic TI (Texas Instruments) adottava
questa codifica. La Borland metteva a disposizione dei programmatori Pascal
un pacchetto supplementare chiamato Turbo BCD. Librerie simili sono
disponibili anche per altri compilatori.
Maurizio.

 Non posso verificare questa affermazione, perň qualche dubbio ce l'ho.
Se ti riferisci al fatto che 4.72-4 su JS restituisce 0.7199999999999997
mentre con VBS restituisce 0.72, il tuo dubbio viene dissolto dai dati di
fatto.
Se anche non hai una macchina wintel, non credo farai fatica a trovare un
amico che possa farti questo piccolo test, o una macchina su cui testarlo
(puoi sempre mettere on line una paginetta e accederci da altra sede).


 fatto.
Non dubitato di quello che dicevi, ma della presunta maggior precisione del
VBS, almeno in questo caso. Quello che riporti, poi, non è un dato di fatto.
Niente impedisce che VBS abbia in memoria lo stesso numero 0.71999... e
visulizzi il numero corretto. Questo avviene solo perché in quasi tutti i
linguaggi le istruzioni di stampa non visualizzano tutte le cifre del
numero. Ad esempio, nel C, la semplice istruzione:
    printf("%f", 4.72 - 4)
darebbe risultato 0.72, perché di default le cifre visualizzate sono 6. Ma
se chiedo di visualizzare un numero maggiore di cifre con printf("%20.18f",
4.72 - 4), che dovrebbe mostrare 18 cifre dopo la virgola, vengono fuori le
magagne.
Anche le semplici calcolatrici evitano che venga visualizzato un risultato
così strano visualizzando sempre una cifra in meno di quelle effettivamente
disponibili.
Una volta usavo il seguente trucco per vedere se il risultato visualizzato
corrispondesse a  quello in memoria: moltiplicavo per un multiplo di 10 in
modo da eliminare tutte le cifre decimali (100 in questo caso); poi toglievo
la parte intera. Il risultato dovrebbe venire 0 se il numero in memoria e
quello visualizzato coincidono. Non sono sicuro che questo trucco funzioni
sempre, però puoi provare:
    a = 4.72 - 4;
    a = a * 100;
    a = a - 72
e vedi che succede.
La mia certezza è che 4.72 non è ben rappresentabile come potenza di 2, VBS
o no, a meno che non si usi il BCD. Ma non mi risulta che VBS usi BCD.
Ritengo, poi, che una grossa mancanza del js è un'istruzione di output
formattato presente in quasi tutti i linguaggi.
Maurizio.

 Niente impedisce che VBS abbia in memoria lo stesso numero 0.71999...
Quello che riporto E' un dato di fatto.
Come dici tu, niente impedisce che il VBS abbia in memoria lo stesso numero,
ma E' un dato di fatto che JS ti *restituisce* 0.7199999999999997 mentre VBS
*restituisce* 0.72.
E questo io ho detto, ne' piu' ne' meno.
Non mi sono addentrato in questioni prettamente tecniche, sei tu che hai
preso tutt'altra strada da questo thread :)
Evidentemente, hai frainteso cio' che ho detto e siamo finiti a parlare di
due cose ben diverse.


 computer di ogni generazione
Ti riferisci ai bug nella FPU dei primi Pentium75/90?
Non credo che sia quello il caso, ha ragione Zer0 ed il problema, se ben 
ricordo, e' insito nella rappresentazione binaria dei numeri (c'era anche 
qualche post di NEO al riguardo)
In ogni caso la cosa e' ben documentata nelle FAQ della KnowledgeBase di 
Netscape... se solo riuscissi a trovare la URL :-(
-- 
Ciao, Riccardo
------------------------------------------------------------------------
http://www.jsdir.com
 ---- Bring Your Site To Life!!!!
------------------------------------------------------------------------
http://www.dev2dev.it
 - La rete ha connesso nuove particelle - D2D006
------------------------------------------------------------------------
 ----> itALY = it <----