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.
Related
in java, is it legal? i need to find points that are collinear with same slope to point of oigin. vertical lines have positive infinity slope. On cell phone, weird typing
From the Java Language Specification
15.20.1 Numerical Comparison Operators <, <=, >, and >=: "All values other than NaN are ordered, with negative infinity less than all finite values, and positive infinity greater than all finite values."
15.21.1 Numerical Equality Operators == and !=: "In particular, there is one value representing positive infinity and one value representing negative infinity; each compares equal only to itself, and each compares unequal to all other values."
Totally legal. POSITIVE_INFINITY is a value, after all.
EDIT 2: There used to be some stupid stuff in this post about Double.NaN. If you saw it, disregard it. new Double(1.0 / 0.0).compareTo(Double.POSITIVE_INFINITY) = 0, and POSITIVE_INFINITY equals itself, and that should be enough to handle vertical slopes.
Does the following statement holds for any double (Java primitive double precision IEEE-754) except NaN:
Double.parseDouble(String.valueOf(d)) == d
Said otherwise, does parsing a serialized (using String.valueOf()) double value always yields the exact original double?
With the exception of NaN as you've said, yes, that invariant should hold. If not, that's a JDK bug right there.
Double.toString says this in its Javadoc:
How many digits must be printed for the fractional part of m or a? There must be at least one digit to represent the fractional part, and beyond that as many, but only as many, more digits as are needed to uniquely distinguish the argument value from adjacent values of type double. That is, suppose that x is the exact mathematical value represented by the decimal representation produced by this method for a finite nonzero argument d. Then d must be the double value nearest to x; or if two double values are equally close to x, then d must be one of them and the least significant bit of the significand of d must be 0.
To summarize, it returns enough digits to identify this double uniquely, so Double.parseDouble should return the exact same double that was converted to a string.
i=Double.NaN
while(i==i)
{
//some code
}
what is the output?
Why don't we have a Integer.NaN?
IEEE floating points have a "Not a Number" representation by spec. Integral types do not have such a state. Every possible binary representation of an integer is a real number.
what is the output?
There is no output because NaN != NaN as per the IEEE 754 standard, so the loop will never be entered.
Why don't we have a Integer.NaN?
Because Integers are based on a two's complement binary representation where every bit pattern is a valid integer, and none have any special meaning.
Double.NaN == x is always false, no matter what x is.
For float and double NaN is not equal to anything even itself.
For int and long types I have used MIN_VALUE as a value like NaN, but you have to code this yourself, if you want it to work this way.
BTW: There is a puzzler, when is the following an infinite loop.
while(x != x + 0);
There are three types for x when this is an infinite loop.
Another is when is this an infinite loop.
while(x == -x);
There is 16 type/value combinations for this, much more than you might expect. ;)
I cannot tell you why but you can work around it with this:
(int)Double.NaN;
so my guess is that there is not a good reason.
double d=1/0.0;
System.out.println(d);
It prints Infinity , but if we will write double d=1/0; and print it we'll get this exception: Exception
in thread "main" java.lang.ArithmeticException: / by zero
at D.main(D.java:3) Why does Java know in one case that diving by zero is infinity but for the int 0 it is not defined?
In both cases d is double and in both cases the result is infinity.
Floating point data types have a special value reserved to represent infinity, integer values do not.
In your code 1/0 is an integer division that, of course, fails. However, 1/0.0 is a floating point division and so results in Infinity.
strictly speaking, 1.0/0.0 isn't infinity at all, it's undefined.
As David says in his answer, Floats have a way of expressing a number that is not in the range of the highest number it can represent and the lowest. These values are collectively known as "Not a number" or just NaNs. NaNs can also occur from calculations that really are infinite (such as limx -> 0 ln2 x), values that are finite but overflow the range floats can represent (like 10100100), as well as undefined values like 1/0.
Floating point numbers don't quite clearly distinguish among undefined values, overflow and infinity; what combination of bits results from that calculation depends. Since just printing "NaN" or "Not a Number" is a bit harder to understand for folks that don't know how floating point values are represented, that formatter just prints "Infinity" or sometimes "-Infinity" Since it provides the same level of information when you do know what FP NaN's are all about, and has some meaning when you don't.
Integers don't have anything comparable to floating point NaN's. Since there's no sensible value for an integer to take when you do 1/0, the only option left is to raise an exception.
The same code written in machine language can either invoke an interrupt, which is comparable to a Java exception, or set a condition register, which would be a global value to indicate that the last calculation was a divide by zero. which of those are available varies a bit by platform.
i do the below java print command for this double variable
double test=58.15;
When i do a System.out.println(test); and System.out.println(new Double(test).toString()); It prints as 58.15.
When i do a System.out.println(new BigDecimal(test)) I get the below value
58.14999999999999857891452847979962825775146484375
I am able to understand "test" double variable value is internally stored as 58.1499999. But when i do the below two System.out.println i am getting the output as 58.15 and not 58.1499999.
System.out.println(test);
System.out.println(new Double(test).toString());
It prints the output as 58.15 for the above two.
Is the above System.out.println statements are doing some rounding of the value 58.1499999 and printing it as 58.15?
System.out.println(new BigDecimal("58.15"));
To construct a BigDecimal from a hard-coded constant, you must always use one of constants in the class (ZERO, ONE, or TEN) or one of the string constructors. The reason is that one you put the value in a double, you've already lost precision that can never be regained.
EDIT: polygenelubricants is right. Specifically, you're using Double.toString or equivalent. To quote from there:
How many digits must be printed for
the fractional part of m or a? There
must be at least one digit to
represent the fractional part, and
beyond that as many, but only as many,
more digits as are needed to uniquely
distinguish the argument value from
adjacent values of type double. That
is, suppose that x is the exact
mathematical value represented by the
decimal representation produced by
this method for a finite nonzero
argument d. Then d must be the double
value nearest to x; or if two double
values are equally close to x, then d
must be one of them and the least
significant bit of the significand of
d must be 0.
Yes, println (or more precisely, Double.toString) rounds. For proof, System.out.println(.1D); prints 0.1, which is impossible to represent in binary.
Also, when using BigDecimal, don't use the double constructor, because that would attempt to precisely represent an imprecise value. Use the String constructor instead.
out.println and Double.toString() use the format specified in Double.toString(double).
BigDecimal uses more precision by default, as described in the javadoc, and when you call toString() it outputs all of the characters up to the precision level available to a primitive double since .15 does not have an exact binary representation.