De acuerdo con esta página java.sun == es el operador de comparación de igualdad para números de coma flotante en Java.

Sin embargo, cuando escribo este código:

if(sectionID == currentSectionID)

en mi editor y ejecuto un análisis estático, obtengo: "JAVA0078 Valores de coma flotante en comparación con =="

¿Qué tiene de malo usar ==para comparar valores de coma flotante? ¿Cuál es la forma correcta de hacerlo? 

La forma correcta de probar flotadores para 'igualdad' es:

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

donde épsilon es un número muy pequeño como 0.00000001, dependiendo de la precisión deseada.

Los valores de coma flotante pueden desactivarse un poco, por lo que pueden no informar exactamente igual. Por ejemplo, estableciendo un flotante en "6.1" y luego imprimiéndolo nuevamente, puede obtener un valor reportado de algo como "6.099999904632568359375". Esto es fundamental para la forma en que funcionan los flotadores; por lo tanto, no desea compararlos utilizando la igualdad, sino más bien la comparación dentro de un rango, es decir, si la diferencia del flotante con el número con el que desea compararlo es menor que un cierto valor absoluto.

Este artículo en el Registro ofrece una buena descripción de por qué este es el caso; Lectura útil e interesante.

Solo para dar la razón detrás de lo que todos los demás dicen.

La representación binaria de un flotador es un poco molesta.

En binario, la mayoría de los programadores conocen la correlación entre 1b = 1d, 10b = 2d, 100b = 4d, 1000b = 8d

Bueno, también funciona a la inversa.

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

El problema es que no hay una forma exacta de representar la mayoría de los números decimales como .1, .2, .3, etc. Todo lo que puede hacer es aproximarse en binario. El sistema hace un poco de redondeo cuando se imprimen los números para mostrar .1 en lugar de .10000000000001 o .999999999999 (que probablemente estén tan cerca de la representación almacenada como .1)

Editar del comentario: La razón por la que esto es un problema son nuestras expectativas. Esperamos totalmente que 2/3 se falsifique en algún momento cuando lo convertimos a decimal, ya sea .7 o .67 o .666667 .. Pero no esperamos automáticamente que .1 se redondee de la misma manera que 2/3 Y eso es exactamente lo que está sucediendo.

Por cierto, si tiene curiosidad, el número que almacena internamente es una representación binaria pura usando una "notación científica" binaria. Entonces, si le dice que almacene el número decimal 10.75d, almacenaría 1010b para el 10 y .11b para el decimal. Por lo tanto, almacenaría .101011 y luego guardaría algunos bits al final para decir: Mueva el punto decimal cuatro lugares a la derecha.

(Aunque técnicamente ya no es un punto decimal, ahora es un punto binario, pero esa terminología no habría hecho las cosas más comprensibles para la mayoría de las personas que encontrarían esta respuesta útil).

¿Qué tiene de malo usar == para comparar valores de punto flotante?

Porque no es cierto que 0.1 + 0.2 == 0.3

Creo que hay mucha confusión sobre los flotadores (y los dobles), es bueno aclararlo.

1. No hay nada inherentemente incorrecto en el uso de flotantes como ID en JVM compatible con el estándar [*]. Si simplemente configura la ID del flotador en x, no haga nada con ella (es decir, sin aritmética) y luego pruebe y == x, estará bien. Además, no hay nada de malo en usarlos como claves en un HashMap. Lo que no puede hacer es asumir igualdades x == (x - y) + y, etc. Dicho esto, las personas usualmente usan tipos enteros como ID, y puede observar que la mayoría de las personas aquí están desanimadas por este código, por lo que, por razones prácticas, es mejor cumplir con las convenciones . Tenga en cuenta que hay tantos doublevalores diferentes como largos values, por lo que no gana nada con el uso double. Además, generar el "próximo ID disponible" puede ser complicado con los dobles y requiere cierto conocimiento de la aritmética de coma flotante. No vale la pena.

2. Por otro lado, confiar en la igualdad numérica de los resultados de dos cálculos matemáticamente equivalentes es arriesgado. Esto se debe a los errores de redondeo y la pérdida de precisión al convertir de representación decimal a binaria. Esto ha sido discutido hasta la muerte en SO.

[*] Cuando dije "JVM compatible con el estándar" quería excluir ciertas implementaciones de JVM con daño cerebral. Mira esto .

Este es un problema no específico de Java. Usar == para comparar dos flotantes / dobles / cualquier número de tipo decimal puede causar problemas debido a la forma en que están almacenados. Un flotador de precisión simple (según el estándar IEEE 754) tiene 32 bits, distribuidos de la siguiente manera:

1 bit - Signo (0 = positivo, 1 = negativo)
8 bits - Exponente (una representación especial (sesgo-127) de la x en 2 ^ x)
23 bits - Mantisa. El número actual que se almacena.

La mantisa es la que causa el problema. Es un poco como una notación científica, solo el número en la base 2 (binario) se parece a 1.110011 x 2 ^ 5 o algo similar. Pero en binario, el primer 1 es siempre un 1 (excepto la representación de 0)

Por lo tanto, para ahorrar un poco de espacio en la memoria (juego de palabras), IEEE decidió que se debe asumir el 1. Por ejemplo, una mantisa de 1011 realmente es 1.1011.

Esto puede causar algunos problemas con la comparación, especialmente con 0 ya que 0 no puede representarse exactamente en un flotante. Esta es la razón principal por la cual se desalienta el ==, además de los problemas matemáticos de coma flotante descritos por otras respuestas.

