We Keep Coding

Big Error in Java or incongruency with simple operators

I'm beginning in Java, and could anyone explain me why Java gives me these answers?
I have a very simple class trying to learn how to round a number.
I want 2 decimals
so...
public static void main(String[] args) {
double pi1 = Math.PI;
System.out.println("pi1 = " + pi1);
double p2 ;
p2= Math.round(pi1*100)/100;
//p2= Math.round(pi1*100)
//p2=p2/100;
System.out.println("p2 = " + p2);
}
If I run this result is:
p2 = 3.0
Then I change
//p2= Math.round(pi1*100)/100;
p2 = Math.round(pi1*100);
p2 = p2/100;
Now, result is:
p2 = 3.14
as I wanted
Why with these differences? Why the first option doesn't give me 3.14
I think that I've made a correct code with 1st option.
Please, anyone could tell me why?
These things makes me don't trust Java.
Thank you.

I will assume that you know how integer division works in Java. In short, when both sides of / are integral types, like in 314 / 100, the expression evaluates to an integer too, like 3.
Math.round returns a long, which is an integral type. In your first code, you have the expression Math.round(pi1*100)/100. Math.round(...) returns an integer type, 100 is an integer literal, so integer division occurs.
However, in the second code, you first assigned the result of Math.round to p2. The long returned is implicitly converted to a double first, and stored in p2. You then wrote an expression in p2: p2/100. Here, one of the operands is double, so integer division does not occur.
Therefore, the one liner version that is the same as the second code is:
p2 = ((double)Math.round(pi1*100))/100;
You don't see the double conversion in the second code because it is done implicitly.
A note on rounding
This way rounding doubles should be used if you want to do calculations with the rounded number afterwards. If you just want to display a rounded number as output, you should use String.format, System.out.printf, or DecimalFormat. Read more about these methods here.

No mistake here, it works properly. Method Math.round(double) returns type long.
In your first variant, you receive result long 314 and divide it by 100 and get the result 3, and then assign it back to double.
In your second variant, you receive long result 314 and assign it back to double. Dividing double keeps precision as opposed to dividing long, so you get the correct result of 3.14
There for make p2= Math.round(pi1*100)/100; as
p2= Math.round(pi1*100) / 100.0;
Output -:
pi1 = 3.141592653589793
p2 = 3.14

BigDecimal operations precision overflow

import java.math.BigDecimal;
public class TestNumber {
public static void main(String[] args) {
BigDecimal bd = new BigDecimal(0);
bd = bd.add(new BigDecimal(19.89));
System.out.println(bd.doubleValue() + " - \t " + bd);
}
}
I have multiple BidDecimals fields and arithmetic operations/comparations, the problem is with arithmetic results and decimals values.
For the above example the output is as follows:
19.89 - 19.8900000000000005684341886080801486968994140625
I expects:
19.89
The unexpected result creates other undesirable outputs to perform operations on the field type BigDecimal

The precision is already lost once you use the BigDecimal constructor that accepts double values. The value youre seeing is the true IEEE 754 representation of the number. You can use
bd = bd.add(new BigDecimal("19.89"));

The double value displayed by println is not the same as the actual value stored in that double variable.
In any range there are an infinite number of real numbers but only a finite number of representable floating point values. When you define a floating point value, that value may not map to a representable floating point value, in which case you get the representable value that is closest to what you want. (Also keep in mind the representation is in binary, and a lot of numbers that are familiar to us become repeating decimals in binary that have to get truncated.) Here of course it's off by only 0.0000000000000005684341886080801486968994140625.
The lines
double d = 19.89d;
System.out.println(d);
will show you a cleaned-up approximation of what's in d. Java is hiding the messy trailing decimals from you.
On the other hand, these lines
double d = 19.89d
BigDecimal b = new BigDecimal(d);
System.out.println(b);
result in the BigDecimal getting initialized with the entire contents of d, which the BigDecimal reproduces faithfully out to the last trailing digit.
When println is passed the BigDecimal, the BigDecimal's toString method returns a string showing the digits it stored, and println writes that string to the console.
Using
BigDecimal b = new BigDecimal("19.89");
will result in the actual decimal value 19.89 getting stored in the BigDecimal, because no floating point evaluation is involved.

If you have a double and you need to make a BigDecimal out of it, without adding all the extra precision, try something like
double d = 19.89; // or something else
bd = new BigDecimal(d, new MathContext(15));
This tells it to keep only 15 digits of precision (which is about how many digits of precision a double supports). This creates a BigDecimal whose toString() returns
"19.8900000000000"
which isn't quite perfect, since all the trailing zeroes will show up, but it doesn't give you the extra non-zero digits you're getting.

