Double e approssimazioni

[RenzoDF]

L'approssimazione non e` un problema, quello che non va e` che a 32 bit e a 64 bit ho valori diversi.

diversi per 1 parte su 10^15 ? ... per me, ma anche per il JPL quei due valori sono coincidenti

Ti riposto un video interessante sull'argomento
http://videosift.com/video/IBM-Powers-O ... ence-video
... una volta che l'avrai visto, vedrai che saranno UGUALI anche per Te

[Berello]

Luca, sei sicuro che la differenza tra i due risultati sia dovuta a differenze di approssimazione?
Hai detto che parti da numeri diversi sulle due macchine virtuali; la differenza nel risultato non potrebbe essere dovuta a quello?
Prova ad esempio a partire dagli stessi numeri sulle due macchine virtuali e vedi se il risultato che ottieni è ancora diverso. Probabilmente il problema non è in quell'operazione che hai segnalato, ma nelle operazioni precedenti, che generano le coordinate dei punti. Non ne sono sicuro, ma fai una prova e lo scopriremo.

Da quel che ricordo, il double è definito secondo lo standard IEEE754 e la sua precisione è definita dallo standard. Quindi dovrebbe essere la stessa precisione, ovunque questo standard si applicato.
Tant'è vero che un double occupa 64 bit sia su macchine a 32 bit, sia su macchine a 64 bit.

Fammi sapere!

[posta10100]

diversi per 1 parte su 10^15 ? ... per me, ma anche per il JPL quei due valori sono coincidenti

Anche per me sono uguali, ma la macchina non la pensa allo stesso modo...

Ti riposto un video interessante sull'argomento

Purtroppo da qui i video non si vedono, lo guardo stasera!

Tant'è vero che un double occupa 64 bit sia su macchine a 32 bit, sia su macchine a 64 bit.

Infatti suona male anche a me.

Hai detto che parti da numeri diversi sulle due macchine virtuali; la differenza nel risultato non potrebbe essere dovuta a quello?

Se su linux a 64 bit, al posto di usare la jvm a 64 bit uso quella a 32 bit il risultato e` uguale a win.
Quindi, che sia nel punto che ho segnalato io o in un altro punto, purtroppo sempre di una differenza di approssimazione si tratta.

Prova ad esempio a partire dagli stessi numeri sulle due macchine virtuali e vedi se il risultato che ottieni è ancora diverso.

Adesso faccio anche quella prova, ma non sono molto fiducioso...

[RenzoDF]

diversi per 1 parte su 10^15 ? ... per me, ma anche per il JPL quei due valori sono coincidenti

Anche per me sono uguali, ma la macchina non la pensa allo stesso modo...

Io continuo a non capire, comunque ...

sta a te "convincerla" ... credi che il martello lo abbiano inventato per che scopo ?

[posta10100]

credi che il martello lo abbiano inventato per che scopo ?

Per darlo in testa a chi so io!
Berello aveva ragione.
La differenza e` dovuta a quella parte su n-mila che differenziava i 2 punti.
Il problema ora e` che ho trovato la causa: le funzioni sin e cos restituiscono risultati diversi a seconda della jvm!
Ecco il codice di test (manca la parte del confronto delle stringhe ma non e` importante).

Codice: Seleziona tutto

   
public void testJVM() throws Exception {
        double angleDelta = Math.PI / 28.0;
        String cosValues = "";
        String sinValues = "";
        for (int i = 0; i < 28 * 2; i++) {
            cosValues += Math.cos(i * angleDelta) + "\n";
            sinValues += Math.sin(i * angleDelta) + "\n";
        }
}

Il valore di su jvm a 32 bit e` 0.8467241992282841, a 64 bit vale 0.8467241992282842.
Il valore di su jvm a 32 bit e` 0.3302790619551671, a 64 bit vale 0.33027906195516704.

Vado a cercare un martello piu` grande, quello che ho non basta.
Grazie a tutti!

[Berello]

Sono andato a cercare sulle API di Java; per Math.sin() e Math.cos() dice: "The computed result must be within 1 ulp of the exact result. Results must be semi-monotonic."
E "ulp" significa "unit of least precision".
Sarà questo il motivo per cui il risultato è diverso su macchine a 32 bit o a 64 bit? Eppure a mio parere non dovrebbe.
A questo punto, potresti ridefinire delle tue funzioni sin() e cos() (magari semplicemente troncando quelle fornite da Java). Sarebbe comunque approssimato, ma così dovresti ottenere lo stesso risultato in 32 e in 64 bit.

Vedi anche questo!

[xyz]

I calcoli in float point nelle architetture Intel differiscono se calcolati con la FPU o con le SSE. Di solito i programmi a 32 bit sono compilati con utilizzo della FPU la quale calcola sempre con una precisione di 80 bit (long long double, estensione proprietaria del IEEE-754) e poi tronca a 64 bit (double) o 32 bit (float) a seconda del dato richiesto. Con l'avvento delle CPU a 64 bit e l'introduzione dei calcoli con il set di istruzioni SSE (se abilitati in fase di compilazione) i numeri float point sono calcolati con una precisione di 64 bit (standard IEEE-754) quindi possono differire di poco rispetto ai calcoli fatti con la FPU.

Il tuo problema di risolve semplicemente imponendo un arrotondamento ad un numero sensato di decimali, ad esempio consideri solo 4 cifre decimali.

[posta10100]

A questo punto, potresti ridefinire delle tue funzioni sin() e cos() (magari semplicemente troncando quelle fornite da Java)

Ho fatto giusto questo, ora da lo stesso risultato.

Eppure a mio parere non dovrebbe.

Anche secondo me e` non dovrebbe, anzi non deve. Pazienza l'importante e` che ora funziona.

I calcoli in float point nelle architetture Intel differiscono...

Ecco il motivo!

Grazie, si imparano sempre cose nuove!

[RenzoDF]

Come ha già sottolineato xyz anch'io il problema non lo vedo proprio, se non come semplice curiosità !

BTW se avessi scritto un risultato con tutte quelle cifre significative (impossibile per il mio regolo ) il mio Prof. di Elettrotecnica mi avrebbe messo un 2, anche con tutto il compito corretto

....
Il numero di cifre significative sarebbero invece stato importante, per esempio, per questo calcolo
http://blog.modernmechanix.com/2009/11/ ... t-numbers/

[posta10100]

Vediamo di spiegare il motivo per cui per me è importante avere lo stesso risultato su tutte le jvm.
Ho implementato dei test (JUnit test) che lanciano una serie di metodi java confrontando poi il risultato con un risultato atteso.

Se supponiamo io stia testando il metodo Math.cos, con il metodo di test che ho postato in [15].
La stringa cosValues alla fine del ciclo contiene tutti i valori restituiti da Math.cos.
Questa stringa la confronto con una nota, se coincidono va tutto bene, se ci sono differenze qualcosa non funziona come dovrebbe.
Se tra una jvm e l'altra il valore di Math.cos cambia, allora anche la stringa cambia e il test fallisce anche se il codice scritto è corretto.
Supponiamo ora che il valore restituito da Math.cos viene utilizzato per ricavare i punti su di una ellisse.
Se tra una jvm e l'altra i valori del coseno cambiano allora anche i punti sull'ellisse saranno leggermente diversi e tutti i metodi di test dell'ellisse falliscono.

Probabilmente vi ho confuso ancora di più le idee, ma questo è il motivo per cui per me è importante avere lo stesso risultato su tutte le jvm.