I understand that doubles in Java can take Double.NaN or Double.POSITIVE_INFINITY etc.
But is it necessary to check for Double.isNan or Double.isFinite each time a method accepts a double as a parameter?
I'm making a small project and I think that Nan or infinite values will not occur.
In java we can use the isNan() method for float and double values.
E.g.:
if (!Double.isNaN(0.01)) {
// condition happens
}
if (!Float.isNaN(0.01F)) {
// condition happens
}
I wonder why we can't use it for Integers.
NaN is Not a Number, i.e., an undefined or unrepresentible number, such as the square root of -1.
Integers are always well defined, and Strings just aren't numbers at all, so they are irrelevant for checking against being NaN.
Because String and Integer can't be NaN.
NaN is a special value of floating point numbers, along with others like Infinity; integers and strings don't have such special values, so the functions to check for them would make no sense.
The reason they exist is to represent the results of certain calculations, so that floating point numbers can be used in arbitrary mathematical situations.
What is an elegant, readable and non-verbose way of comparing two floating point value for exact equality?
As simple as it may sound, its a wicked problem. The == operator doesn't get the job done for NaN and also has special treatment for zero:
(+0.0 == -0.0) -> true
Double.NaN == Double.NaN -> false
But I want to determine if two values are exactly the same (but I do not care for different NaN patterns, so any NaN == any other NaN -> true).
I can do this with this ugly Monster piece of code:
Double.doubleToLongBits(a) == Double.doubleToLongBits(b)
Is there a better way to write this (and make the intent obvious)?
You can use
Double.compare(a, b) == 0
From the javadoc for compareTo
Double.NaN is considered by this method to be equal to itself and greater than all other double values (including Double.POSITIVE_INFINITY).
0.0d is considered by this method to be greater than -0.0d.
What you've got is already the best way of doing it, I'd say. It makes it clear that you're interested in the bitwise representation of the value. You happen to be converting those bits to long as a convenient 64-bit type which doesn't have any funky behaviour.
If you don't want it appearing frequently in your codebase, just add a method to wrap it:
public static boolean bitwiseEqualsWithCanonicalNaN(double x, double y) {
return Double.doubleToLongBits(x) == Double.doubleToLongBits(y);
}
Note that as per your question, this does not differentiate between different NaN values. If you wanted to do this at a later date, you'd need to use Double.toRawLongBits.
Why does this comparison give me 'false'? I looked at the source and Float.NaN is defined as
/**
* A constant holding a Not-a-Number (NaN) value of type
* <code>float</code>. It is equivalent to the value returned by
* <code>Float.intBitsToFloat(0x7fc00000)</code>.
*/
public static final float NaN = 0.0f / 0.0f;
EDIT: surprisingly, if I do this:
System.out.println("FC " + (Float.compare(Float.NaN, Float.NaN)));
it gives me 0. So Float.compare() does think that NaN is equal to itself!
Use Float.isNaN to check for NaN values.
Because Java implements the IEEE-754 floating point standard which guarantees that any comparison against NaN will return false (except != which returns true)
That means, you can't check in your usual ways whether a floating point number is NaN, so you could either reinterpret both numbers as ints and compare them or use the much cleverer solution:
def isNan(val):
return val != val
All I need to say is: Wikipedia About NaN.
It is written quite clearly. The interesting part is that the floating point NaN of the common standard expresses a NaN this way:
s111 1111 1xxx xxxx xxxx xxxx xxxx xxxx
The s is the sign (negative or positive), the 1's are the exponent and the x is regarded as a payload.
Looking at the payload a NaN is not equal any NaN and there are rare chances that these information of the payload are interesting for you as a developer (e.g. complex numbers).
Another thing is that in the standard they have signalling and quite NaN. A signalling NaN (sNaN) means an NaN that should raises a reaction like a exception. It should be used to say out loud that you have a problem in your equation. A quiet NaN (qNaN) is a NaN that is silently passed on.
A sNaN that created a signal is converted to a qNaN to not further produce any more signals in subsequent operations. Remember some system define i^0 = 1 as a constant that NaN^0 = 1 holds true. So there are cases where people calculate with NaN.
So in the end I would go with this: qNaN != sNaN but this is internal and is not observable for the user (you cant check that). Mix along the payment and the sign (yes you can have negative and positive NaN) and it appears to me that always return NaN != NaN looks like a much wiser choice that I finally learned to appreciate -> I will never ever complain or wonder about the inequality of NaN again. Praise the folks who were that thoughtful giving us such a good standard!
By the way: Java uses a positive NaN with a payload of 0 (all x are zeros).
Is it safe if I use comparision like this (a is int, b and c is float/double):
a == b
b == c
It may hear ridiculous, but in my old programing language, sometimes 1 + 2 == 3 is false (because left side returns 2.99999999999...). And, what about this:
Math.sqrt(b) == Math.sqrt(c)
b / 3 == 10 / 3 //In case b = 10, does it return true?
In general, no it is not safe due to the fact that so many decimal numbers cannot be precisely represented as float or double values. The often stated solution is test if the difference between the numbers is less than some "small" value (often denoted by a greek 'epsilon' character in the maths literature).
However - you need to be a bit careful how you do the test. For instance, if you write:
if (Math.abs(a - b) < 0.000001) {
System.err.println("equal");
}
where a and b are supposed to be "the same", you are testing the absolute error. If you do this, you can get into trouble if a and b are (say_ 1,999,999.99 and 2,000,000.00 respectively. The difference between these two numbers is less than the smallest representable value at that scale for a float, and yet it is much bigger than our chosen epsilon.
Arguably, a better approach is to use the relative error; e.g. coded (defensively) as
if (a == b ||
Math.abs(a - b) / Math.max(Math.abs(a), Math.abs(b)) < 0.000001) {
System.err.println("close enough to be equal");
}
But even this is not the complete answer, because it does not take account of the way that certain calculations cause the errors to build up to unmanageable proportions. Take a look at this Wikipedia link for more details.
The bottom line is that dealing with errors in floating point calculations is a lot more difficult than it appears at first glance.
The other point to note is (as others have explained) integer arithmetic behaves very differently to floating point arithmetic in a couple of respects:
integer division will truncate if the result is not integral
integer addition subtraction and multiplication will overflow.
Both of these happen without any warning, either at compile time or at runtime.
You do need to exercise some care.
1.0 + 2.0 == 3.0
is true because integers are exactly representable.
Math.sqrt(b) == Math.sqrt(c)
if b == c.
b / 3.0 == 10.0 / 3.0
if b == 10.0 which is what I think you meant.
The last two examples compare two different instances of the same calculation. When you have different calculations with non representable numbers then exact equality testing fails.
If you are testing the results of a calculation that is subject to floating point approximation then equality testing should be done up to a tolerance.
Do you have any specific real world examples? I think you will find that it is rare to want to test equality with floating point.
b / 3 != 10 / 3 - if b is a floating point variable like b = 10.0f, so b / 3 is 3.3333, while 10 / 3 is integer division, so is equal to 3.
If b == c, then Math.sqrt(b) == Math.sqrt(c) - this is because the sqrt function returns double anyways.
In general, you shouldn't be comparing doubles/floats for equation, because they are floating point numbers so you might get errors. You almost always want to compare them with a given precision, i.e.:
b - c < 0.000001
The safest way to compare a float/double with something else is actually to use see if their difference is a small number.
e.g.
Math.abs(a - b) < EPS
where EPS can be something like 0.0000001.
In this way you make sure that precision errors do not affect your results.
== comparison is not particularly safe for doubles/floats in basically any language. An epsilon comparison method (where you check that the difference between two floats is reasonably small) is your best bet.
For:
Math.sqrt(b) == Math.sqrt(c)
I'm not sure why you wouldn't just compare b and c, but an epsilon comparison would work here too.
For:
b / 3 == 10 / 3
Since 10/3 = 3 because of integer division, this will not necessarily give the results you're looking for. You could use 10.0 / 3, though i'm still not sure why you wouldn't just compare b and 10 (using the epsilon comparison method in either case).
Float wrapper class's compare method can be used to compare two float values.
Float.compare(float1,float2)==0
It will compare integer bits corresponding to each float object.
In java you can compare a float with another float,and a double with another double.And you will get true when comparing a double with a float when their precision is equal
b is float and 10 is integer then if you compare both with your this critearia then it will give false because...
b = flaot (meance ans 3.33333333333333333333333)
10 is integer so that make sence.
If you want a more complete explanation, here there is a good one: http://download.oracle.com/docs/cd/E19957-01/806-3568/ncg_goldberg.html (but it is a little bit long)