Perché la modifica dell'ordine di somma restituisce un risultato diverso?

Perché la modifica dell'ordine di somma restituisce un risultato diverso?

23.53 + 5.88 + 17.64 = 47.05

23.53 + 17.64 + 5.88 = 47.050000000000004

Sia Java che JavaScript restituiscono gli stessi risultati.

Capisco che, a causa del modo in cui i numeri in virgola mobile sono rappresentati in binario, alcuni numeri razionali ( come 1/3 - 0.333333 ... ) non possono essere rappresentati con precisione.

Perché la semplice modifica dell'ordine degli elementi influisce sul risultato?

Forse questa domanda è stupida, ma perché cambiare semplicemente l'ordine degli elementi influenza il risultato?

Cambierà i punti in cui i valori sono arrotondati, in base alla loro grandezza. Come esempio del tipo di cosa che stiamo vedendo, facciamo finta che invece del punto mobile binario, stessimo usando un tipo decimale a virgola mobile con 4 cifre significative, in cui ogni aggiunta viene eseguita con precisione "infinita" e quindi arrotondata a il numero rappresentabile più vicino. Ecco due somme:

1/3 + 2/3 + 2/3 = (0.3333 + 0.6667) + 0.6667
                = 1.000 + 0.6667 (no rounding needed!)
                = 1.667 (where 1.6667 is rounded to 1.667)

2/3 + 2/3 + 1/3 = (0.6667 + 0.6667) + 0.3333
                = 1.333 + 0.3333 (where 1.3334 is rounded to 1.333)
                = 1.666 (where 1.6663 is rounded to 1.666)

Non abbiamo nemmeno bisogno di numeri non interi perché questo sia un problema:

10000 + 1 - 10000 = (10000 + 1) - 10000
                  = 10000 - 10000 (where 10001 is rounded to 10000)
                  = 0

10000 - 10000 + 1 = (10000 - 10000) + 1
                  = 0 + 1
                  = 1

Ciò dimostra forse più chiaramente che la parte importante è che abbiamo un numero limitato di cifre significative , non un numero limitato di cifre decimali . Se potessimo sempre mantenere lo stesso numero di cifre decimali, almeno con l'aggiunta e la sottrazione, andremmo bene (purché i valori non traboccino). Il problema è che quando si arriva a numeri più grandi, si perdono informazioni più piccole, in questo caso il 10001 viene arrotondato a 10000. (Questo è un esempio del problema che Eric Lippert ha notato nella sua risposta .)

È importante notare che i valori sulla prima riga del lato destro sono gli stessi in tutti i casi, quindi anche se è importante capire che i tuoi numeri decimali (23.53, 5.88, 17.64) non saranno rappresentati esattamente come doublevalori, questo è solo un problema a causa dei problemi sopra indicati.

Ecco cosa sta succedendo in binario. Come sappiamo, alcuni valori in virgola mobile non possono essere rappresentati esattamente in binario, anche se possono essere rappresentati esattamente in decimali. Questi 3 numeri sono solo esempi di questo fatto.

Con questo programma ho prodotto le rappresentazioni esadecimali di ciascun numero e i risultati di ogni aggiunta.

public class Main{
   public static void main(String args[]) {
      double x = 23.53;   // Inexact representation
      double y = 5.88;    // Inexact representation
      double z = 17.64;   // Inexact representation
      double s = 47.05;   // What math tells us the sum should be; still inexact

      printValueAndInHex(x);
      printValueAndInHex(y);
      printValueAndInHex(z);
      printValueAndInHex(s);

      System.out.println("--------");

      double t1 = x + y;
      printValueAndInHex(t1);
      t1 = t1 + z;
      printValueAndInHex(t1);

      System.out.println("--------");

      double t2 = x + z;
      printValueAndInHex(t2);
      t2 = t2 + y;
      printValueAndInHex(t2);
   }

   private static void printValueAndInHex(double d)
   {
      System.out.println(Long.toHexString(Double.doubleToLongBits(d)) + ": " + d);
   }
}

Il printValueAndInHexmetodo è solo un aiuto per la stampante esadecimale.

L'output è il seguente:

403787ae147ae148: 23.53
4017851eb851eb85: 5.88
4031a3d70a3d70a4: 17.64
4047866666666666: 47.05
--------
403d68f5c28f5c29: 29.41
4047866666666666: 47.05
--------
404495c28f5c28f6: 41.17
4047866666666667: 47.050000000000004

I primi 4 numeri sono x, y, z, e s's rappresentazioni esadecimali. Nella rappresentazione in virgola mobile IEEE, i bit 2-12 rappresentano l' esponente binario , ovvero la scala del numero. (Il primo bit è il bit di segno e i bit rimanenti per la mantissa .) L'esponente rappresentato è in realtà il numero binario meno 1023.

Gli esponenti per i primi 4 numeri vengono estratti:

    sign|exponent
