Secondo questa pagina java.sun == è l'operatore di confronto di uguaglianza per i numeri in virgola mobile in Java.

Tuttavia, quando scrivo questo codice:

if(sectionID == currentSectionID)

nel mio editor ed eseguo analisi statiche, ottengo: "JAVA0078 Valori in virgola mobile rispetto a =="

Cosa c'è di sbagliato nell'utilizzo ==per confrontare i valori in virgola mobile? Qual è il modo corretto di farlo? 

il modo corretto di testare i float per "uguaglianza" è:

if(Math.abs(sectionID - currentSectionID) < epsilon)

dove epsilon è un numero molto piccolo come 0,00000001, a seconda della precisione desiderata.

I valori in virgola mobile possono essere disattivati ​​di un po ', quindi potrebbero non essere riportati esattamente uguali. Ad esempio, impostando un float su "6.1" e quindi stampandolo di nuovo, potresti ottenere un valore riportato di qualcosa come "6.099999904632568359375". Questo è fondamentale per il modo in cui i galleggianti funzionano; pertanto, non si desidera confrontarli usando l'uguaglianza, ma piuttosto il confronto all'interno di un intervallo, ovvero se la differenza del float con il numero con cui si desidera confrontarlo è inferiore a un certo valore assoluto.

Questo articolo sul registro offre una buona panoramica del perché questo è il caso; lettura utile e interessante.

Giusto per dare il motivo dietro ciò che dicono tutti gli altri.

La rappresentazione binaria di un float è piuttosto fastidiosa.

In binario, la maggior parte dei programmatori conosce la correlazione tra 1b = 1d, 10b = 2d, 100b = 4d, 1000b = 8d

Bene funziona anche nell'altro modo.

.1b = .5d, .01b = .25d, .001b = .125, ...

Il problema è che non esiste un modo esatto per rappresentare la maggior parte dei numeri decimali come .1, .2, .3, ecc. Tutto ciò che puoi fare è approssimativo in binario. Il sistema esegue un piccolo arrotondamento quando i numeri vengono stampati in modo da visualizzare .1 invece di .10000000000001 o .99999999999999 (che sono probabilmente vicini alla rappresentazione memorizzata come lo è .1)

Modifica dal commento: la ragione per cui questo è un problema sono le nostre aspettative. Ci aspettiamo che i 2/3 vengano sfumati a un certo punto quando li convertiamo in decimali, .7 o .67 o .666667 .. Ma non ci aspettiamo automaticamente che .1 venga arrotondato allo stesso modo di 2/3 - ed è esattamente quello che sta succedendo.

A proposito, se sei curioso il numero che memorizza internamente è una rappresentazione binaria pura usando una "Notazione scientifica" binaria. Quindi se gli dicessi di memorizzare il numero decimale 10.75d, memorizzerebbe 1010b per il 10 e .11b per il decimale. Quindi memorizzerebbe .101011 quindi salva alcuni bit alla fine per dire: spostare il punto decimale di quattro posizioni a destra.

(Anche se tecnicamente non è più un punto decimale, ora è un punto binario, ma quella terminologia non avrebbe reso le cose più comprensibili per la maggior parte delle persone che avrebbero trovato questa risposta di qualsiasi utilità.)

Cosa c'è di sbagliato nell'usare == per confrontare i valori in virgola mobile?

Perché non è vero 0.1 + 0.2 == 0.3

Penso che ci sia molta confusione attorno ai galleggianti (e ai doppi), è bene chiarirlo.

1. Non c'è nulla di intrinsecamente sbagliato nell'uso dei float come ID nella JVM conforme allo standard [*]. Se si imposta semplicemente l'ID float su x, non fare nulla con esso (cioè senza aritmetica) e successivamente testare y == x, andrà tutto bene. Inoltre non c'è nulla di sbagliato nell'usarli come chiavi in ​​una HashMap. Quello che non puoi fare è assumere uguaglianze come x == (x - y) + y, ecc. Detto questo, le persone di solito usano tipi interi come ID, e puoi osservare che la maggior parte delle persone qui è rimandata da questo codice, quindi per motivi pratici, è meglio aderire alle convenzioni . Nota che ci sono tanti doublevalori diversi quanti sono lunghi values, quindi non ottieni nulla usando double. Inoltre, generare "prossimo ID disponibile" può essere complicato con i doppi e richiede una certa conoscenza dell'aritmetica in virgola mobile. Non vale la pena.

