Linguaggi - Programmazione - Calcolo numerico

[hfish]

e poi un numero a doppia precisione ha sempre 32 decimali di mantissa.
e tt i software devono restituire le 32 cifre in modo uguale.

immagina di avere una mantissa a 35 bit...
puoi scegliere di troncare a 32, di arrotondare il 32esimo bit verso l'alto o verso il basso

ecco che gia' hai TRE diversi modi di rappresentare il dato. non esiste un modo giusto e uno sbagliato... si prendono delle decisioni nello standard, e si rispettano dopo quando si implementa il tutto, oppure lo standard decide di lasciare libera scelta all'implementatore, che scegliera' quello che preferisce e si spera lo documenti

[hfish]

cmq accennavano prima, non si puo' pretendere di rappresentare un set infinito di numeri su un set finito, e tra l'altro MOLTO piccolo, di bit. per forza di cose e' necessario avere delle approssimazioni.

ogni linguaggio (ogni compilatore all'interno dello stesso linguaggio, addirittura) e' libero di trattare come meglio preferisce tutte quelle cose che sono lasciate all'implementatore dallo standard...

se in c provi a salvare la radice di 2 in un double e poi ne stampi il valore per 100mila volte, e' abbastanza probabile che tu ottenga parecchi valori diversi...

[Fractals87]

Si ma semplifichiamo l'esempio.
Js rappresenta un numero 0.851 in questo modo
Fortran rappresenta in doppia precisione il numero come 0.58099999999999996.
Secondo me questo è sbagliato.
Eppure da quanto si legge il Fortran è rinominato per calcoli numerici è un controsenso che nn capisco.

[MItaly]

In realtà la maggior parte dei linguaggi "sensati" su piattaforme mainstream internamente usa i double IEEE 754 (nel caso di JavaScript mi pare ci sia proprio nelle specifiche), che, fissate certe opzioni, hanno semantica perfettamente definita, esattamente per evitare questi problemi (=i conti devono essere riproducibili). Ci sono però altre fonti di indeterminazioni, specialmente su x86:

• se riscrivi il codice e alteri minimamente l'ordine delle operazioni i risultati possono variare; lavorando in floating point somma e prodotto non sono associativi ((a+b)+c non è necessariamente a+(b+c)), il prodotto non è distributivo e moltiplicare per l'inverso non è uguale a dividere, elevare x^n non è uguale a moltiplicare x per sé stesso n volte, eccetera;
• alla stessa maniera, se consenti all'ottimizzatore di ignorare queste peculiarità del FP (-funsafe-math-optimizations per i compilatori di famiglia gcc) al fine di aumentare la velocità di calcolo ti potresti ritrovare risultati diversi;
• anche rimanendo all'interno dell'IEEE 754, ci sono diverse opzioni di arrotondamento possibili per le varie operazioni; su x86, queste sono controllate dalla x87 control word; a seconda di come è impostata, i tuoi conti seguiranno regole diverse. Di solito questo non è un problema (normalmente un nuovo processo parte con un valore noto), ma se inizi a richiamare librerie che toccano la control word inizia un mondo di sofferenze (known offenders: DirectX, Delphi; la cosa è particolarmente odiosa perché se chiedi a Windows un file dialog e c'è registrata una shell extension scritta in Delphi ti viene sfanculata la control word). Lavorando in JavaScript in un browser probabilmente ti cucchi quello che passa il convento;
• il set di istruzioni x87 internamente opera con uno stack di valori a 80 bit (invece che a 64), per cui, a seconda di come il compilatore decide di gestire le operazioni (lasciando i valori sullo stack FPU o riportandoli in memoria per register spilling & co.) si va incontro ad arrotondamenti 80 -> 64 bit in momenti diversi dei conti, il che dà risultati differenti; la cosa è particolarmente tragica perché puoi rifare gli stessi conti partendo dagli stessi dati in due punti diversi del programma (o anche peggio: stessa funzione ma in un caso espansa inline, in un altro no) e ottenere risultati diversi tanto quanto basta per far fallire un test di uguaglianza; per questo problema normalmente i compilatori forniscono un qualche meccanismo per forzare l'arrotondamento ad ogni operazione (se non erro -ffloat-store su gcc & co.).

Il discorso degli 80 bit dovrebbe essere fortunatamente morto con SSE, ma tutto il resto rimane.

[Fractals87]

Fermo restando che la semantica delle operazioni è identica.
Da ciò che ho capito il tutto non dipende dal linguaggio ma bensi dalla FPU integrata nel processore.
Sicuramente l'architettura su cui sto lavorando è differente.
(Il programma fortran sta girando su una macchina virtuale dove sopra c'è linux centos 5 sul mio poratile)

il js viene eseguito sotto windows7sp164bit

Entrambi a 64Bit.

Ho comunque compreso sommariamente la realtà, oltre ad aver capito che il problema non è di facile risoluzione.
Provvederò a documentarmi adeguatamente (ora so cosa cercare).

Grazie mille MItaly per la precisa risposta.

[MItaly]

Sicuramente l'architettura su cui sto lavorando è differente.
(Il programma fortran sta girando su una macchina virtuale dove sopra c'è linux centos 5 sul mio poratile)

il js viene eseguito sotto windows7sp164bit

Entrambi a 64Bit.

Secondo me uno dei due emette istruzioni SSE, l'altro x87. Il JavaScript con cosa lo fai girare?

[panta1978]

Io programmo ed ho programmato in Matlab, Fortran, C, Basic... Sì, ci sono errori di troncamento.
Ma oggettivamente non mi hanno mai creato fastidio, basta progettare bene l'algoritmo...

[Fractals87]

Io programmo ed ho programmato in Matlab, Fortran, C, Basic... Sì, ci sono errori di troncamento.
Ma oggettivamente non mi hanno mai creato fastidio, basta progettare bene l'algoritmo...

Si ma se il tuo calcolo finale prevede una centinaia di calcoli intermedi, converrai con me che a furia di troncare l'errore sale a cifre significative.

Secondo me uno dei due emette istruzioni SSE, l'altro x87. Il JavaScript con cosa lo fai girare?

Il js gira su browser chrome (ultima versione) sotto un win7pro64 (Era questo che volevi sapere giusto?)

[panta1978]

Si ma se il tuo calcolo finale prevede una centinaia di calcoli intermedi, a meno di errori dovuti a sottrazioni tra numeri molto simili (bad design!) o operazioni simili, con 64-bit di precisione rimani comunque a valori accettabili.
Considera che la precisione del tuo calcolatore è con tutta probabilità maggiore di quella dei tuoi dati.

Se microscopici errori nell'input forniscono output errati, occorre stare attenti al codice...

[Fractals87]

non so che dire....
il codice l'ho controllato diverse volte e mi pare tt corretto anche sintassi matematica.
considera che il peggior numero con cui lavoro è 0.367713e-11
la formula che ho dovuto tradurre è questa

https://law.resource.org/pub/in/bis/...305.3.2003.pdf

Pagina 31 del pdf, 26 del documento

Proverò ad ricontrollare comunque il codice....