403 => 0|100 0000 0011| => 1027 - 1023 = 4
401 => 0|100 0000 0001| => 1025 - 1023 = 2
403 => 0|100 0000 0011| => 1027 - 1023 = 4
404 => 0|100 0000 0100| => 1028 - 1023 = 5

Prima serie di aggiunte

Il secondo numero ( y) è di grandezza minore. Quando si aggiungono questi due numeri per ottenere x + y, gli ultimi 2 bit del secondo numero ( 01) vengono spostati fuori dall'intervallo e non figurano nel calcolo.

La seconda aggiunta aggiunge x + ye zaggiunge due numeri della stessa scala.

Seconda serie di aggiunte

Qui, si x + zverifica per primo. Sono della stessa scala, ma producono un numero che è più in alto nella scala:

404 => 0|100 0000 0100| => 1028 - 1023 = 5

La seconda aggiunta aggiunge x + ze y, e ora vengono rilasciati 3 bit yper aggiungere i numeri ( 101). Qui, ci deve essere un arrotondamento verso l'alto, perché il risultato è il prossimo numero in virgola mobile verso l'alto: 4047866666666666per la prima serie di aggiunte rispetto 4047866666666667alla seconda serie di aggiunte. Tale errore è abbastanza significativo da mostrare nella stampa del totale.

In conclusione, fai attenzione quando esegui operazioni matematiche sui numeri IEEE. Alcune rappresentazioni sono inesatte e diventano ancora più inesatte quando le scale sono diverse. Aggiungi e sottrai numeri di scala simile se puoi.

La risposta di Jon è ovviamente corretta. Nel tuo caso l'errore non è più grande dell'errore che accumuleresti facendo qualsiasi semplice operazione in virgola mobile. Hai uno scenario in cui in un caso ricevi zero errori e in un altro ricevi un piccolo errore; non è uno scenario così interessante. Una buona domanda è: esistono scenari in cui la modifica dell'ordine dei calcoli passa da un piccolo errore a un errore (relativamente) enorme? La risposta è inequivocabilmente sì.

Considera ad esempio:

x1 = (a - b) + (c - d) + (e - f) + (g - h);

vs

x2 = (a + c + e + g) - (b + d + f + h);

vs

x3 = a - b + c - d + e - f + g - h;

Ovviamente nell'aritmetica esatta sarebbero gli stessi. È divertente cercare di trovare valori per a, b, c, d, e, f, g, h in modo tale che i valori di x1 e x2 e x3 differiscano per una grande quantità. Vedi se riesci a farlo!

Questo in realtà copre molto più di Java e Javascript e probabilmente influenzerebbe qualsiasi linguaggio di programmazione usando float o double.

In memoria, i punti mobili utilizzano un formato speciale lungo le linee di IEEE 754 (il convertitore fornisce una spiegazione molto migliore di quanto io possa).

Comunque, ecco il convertitore float.

http://www.h-schmidt.net/FloatConverter/

La cosa sull'ordine delle operazioni è la "finezza" dell'operazione.

La tua prima riga produce 29,41 dai primi due valori, che ci dà 2 ^ 4 come esponente.

La tua seconda riga produce 41,17 che ci dà 2 ^ 5 come esponente.

Stiamo perdendo una cifra significativa aumentando l'esponente, che probabilmente cambierà il risultato.

Prova a spuntare l'ultimo bit all'estrema destra per attivare e disattivare 41.17 e puoi vedere che qualcosa di "insignificante" come 1/2 ^ 23 dell'esponente sarebbe sufficiente a causare questa differenza in virgola mobile.

Modifica: per quelli di voi che ricordano cifre significative, questo rientra in quella categoria. 10 ^ 4 + 4999 con una cifra significativa di 1 sarà 10 ^ 4. In questo caso, la cifra significativa è molto più piccola, ma possiamo vedere i risultati con .00000000004 ad esso collegato.

I numeri in virgola mobile sono rappresentati utilizzando il formato IEEE 754, che fornisce una dimensione specifica di bit per la mantissa (significato). Sfortunatamente questo ti dà un numero specifico di "blocchi frazionari" con cui giocare, e alcuni valori frazionari non possono essere rappresentati con precisione.

Ciò che sta accadendo nel tuo caso è che nel secondo caso, probabilmente l'aggiunta sta incontrando un problema di precisione a causa dell'ordine in cui le aggiunte vengono valutate. Non ho calcolato i valori, ma potrebbe essere per esempio che 23.53 + 17.64 non possano essere rappresentati con precisione, mentre 23.53 + 5.88 possono.

Purtroppo è un problema noto che devi solo affrontare.

Credo che abbia a che fare con l'ordine di evacuazione. Mentre la somma è naturalmente la stessa in un mondo matematico, nel mondo binario invece di A + B + C = D, è

A + B = E
E + C = D(1)

Quindi c'è quel passaggio secondario in cui i numeri in virgola mobile possono scendere.

Quando cambi l'ordine,

A + C = F
F + B = D(2)