2. D'altra parte, fare affidamento sull'uguaglianza numerica dei risultati di due calcoli matematicamente equivalenti è rischioso. Ciò è dovuto agli errori di arrotondamento e alla perdita di precisione durante la conversione da rappresentazione decimale a binaria. Questo è stato discusso a morte su SO.

[*] Quando ho detto "JVM conforme agli standard" volevo escludere alcune implementazioni JVM danneggiate dal cervello. Vedere questo .

Questo è un problema non specifico di Java. L'uso di == per confrontare due float / doppi / qualsiasi numero di tipo decimale può potenzialmente causare problemi a causa del modo in cui sono memorizzati. Un galleggiante a precisione singola (secondo lo standard IEEE 754) ha 32 bit, distribuito come segue:

1 bit - Segno (0 = positivo, 1 = negativo)
8 bit - Esponente (una rappresentazione speciale (bias-127) della x in 2 ^ x)
23 bit - Mantisa. Il numero di attuall che è memorizzato.

La mantisa è ciò che causa il problema. È un po 'come la notazione scientifica, solo il numero nella base 2 (binario) sembra 1.110011 x 2 ^ 5 o qualcosa di simile. Ma in binario, il primo 1 è sempre un 1 (tranne per la rappresentazione di 0)

Pertanto, per risparmiare un po 'di spazio di memoria (gioco di parole), IEEE ha deciso che l'1 dovrebbe essere assunto. Ad esempio, una mantisa di 1011 è davvero 1.1011.

Ciò può causare alcuni problemi con il confronto, specialmente con 0 poiché 0 non può essere rappresentato esattamente in un float. Questo è il motivo principale per cui == è scoraggiato, oltre ai problemi matematici in virgola mobile descritti da altre risposte.

Java ha un problema unico in quanto il linguaggio è universale su molte piattaforme diverse, ognuna delle quali potrebbe avere il proprio formato float unico. Ciò rende ancora più importante evitare ==.

Il modo corretto di confrontare due float (non specifici per lingua) per l'uguaglianza è il seguente:

if(ABS(float1 - float2) < ACCEPTABLE_ERROR)
    //they are approximately equal

dove ACCEPTABLE_ERROR è #defined o qualche altra costante uguale a 0.000000001 o qualunque precisione richiesta, come già menzionato Victor.

Alcune lingue hanno questa funzionalità o questa costante integrata, ma in genere è una buona abitudine.

Ad oggi, il modo semplice e veloce per farlo è:

if (Float.compare(sectionID, currentSectionID) == 0) {...}

Tuttavia, i documenti non specificano chiaramente il valore della differenza di margine (un epsilon dalla risposta di @Victor) che è sempre presente nei calcoli sui float, ma dovrebbe essere qualcosa di ragionevole in quanto fa parte della libreria di lingue standard.

Tuttavia, se è necessaria una precisione superiore o personalizzata, allora

float epsilon = Float.MIN_NORMAL;  
if(Math.abs(sectionID - currentSectionID) < epsilon){...}

è un'altra opzione di soluzione.

I valori dei punti di espansione non sono affidabili a causa dell'errore di arrotondamento.

Come tali, probabilmente non dovrebbero essere usati come valori chiave, come sectionID. Utilizzare invece numeri interi o longse intnon contiene abbastanza valori possibili.

Oltre alle risposte precedenti, dovresti essere consapevole che ci sono comportamenti strani associati -0.0fe +0.0f(sono ==ma non equals) e Float.NaN(è equalsma non== ) (speranza ho capito bene -! Argh, non lo fanno).

Modifica: controlliamo!

import static java.lang.Float.NaN;
public class Fl {
    public static void main(String[] args) {
        System.err.println(          -0.0f   ==              0.0f);   // true
        System.err.println(new Float(-0.0f).equals(new Float(0.0f))); // false
        System.err.println(            NaN   ==               NaN);   // false
        System.err.println(new Float(  NaN).equals(new Float( NaN))); // true
    }
} 

Benvenuti in IEEE / 754.

Ecco una discussione molto lunga (ma si spera utile) su questo e molti altri problemi in virgola mobile che potresti incontrare: Ciò che ogni scienziato informatico dovrebbe sapere sull'aritmetica in virgola mobile

Puoi usare Float.floatToIntBits ().

Float.floatToIntBits(sectionID) == Float.floatToIntBits(currentSectionID)

Prima di tutto, sono float o float? Se uno di questi è Float, dovresti usare il metodo equals (). Inoltre, probabilmente è meglio usare il metodo statico Float.compare.

