We Keep Coding

Java - natural log with correct rounding

The documentation of the SE Math library is, thankfully, very transparent about rounding errors:
If a method always has an error less than 0.5 ulps, the method always returns the floating-point number nearest the exact result; such a method is correctly rounded. A correctly rounded method is generally the best a floating-point approximation can be; however, it is impractical for many floating-point methods to be correctly rounded. Instead, for the Math class, a larger error bound of 1 or 2 ulps is allowed for certain methods. Informally, with a 1 ulp error bound, when the exact result is a representable number, the exact result should be returned as the computed result; otherwise, either of the two floating-point values which bracket the exact result may be returned.
And every floating-point method mentions its error bounds in ulps. In particular, for Math.log():
Returns the natural logarithm (base e) of a double value...The computed result must be within 1 ulp of the exact result
Therefore, Math.log() will possibly round to the nearest representable value in the wrong direction.
I need a correctly rounded implementation of base-e log. Where might I find one?

Value changes when using double to store the value in c++ but remains same in java

I have similar code in c++ and java. There is a call by value to a double variable. I pass on a value of 1680.175 to both the codes. I can see during debugging that the value when passed changes to 1680.1749999999902 in c++ while it remains the same in java. I have to round a value after two places of decimal and therefore the codes give different result.

The value didn't change at all, you just printed it such that the extra decimals showed. The value 1680.175 does not have an exact representation in the double floating-point notation and the closest value is 1680.1749999999902. The same thing goes on in Java.

A double precision value has mantissa and exponent. Internally 1680.175 may be stored as 1680.1749999999902 or say 1680.1750001002 etc, i.e. close to your actual value. If precision is important then provide extra significant digits after decimal point as well.

If the double type can handle the numbers 4.35 and 435, why do 4.35 * 100 evaluates to 434.99999999999994? [duplicate]

This question already has answers here:
Is floating point math broken?
(31 answers)
Rounding oddity - what is special about "100"? [duplicate]
(2 answers)
Closed 9 years ago.
As I understand this, some numbers can't be represented with exactitude in binary, and that's why floating-point arithmetic sometimes gives us unexpected results; like 4.35 * 100 = 434.99999999999994. Something similar to what happens with 1/3 in decimal.
That makes sense, but this induces another question. Seems that in binary both 4.35 and 435 can be represented with exactitude. That's when it stops making sense to me. Why does 4.35 * 100 evaluates to 434.99999999999994? 435 and 4.35 have an exact representation in the double type dynamics:
double number1 = 4.35;
double number2 = 435;
double number3 = 100;
System.out.println(number1); // 4.35
System.out.println(number2); // 435.0
System.out.println(number3); // 100.0
// So far so good. Everything ok.
System.out.println(number1 * number3); // 434.99999999999994 !!!
// But 4.35 * 100 evaluates to 434.99999999999994
Why?
Edit: this question was marked as duplicate, and it is not. As you can see in the accepted answer, my confusion was regarding the discrepancy between the actual value and the printed value.

Seems that in binary both 4.35 and 435 can be represented with exactitude.
I see that you understand how the floating point numbers are internally represented. As for your doubt, no 4.35 does not have an exact binary representation. So the issue is, why the 1st print statement prints 4.35.
That is happening because System.out.println() invokes the Double.toString(double) method, which in turns uses FloatingDecimal#toJavaFormatString() method, which performs some rounding internally on the passed double argument. You can go through the source code I linked.
For seeing the actual value of 4.35, try using this:
BigDecimal bd = new BigDecimal(number1);
System.out.println(bd);
This will print:
4.3499999999999996447286321199499070644378662109375
In this case, rather than printing the double value, you create a BigDecimal object passing double value as argument. BigDecimal represents arbitrary precision signed decimal number. So it gives you the exact value of 4.35.

You are right in that sometimes floating-point arithmetic gives unexpected results.
Your assertion that 4.35 can be represented exactly in floating-point is incorrect, because it can't be represented as a terminating binary decimal. 100 can obviously be represented exactly, so for the result to be 434.99999999999994, `4.35 must not be represented exactly.
To be represented exactly in floating-point, a number must be able to be converted to a fraction where the denominator is a power of two only (and it must not be so precise that it exceeds the maximum precision of the floating-point type you're using). In this case, 4.35 is 4 7/20, and the denominator has a factor of 5, so the number can't be represented exactly in binary.

Although from a hardware perspective each floating-point number represents some exact value of the form M * 2^E (where M and E are integers in a certain range), from a software perspective it is more helpful to think of each floating-point number as representing "Something for which M * 2^E has been deemed the best representation, and which is hopefully close to that". Given a floating-point value (M * 2^E), one should figure that the actual number it's intended to represent may very easily be anywhere from (N - 1/2) * 2^E to (N + 1/2) * 2^E and in practice may extend a bit further beyond.
As a simple example, with type float, the value of M is limited to the range 0-16777215. The best representation of 2000000.1f is thus 16000001 * 2^-3 [i.e. 16000001/8]. Although exact decimal value of 16000001/8 is 2000000.125, the last digit isn't necessary to define the value of the number, since 16000001/8 would the best representation of 2000000.120 and 2000000.129 (or, for that matter, all values between 2000000.0625 and 2000000.1875, non-inclusive). Because the number of digits that would required to display the exact decimal value of a number of the form M * 2^E would often far exceed the number of meaningful digits, it is common to limit number of displayed digits to roughly those necessary to uniquely define the value.
Note that if one regards floating-point numbers as representing ranges, one will observe that casts from double to float--even though they must be explicitly specified--are actually safe since converting the double that best represents a particular value to float will yield either the best float representation of that value or something very close to it. Conversely, conversion from float to double, even though it's allowed implicitly, is dangerous because such conversion is very unlikely to select the double which would best represent the number that the float was supposed to represent.

it is a bit hard to explain in English, because I have learned computer number representation in Hungarian. In short, 4.35, 435 nor 100 is not exactly these numbers, but mantissa * 2^k (k-characteristic from -k to +k, and t - is the length of the mantissa in the M = (t,-k,+k) ) although the print call does some rounding. So the number-line is not continuous, but near some famous points, denser ).
So as I think these numbers are not exactly what you expect, and after the operation (I suppose this is one or two simple binary operation) you get the multiple of error distance of the two float point number representation.

Float.NaN == Float.NaN

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

double d=1/0.0 vs double d=1/0

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.