Newsgroup: it.comp.lang.javascript
Titolo: convertire formati numerici di sistemi diversi

Ho una tabella che riporta valori in ï¿œ secondo la convenzione italiana 
(virgola separatore decimale). Quale ï¿œ il modo piï¿œ semplice per farne 
leggere il contenuto a javascript memorizzandolo in un array numerico? 
Cioï¿œ, per trasformare 1.234,56 in 1234.56?
 

 Cioè, per trasformare 1.234,56 in 1234.56?
 
Il dato deve essere sempre separato dalla sua rappresentazione. Quindi
dovresti avere l'array numerico "up front", ovvero i tuoi dati
dovrebbero essere già numeri e non stringhe. E poi, in fase di
visualizzazione, formattarlo come si preferisce.
 
Per intenderci, quindi, se usi un DB e hai questi dati memorizzati come
stringhe, dovresti averceli come numeri. Se non puoi modificare il DB,
dovrebbe essere una cosa fatta lato server. Se proprio l'unica cosa che
puoi modificare è il client, e sei certo che il formato che ti arriva è
sempre nella forma 1.234,56, allora la cosa piú semplice è eliminare
ogni possibile punto, sostituire la virgola con un punto, e usare
l'operatore unario. Anche questa operazione però, la farei appena i dati
vengono restituiti, e non quando sono ormai già scritti nell'HTML (lo
specifico perché ignoro se tu ti riferisca a una tabella HTML o una
tabella di un DB, nel qual caso però sarebbe stato piú corretto
specificare il tipo di dati effettivamente restituito – JSON, XML, etc).
 
Ma intendiamoci, una situazione di questo genere è un errore di design,
e andrebbe corretto questo errore piuttosto che i sintomi. A meno che tu
non stia, chessò, creando un add-on che modifica pagine di terzi che non
hanno la conversione in altre valute (quindi è probabile che l'unica
fonte dati alla quale puoi accedere è l'HTML).
 
 

 Cioè, per trasformare 1.234,56 in 1234.56?
 
Assicurati che siano tutti in formato corretto (quindi con ,00 nei 
decimali), e poi rimuovi ogni punto o virgola. Così diventa 123456.
 
In questo modo li passi interi e non rischi di perdere precisione nella 
rappresentazione decimale. Fai tutti i calcoli con aritmetica intera, e 
solo quando li stampi dividi per 100 (o aggiungi una virgola prima delle 
ultime due cifre e un punto ogni 3 successive)
 
Bye.

 rappresentazione decimale. Fai tutti i calcoli con aritmetica intera,
 
D'accordo, non parli solo di visualizzazione, ma di calcoli successivi.
Ma in questo senso bisognerebbe avere tutti i calcoli di qualsiasi
genere in notazione a virgola fissa – e, tra l'altro, come dicevamo, JS
non ha interi – e a meno che non vi siano problemi di precisione che non
vengano risolti in fase di visualizzazione dal `toFixed`.

 decimali?
 
Visto che parlava di trasformarli sul server per mandarli a JS, senza 
specificare il linguaggio lato server, per me la cosa più sicura è 
convertire tutto in intero, e fare i calcoli così.
 
Mi è capitato spesso, per esempio nel calcolo dell'IVA, di trovarmi 
numeri periodici. Ma anche prendendo dati di prezzi da un form su una 
macchina a 32bit, un paio di volte mi è capitato che approssimasse di 1 
cent o di un milionesimo di euro. :)
 
Da allora trasformo sempre le valute in interi.
 
Bye.
 

 cent o di un milionesimo di euro. :)
 
Per quali cifre? A me non è mai capitato niente del genere; tutti i
problemi di precisione che ho avuto sono sempre stati trascurabili, ma è
anche vero che non ho mai fatto calcoli che toccassero tetti superiori
ai limiti numerici sulle macchine/linguaggi in questione (JS in primis),
almeno negli ultimi decenni.
 
Per intenderci, il piú che potevo avere erano cose come `5.7 - 4` uguale
a `1.7000000000000002`, ma avendo la precisione a due decimali era
appunto trascurabile in quanto le operazioni e i numeri su cui lavoravo
non si accumulavano.
È anche vero che non lavoro su questo genere di cose da diverso tempo,
quindi può darsi che mi sfugga qualcosa. :)
 
Già JS si "mangia" il tetto massimo di un intero, perché considera tutto
float, in generale – almeno su client, appunto – eviterei di "mangiare"
altre due cifre a meno che non ci siano ragioni specifiche – tipo la
sicurezza che l'errore di precisione non è trascurabile.

 fonte dati alla quale puoi accedere è l'HTML).
 
E' esattamente questa la situazione, quindi devo necessariamente 
assumere di partire dal formato html.
Mi spiace avere omesso l'informazione causando l'equivoco.
Grazie per tutte le risposte.
 

 Grazie per tutte le risposte.
 
De nada.
 

 non si accumulavano.
 
Il problema non era tanto di precisione nei calcoli, quanto estetico. Era 
un backend per uno shop, e quando inserivano cifre tipo 4.89 gli scriveva 
4.888888888888889 (o roba del genere, non ricordo la cifra precisa).
 
All'epoca la cosa più semplice e sicura per evitare gli arrotondamenti 
della conversione in fp binario, era di salvare tutto come intero. Quando 
dovevo fare calcoli li facevo comunque su interi, e per la 
rappresentazione a volte andavo di stringhe. :)
 
Bye.

 rappresentazione a volte andavo di stringhe. :)
 
Beh, la rappresentazione – laddove s'intende visualizzazione – dovrebbe
comunque essere stringa. :) O in ogni caso alla fine viene visualizzato
come stringa (l'HTML appunto quello è).