Quanto segue utilizza automaticamente la massima precisione:

/**
 * Compare to floats for (almost) equality. Will check whether they are
 * at most 5 ULP apart.
 */
public static boolean isFloatingEqual(float v1, float v2) {
    if (v1 == v2)
        return true;
    float absoluteDifference = Math.abs(v1 - v2);
    float maxUlp = Math.max(Math.ulp(v1), Math.ulp(v2));
    return absoluteDifference < 5 * maxUlp;
}

Naturalmente, potresti scegliere più o meno di 5 ULP ("unità all'ultimo posto").

Se sei nella libreria di Apache Commons, la Precisionclasse ha compareTo()e equals()sia con epsilon che con ULP.

potresti volerlo ==, ma 123.4444444444443! = 123.4444444444442

Se * devi * usare i float, la parola chiave strictfp può essere utile.

http://en.wikipedia.org/wiki/strictfp

Due diversi calcoli che producono uguali numeri reali non producono necessariamente uguali numeri in virgola mobile. Le persone che usano == per confrontare i risultati dei calcoli di solito finiscono per essere sorprese da questo, quindi l'avvertimento aiuta a segnalare ciò che altrimenti potrebbe essere un bug sottile e difficile da riprodurre.

Hai a che fare con codice in outsourcing che userebbe float per cose denominate sectionID e currentSectionID? Solo curioso.

@Bill K: "La rappresentazione binaria di un float è piuttosto fastidiosa." Come mai? Come lo faresti meglio? Ci sono alcuni numeri che non possono essere rappresentati correttamente in nessuna base, perché non finiscono mai. Pi è un buon esempio. Puoi solo approssimarlo. Se hai una soluzione migliore, contatta Intel.

Come menzionato in altre risposte, i doppi possono avere piccole deviazioni. E potresti scrivere il tuo metodo per confrontarli usando una deviazione "accettabile". Però ...

Esiste una classe apache per confrontare i doppi: org.apache.commons.math3.util.Precision

Contiene alcune costanti interessanti: SAFE_MINe EPSILON, che sono le deviazioni massime possibili di semplici operazioni aritmetiche.

Fornisce inoltre i metodi necessari per confrontare, doppie uguali o rotonde. (usando ulps o deviazione assoluta)

In una riga di risposta posso dire che dovresti usare:

Float.floatToIntBits(sectionID) == Float.floatToIntBits(currentSectionID)

Per apprendere di più sull'uso corretto degli operatori correlati, sto elaborando alcuni casi qui: in generale, ci sono tre modi per testare le stringhe in Java. Puoi usare ==, .equals () o Objects.equals ().

Come sono differenti? == verifica la qualità di riferimento nelle stringhe, il che significa scoprire se i due oggetti sono uguali. D'altra parte, .equals () verifica se le due stringhe hanno lo stesso valore logicamente. Infine, Objects.equals () verifica eventuali null nelle due stringhe, quindi determina se chiamare .equals ().

Operatore ideale da usare

Bene, questo è stato oggetto di numerosi dibattiti perché ciascuno dei tre operatori ha il proprio insieme unico di punti di forza e di debolezza. Esempio, == è spesso un'opzione preferita quando si confronta il riferimento a un oggetto, ma ci sono casi in cui può sembrare che paragonino anche i valori di stringa.

Tuttavia, ciò che ottieni è un valore di caduta perché Java crea l'illusione che stai confrontando i valori, ma in realtà non lo sei. Considera i due casi seguenti:

Caso 1:

String a="Test";
String b="Test";
if(a==b) ===> true

Caso 2:

String nullString1 = null;
String nullString2 = null;
//evaluates to true
nullString1 == nullString2;
//throws an exception
nullString1.equals(nullString2);

Pertanto, è meglio utilizzare ciascun operatore durante il test dell'attributo specifico per cui è progettato. Ma in quasi tutti i casi, Objects.equals () è un operatore più universale, quindi l'esperienza degli sviluppatori web lo sceglie.

Qui puoi ottenere maggiori dettagli: http://fluentthemes.com/use-compare-strings-java/

Il modo corretto sarebbe

java.lang.Float.compare(float1, float2)

Un modo per ridurre l'errore di arrotondamento è utilizzare double anziché float. Ciò non risolverà il problema, ma ridurrà la quantità di errore nel programma e float non è quasi mai la scelta migliore. A PARER MIO.