java BigDecimal subraction failing

I tried the following code. but getting different result when subtracting using BigDecimal.
double d1 = 0.1;
double d2 = 0.1;
System.out.println("double result: "+ (d2-d1));
float f1 = 0.1F;
float f2 = 0.1F;
System.out.println("float result: "+ (f2-f1));
BigDecimal b1 = new BigDecimal(0.01);
BigDecimal b2 = new BigDecimal(0.01);
b1 = b1.subtract(b2);
System.out.println("BigDecimal result: "+ b1);
Result:
double result: 0.0
float result: 0.0
BigDecimal result: 0E-59
I am still working on this. can anyone please clarify.

[There are a lot of answers here telling you that binary floating-point can't exactly represent 0.01, and implying that the result you're seeing is somehow inexact. Whilst the first part of that is true, it's not really the core issue here.]
The answer is that "0E-59" is equal to 0. Recall that a BigDecimal is the combination of an unscaled value and a decimal scale factor:
System.out.println(b1.unscaledValue());
System.out.println(b1.scale());
displays:
0
59
The unscaled value is 0, as expected. The "strange" scale value is simply an artifact of the decimal expansion of the non-exact floating-point representation of 0.01:
System.out.println(b2.unscaledValue());
System.out.println(b2.scale());
displays:
1000000000000000020816681711721685132943093776702880859375
59
The next obvious question is, why doesn't BigDecimal.toString just display b1 as "0", for convenience? The answer is that the string representation needs to be unambiguous. From the Javadoc for toString:
There is a one-to-one mapping between the distinguishable BigDecimal values and the result of this conversion. That is, every distinguishable BigDecimal value (unscaled value and scale) has a unique string representation as a result of using toString. If that string representation is converted back to a BigDecimal using the BigDecimal(String) constructor, then the original value will be recovered.
If it just displayed "0", then you wouldn't be able to get back to this exact BigDecimal object.

Use constructor from String: b1 = new BigDecimal("0.01");
Java loss of precision
(slide 23)
http://strangeloop2010.com/system/talks/presentations/000/014/450/BlochLee-JavaPuzzlers.pdf

Interesting, the values appear to be equal and subtraction does give you zero, it appears to just be an issue with the printing code. The following code:
import java.math.BigDecimal;
public class Test {
public static void main(String args[]) {
BigDecimal b1 = new BigDecimal(0.01);
BigDecimal b2 = new BigDecimal(0.01);
BigDecimal b3 = new BigDecimal(0);
if (b1.compareTo(b2) == 0) System.out.println("equal 1");
b1 = b1.subtract(b2);
if (b1.compareTo(b3) == 0) System.out.println("equal 2");
System.out.println("BigDecimal result: "+ b1);
}
}
outputs both equal messages, indicating that the values are the same and that you get zero when you subtract.
You could try to raise this as a bug and see what Oracle comes back with. It's likely they'll just state that 0e-59 is still zero, so not a bug, or that the rather complex behaviour being described on the BigDecimal documentation page is working as intended. Specifically, the point that states:
There is a one-to-one mapping between the distinguishable BigDecimal values and the result of this conversion. That is, every distinguishable BigDecimal value (unscaled value and scale) has a unique string representation as a result of using toString. If that string representation is converted back to a BigDecimal using the BigDecimal(String) constructor, then the original value will be recovered.
That fact that the original value needs to be recoverable means that toString() needs to generate a unique string for each scale, which is why you're getting 0e-59. Otherwise, converting the string back to a BigDecimal may give you a different value (unscaled-value/scale tuple).
If you really want zero to show up as "0" regardless of the scale, you can use something like:
if (b1.compareTo(BigDecimal.ZERO) == 0) b1 = new BigDecimal(0);

You have to get the return value:
BigDecimal b3 = b1.subtract(b2);
System.out.println("BigDecimal result: "+ b3);

BigDecimal(double val)
1.The results of this constructor can be somewhat unpredictable. One might assume that writing new BigDecimal(0.1) in Java creates a
BigDecimal which is exactly equal to 0.1 (an unscaled value of 1, with
a scale of 1), but it is actually equal to
0.1000000000000000055511151231257827021181583404541015625. This is because 0.1 cannot be represented exactly as a double (or, for that
matter, as a binary fraction of any finite length). Thus, the value
that is being passed in to the constructor is not exactly equal to
0.1, appearances notwithstanding.
2.The String constructor, on the other hand, is perfectly predictable: writing new BigDecimal("0.1") creates a BigDecimal which is exactly
equal to 0.1, as one would expect. Therefore, it is generally
recommended that the String constructor be used in preference to this
one.
3.When a double must be used as a source for a BigDecimal, note that this constructor provides an exact conversion; it does not give the
same result as converting the double to a String using the
Double.toString(double) method and then using the BigDecimal(String)
constructor. To get that result, use the static valueOf(double)
method.

So the real question is: with the following code,
BigDecimal b1 = new BigDecimal(0.01);
BigDecimal b2 = new BigDecimal(0.01);
b1 = b1.subtract(b2);
why does b1.toString() evaluate to "0E-59" and not to something like "0.0", "0E0" or just "0"?
The reason is that toString() prints the canonical format of the BigDecimal. See BigDecimal.toString() for more information.
At the end, 0E-59 is 0.0 - it is 0*10^59 which mathematically evaluates to 0. So, the unexpected result is a matter of the internal representation of the BigDecimal.
To get the float or double values, use
b1.floatValue());
or
b1.doubleValue());
Both evaluate to 0.0.