Java tiene un problema único en el sentido de que el lenguaje es universal en muchas plataformas diferentes, cada una de las cuales podría tener su propio formato flotante único. Eso hace que sea aún más importante evitar ==.

La forma correcta de comparar dos flotadores (sin lenguaje específico para usted) para la igualdad es la siguiente:

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

donde ACCEPTABLE_ERROR está #definido o alguna otra constante igual a 0.000000001 o cualquier precisión requerida, como ya mencionó Victor.

Algunos idiomas tienen esta funcionalidad o esta constante incorporada, pero generalmente es un buen hábito.

A partir de hoy, la forma rápida y fácil de hacerlo es:

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

Sin embargo, los documentos no especifican claramente el valor de la diferencia de margen (un épsilon de la respuesta de @Victor) que siempre está presente en los cálculos de los flotadores, pero debería ser algo razonable, ya que es parte de la biblioteca de idiomas estándar.

Sin embargo, si se necesita una precisión mayor o personalizada, entonces

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

Es otra opción de solución.

Los valores del punto de alimentación no son confiables debido al error de redondeo.

Como tal, probablemente no deberían usarse como valores clave, como sectionID. Utilice enteros en su lugar, o longsi intno contiene suficientes valores posibles.

Además de las respuestas anteriores, debe tener en cuenta que hay comportamientos extraños asociados con -0.0fy +0.0f(lo son ==pero no lo son equals) y Float.NaN(lo es equalspero no lo es ==) (espero haberlo hecho bien, ¡argh, no lo haga!).

Editar: ¡Vamos a ver!

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
    }
} 

Bienvenido a IEEE / 754.

Aquí hay una discusión muy larga (pero con suerte útil) sobre este y muchos otros problemas de coma flotante que puede encontrar: Lo que todo informático debe saber sobre la aritmética de coma flotante

Puede usar Float.floatToIntBits ().

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

En primer lugar, ¿son flotantes o flotantes? Si uno de ellos es flotante, debe usar el método equals (). Además, probablemente sea mejor usar el método estático Float.compare.

Lo siguiente usa automáticamente la mejor precisión:

/**
 * 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;
}

Por supuesto, puede elegir más o menos de 5 ULP ('unidad en último lugar').

Si te gusta la biblioteca Apache Commons, la Precisionclase tiene compareTo()y equals()con epsilon y ULP.

es posible que desee que sea ==, pero 123.4444444444443! = 123.4444444444442

Si * tiene que * usar flotantes, la palabra clave estrictafp puede ser útil.

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

Dos cálculos diferentes que producen números reales iguales no necesariamente producen números iguales de coma flotante. Las personas que usan == para comparar los resultados de los cálculos generalmente terminan sorprendidos por esto, por lo que la advertencia ayuda a marcar lo que de otro modo sería un error sutil y difícil de reproducir.

¿Está tratando con código subcontratado que usaría flotantes para cosas llamadas sectionID y currentSectionID? Sólo curioso.

@ Bill K: "La representación binaria de un flotador es un poco molesta". ¿Cómo es eso? ¿Cómo lo harías mejor? Hay ciertos números que no se pueden representar en ninguna base correctamente, porque nunca terminan. Pi es un buen ejemplo. Solo puedes aproximarlo. Si tiene una mejor solución, comuníquese con Intel.

Como se menciona en otras respuestas, los dobles pueden tener pequeñas desviaciones. Y podría escribir su propio método para compararlos utilizando una desviación "aceptable". Sin embargo ...

Hay una clase apache para comparar dobles: org.apache.commons.math3.util.Precision

Contiene algunas constantes interesantes: SAFE_MINyEPSILON , que son las desviaciones máximas posibles de operaciones aritméticas simples.

También proporciona los métodos necesarios para comparar, igualar o redondear dobles. (usando ulps o desviación absoluta)

En una línea de respuesta que puedo decir, debes usar:

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

Para que aprenda más sobre el uso correcto de operadores relacionados, estoy elaborando algunos casos aquí: Generalmente, hay tres formas de probar cadenas en Java. Puede usar ==, .equals () u Objects.equals ().

¿En qué se diferencian? == prueba la calidad de referencia en cadenas, lo que significa descubrir si los dos objetos son iguales. Por otro lado, .equals () comprueba si las dos cadenas tienen el mismo valor lógicamente. Finalmente, Objects.equals () prueba cualquier nulo en las dos cadenas y luego determina si se debe llamar a .equals ().

Operador ideal para usar

Bueno, esto ha sido objeto de muchos debates porque cada uno de los tres operadores tiene su conjunto único de fortalezas y debilidades. Ejemplo, == a menudo es una opción preferida cuando se compara la referencia de objeto, pero hay casos en los que puede parecer que también se comparan valores de cadena.

Sin embargo, lo que obtienes es un valor de caída porque Java crea una ilusión de que estás comparando valores pero en el sentido real no lo eres. Considere los dos casos a continuación:

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);

Por lo tanto, es mucho mejor usar cada operador al probar el atributo específico para el que está diseñado. Pero en casi todos los casos, Objects.equals () es un operador más universal, por lo tanto, los desarrolladores web experimentados optan por él.

Aquí puede obtener más detalles: http://fluentthemes.com/use-compare-strings-java/

La forma correcta sería

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

Una forma de reducir el error de redondeo es usar doble en lugar de flotante. Esto no hará que el problema desaparezca, pero reduce la cantidad de error en su programa y la opción flotante casi nunca es la mejor. EN MI HUMILDE OPINIÓN.