ho pensato che risultato di qualsiasi operazione matematica su un NaN mi dovrebbe dare un NaN indietro, ma Math.round(Float.NaN) == 0Perché Math.round() restituisce 0 per gli argomenti NaN?
Qual è la logica per tale comportamento di Math.round()?
Curiosamente, C# si comporta diversamente: http://msdn.microsoft.com/en-us/library/75ks3aby.aspx
Haha. Voglio schiaffeggiarmi in testa.
Math.round(double) restituisce un lunga e lunga non può essere NaN. L'alternativa è un'eccezione.
In C# il risultato è ancora double.
La domanda riguarda l'arrotondamento Floats –
@HunterMcMillen Sì,' long Math.round (double) 'è come viene definito in Java. Questa risposta spiega perché ritorna in '0' e non' NaN'. Se fosse 'double Math.round (double)' allora il modo C# potrebbe essere più appropriato ... –
@Hunter: L'operazione * restituisce * a 'long'. –
Math.round() è definito come (long)Math.floor(a + 0.5d).
a è NaN, quindi a+0.5d è NaN.Math.floor() è impostato su StrictMath.floor() che restituisce NaN quando passato in NaN.NaN ad un long, restituisce 0Quindi in ultima analisi, si tratta di motivo per cui la fusione NaN ad un long restituisce 0. Questo problema è stato ampiamente discusso in this question.
+1 per scavare un po 'nella realizzazione! Hai collegamenti al codice [Open Source JDK] per le funzioni appropriate? –
+1 In Java 7 questa definizione è stata eliminata a causa di questo problema [Perché Math.round (0.499999999999999917) arrotonda a 1 su Java 6] (http://vanillajava.blogspot.co.uk/2012/04/why-mathround0499999999999999917 -rounds.html) –
come ha detto @pst, è il comportamento normale definito per NaN: "Se l'argomento è NaN, il risultato è 0". –
La logica è che prima c'era un bug in 'Math.round()' quando chiamato su NaN poteva potenzialmente rovinare le future chiamate a 'Math.round()': http://bugs.sun.com/bugdatabase/ view_bug.do?bug_id=4755500 –
La differenza è probabile; in Java restituisce 'long' che non può essere' Double.NaN' mentre un C# restituisce un 'double' –