It's a known issue, BigDecimal(double val) API The results of this constructor can be somewhat unpredictable. Though it looks really wierd in this interpertation. Actual reason is that new BigDecimal(0.01) produces a BigDecimal with approx values
0.01000000000000000020816681711721685132943093776702880859375
which has a long precision, and so the result of subtract has a long precision too.
Anyway, we can solves the "problem" this way
BigDecimal b1 = new BigDecimal("0.01");
BigDecimal b2 = new BigDecimal("0.01");
or we can use a constructor with setting a precision
BigDecimal b1 = new BigDecimal(0.01, new MathContext(1));
BigDecimal b2 = new BigDecimal(0.01, new MathContext(1));

Use like this:
BigDecimal b1 = BigDecimal.valueOf(0.01);
BigDecimal b2 = BigDecimal.valueOf(0.01);
b1 = b1.subtract(b2);
System.out.println("BigDecimal result: "+ b1);

Explanation of output of a java program

I came across the following program
class Boolean {
public static void main(String argv[]) {
boolean x;
x = 4.4f == 4.4;
System.out.println(x);
}
}
The output of the following program is false
But if we write the program in the following fashion, then
class Boolean {
public static void main(String argv[]) {
boolean x;
x = 4.5f == 4.5;
System.out.println(x);
}
}
In this case the output is true
Can somebody explain me why ??

You generally shouldn't compare floating point values with == operator. You should use 'close enough' comparison like checking if values differ by some small value:
double epsilon = 0.000001
boolean equal = Math.abs(value1-value2) < epsilon
In your example, 4.4f is not equal to 4.4, because java defaults floating point values to double type, which is 64bit, and to compare them java casts 4.4f to double, which causes it to be slightly different from original double value 4.4(because of problems representing decimal fractions with binary).
Here's a good link on floating point numbers.

The problem is that computers like numbers to be based on base 2 and not base 10 like us.
4.4 is an infinite fraction (like 0.333333333... for us) in binary, and floats have fewer digits than doubles, so there are fewer digits in 4.4f than in 4.4 making them different.
4.5 is not an infinite fraction.
Note: Whenever you need to compare floats or doubles you should always check the size of the difference, not just check for equality.

Run this code to see how casting of float to double works for these cases
NumberFormat nf = new DecimalFormat("0.00000000000000000000");
System.out.println(nf.format(4.4f));
System.out.println(nf.format(4.4));
System.out.println(nf.format(4.5f));
System.out.println(nf.format(4.5));

That is because of a rounding error when the double gets truncated to a float. Sometimes you get it sometimes you won't.
4.4f is a float and 4.4 is a double.

Your prgramm compares a 16-bit float with 32-bit double value. Internaly it is represented a IEEE754 so the difference is a rounding error which leads in some cases to this inequality due to different precision.

This is down to the fact that a float is a not a double and you can't easily do direct comparison, because a float is just an approximation. Take a look at the following code:
public static void main(String args[]) {
double a, b;
a = 4.4f;
b = 4.5f;
System.out.println("4.4f implicitly cast to a double = "+a);
System.out.println("4.5f implicitly cast to a double = "+b);
}
You'll see that 4.4f, when implicitly cast to a double is in fact 4.400000095367432.

In addition to what everyone has said, here is a very popular example to demonstrate this thing with floating point operations.
System.out.println(0.3 - 0.2 - 0.1);
It won't print 0. In fact, it would print a very small number as a result of the truncation errors that happen in floating point operations when certain fractions are non-terminating repeating in the binary representation.

ArithmeticException: "Non-terminating decimal expansion; no exact representable decimal result"

Why does the following code raise the exception shown below?
BigDecimal a = new BigDecimal("1.6");
BigDecimal b = new BigDecimal("9.2");
a.divide(b) // results in the following exception.
Exception:
java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result.

From the Java 11 BigDecimal docs:
When a MathContext object is supplied with a precision setting of 0 (for example, MathContext.UNLIMITED), arithmetic operations are exact, as are the arithmetic methods which take no MathContext object. (This is the only behavior that was supported in releases prior to 5.)
As a corollary of computing the exact result, the rounding mode setting of a MathContext object with a precision setting of 0 is not used and thus irrelevant. In the case of divide, the exact quotient could have an infinitely long decimal expansion; for example, 1 divided by 3.
If the quotient has a nonterminating decimal expansion and the operation is specified to return an exact result, an ArithmeticException is thrown. Otherwise, the exact result of the division is returned, as done for other operations.
To fix, you need to do something like this:
a.divide(b, 2, RoundingMode.HALF_UP)
where 2 is the scale and RoundingMode.HALF_UP is rounding mode
For more details see this blog post.

Because you're not specifying a precision and a rounding-mode. BigDecimal is complaining that it could use 10, 20, 5000, or infinity decimal places, and it still wouldn't be able to give you an exact representation of the number. So instead of giving you an incorrect BigDecimal, it just whinges at you.
However, if you supply a RoundingMode and a precision, then it will be able to convert (eg. 1.333333333-to-infinity to something like 1.3333 ... but you as the programmer need to tell it what precision you're 'happy with'.

You can do
a.divide(b, MathContext.DECIMAL128)
You can choose the number of bits you want: either 32, 64 or 128.
Check out this link :
http://edelstein.pebbles.cs.cmu.edu/jadeite/main.php?api=java6&state=class&package=java.math&class=MathContext

To fix such an issue I have used the below code
a.divide(b, 2, RoundingMode.HALF_EVEN)
Where 2 is scale. Now the problem should be resolved.

I had this same problem, because my line of code was:
txtTotalInvoice.setText(var1.divide(var2).doubleValue() + "");
I change to this, reading previous Answer, because I was not writing decimal precision:
txtTotalInvoice.setText(var1.divide(var2,4, RoundingMode.HALF_UP).doubleValue() + "");
4 is Decimal Precison
AND RoundingMode are Enum constants, you could choose any of this
UP, DOWN, CEILING, FLOOR, HALF_DOWN, HALF_EVEN, HALF_UP
In this Case HALF_UP, will have this result:
2.4 = 2
2.5 = 3
2.7 = 3
You can check the RoundingMode information here: http://www.javabeat.net/precise-rounding-of-decimals-using-rounding-mode-enumeration/

It´s a issue of rounding the result, the solution for me is the following.
divider.divide(dividend,RoundingMode.HALF_UP);

Answer for BigDecimal throws ArithmeticException
public static void main(String[] args) {
int age = 30;
BigDecimal retireMentFund = new BigDecimal("10000.00");
retireMentFund.setScale(2,BigDecimal.ROUND_HALF_UP);
BigDecimal yearsInRetirement = new BigDecimal("20.00");
String name = " Dennis";
for ( int i = age; i <=65; i++){
recalculate(retireMentFund,new BigDecimal("0.10"));
}
BigDecimal monthlyPension = retireMentFund.divide(
yearsInRetirement.divide(new BigDecimal("12"), new MathContext(2, RoundingMode.CEILING)), new MathContext(2, RoundingMode.CEILING));
System.out.println(name+ " will have £" + monthlyPension +" per month for retirement");
}
public static void recalculate (BigDecimal fundAmount, BigDecimal rate){
fundAmount.multiply(rate.add(new BigDecimal("1.00")));
}
Add MathContext object in your divide method call and adjust precision and rounding mode. This should fix your problem

Your program does not know what precision for decimal numbers to use so it throws:
java.lang.ArithmeticException: Non-terminating decimal expansion
Solution to bypass exception:
MathContext precision = new MathContext(int setPrecisionYouWant); // example 2
BigDecimal a = new BigDecimal("1.6",precision);
BigDecimal b = new BigDecimal("9.2",precision);
a.divide(b) // result = 0.17

For me, it's working with this:
BigDecimal a = new BigDecimal("9999999999.6666",precision);
BigDecimal b = new BigDecimal("21",precision);
a.divideToIntegralValue(b).setScale(2)