Develop Reference

Java BigDecimal Rounding while having pointless 0's in the number

Problem
I used BigDecimal.setScale(7, RoundingMode.HALF_UP) to round the number to 7 decimal places, however now if I get a number without any decimal places or with them being fewer then 7 I get useless 0's in the number, for example after rounding 40 that way I'll get 40.0000000.
Question
Is it possible to round numbers a certain number of decimal places using SetScale and get rid of pointless 0's at the same time?

Providing you have already performed your rounding, you can simply use DecimalFormat("0.#").
final double value = 5.1000;
DecimalFormat format = new DecimalFormat("0.#");
System.out.println(format.format(value));
The result here will be 5.1 without the trailing zeroes.

So the other way to work this problem out is using BigDecimals methods such as .stripTrailingZeros().toPlainString()
It is quite lesser code to write, than the other solution, but as said iт the solution could be less comfortable to change level of precision in the future, if you'll need to

Is there a way to remove the even-odd rule of rounding for 5 and round up?

Making a application for ordering tickets. For the total, I added the subtotal, hst, and service fees together, and decimal formatted the sum for the total. If the total is x.85, it rounds down to x.8 but I want x.9
Is there a way to remove the even-odd rule for rounding 5 and round up?
I have tried BigDecimal but it doesn't seem to work for me.
DecimalFormat df = new DecimalFormat("$#,###.00");
grandTotal = subTotal + hst + serviceFees;
System.out.printf("%-40s%11s\n", "TOTAL:", df.format(grandTotal));
I expect the output to round up when there is a 5 to round, but it just rounds based on the even-odd rule.

You need only 1 fraction digit.
You current code is rounding correctly, just too many fraction digits.
The rounding mode you are asking for is called HALF UP, which is a default for DecimalFormat and the only possible rounding mode for printf().
(You can also use format $#,###.# if you don't want to display zeros as fraction.)
Therefore you can use your decimal format just fine or even System.out.printf() but limit number of fraction digits to 1:
DecimalFormat df = new DecimalFormat("$#,###.0"); //set MIN and MAX fraction digits to 1
df.setRoundingMode(RoundingMode.HALF_UP); //default but showing usage if needed
System.out.println(df.format(123454.84d));
System.out.println(df.format(123454.85d));
System.out.printf("$%,.1f", 123454.85d); //HALF UP rounding the only option
prints:
$123,454.8
$123,454.9
$123,454.9

You are using floating point (double), which is just an approximation of real values.
Especially with a list and a total, you will always have trouble to get everything right.
You have no control, whether the total is 2.35 (actually never) or 2.349999998, the latter which would round down.
Use BigDecimal with String constructors: new BigDecimal("1.20"), having a fraction of 2 decimals.
Mind you must use add/multiply i.o. +/*.

Guys i just switched the double data type into a float type and it worked ayyyyy
!!!!!!!

How do you truncate extra decimals from BigDecimal

I'm building a service that uses a currency converter and forwards the BigDecimal amount to another service. Sometimes, the conversion rate makes it so that the converted amount has close to 34 decimal places, which the downstream service does not accept.
Is there a way to simply truncate (not round) the BigDecimal. So, for example, if the converted amount is 1.23456789 I want neither 1.24, nor 1.3, nor 1.20, or anything of that sort. I simply want to get rid of the decimals that appear after 4. So what I want is 1.23.
I saw a lot of questions on SO related to this, but they all rounded the BigDecimal in some way.
Thanks!

RoundingMode.DOWN effectively truncates your decimal values:
Javadoc says:
Rounding mode to round towards zero. Never increments the digit prior
to a discarded fraction (i.e., truncates). Note that this rounding
mode never increases the magnitude of the calculated value.
BigDecimal dec = new BigDecimal(10.2384235254634623524);
System.out.println(dec.setScale(2, RoundingMode.DOWN));
Will give:
10.23

BigDecimal provides RoundingMode, which you need here is RoundingMode.FLOOR,
System.out.println(new BigDecimal("1.234567").setScale(2, RoundingMode.FLOOR)); // 1.23
System.out.println(new BigDecimal("1.236567").setScale(2, RoundingMode.FLOOR)); // 1.23

you could try treating it like a string
System.out.println(new DecimalFormat("#0.##").format(new BigDecimal("1.23456789")));

BigDecimal also provides Rounding Modes. Try this
BigDecimal bd = new BigDecimal(2.2964556655);
System.out.println(bd.setScale(2,BigDecimal.ROUND_DOWN));

BigDecimal in scala

I've stumbled across interisting thing(maybe only for me) in scala. In a word, if we have a BigDecimal(let say val a = BigDecimal(someValue) where someValue is decimal string) the result of operation
N * a / N == a
will not always produce true. I suppose that it relates to any opeartions on BigDecimals. I know that in scala BigDecimals are created with default MathContext set to DECIMAL128(with HALF_EVEN rounding and precision equals to 34). I've discovered such behavior on decimals with more than 30 digits after point
My questions is why I get such results. Can I somehow control them?
example
-0.007633587786259541984732824427480916

As previous comments already point out, this is not avoidable with irrational numbers. This is because there's no way to represent an irrational number using the standard numeric types (if at all). Since I have no examples with irrational numbers (even PI is limited to a fixed number of digits, and therefore can be expressed as a quotient of 2 whole numbers, making it rational), I will use repeating decimals to illustrate the problem. I changed N*a/N to a/N*N because it demonstrates the problem better with whole numbers, but they're equivalent:
a = BigDecimal(1)
N = BigDecimal(3)
a/N = 0.333...
a/N*N = 0.999...
As you can see in the example above, you can use as many decimal places and any rounding mode, but the result is never going to be equal to 1. (Though it IS possible to get 1 using a different rounding mode per operation, i.e. BigDecimal(3, roundHalfEven) * (BigDecimal(1, roundUp) / 3))
One thing you can do to control the number comparison is to use a higher precision when performing your arithmetic operations and round to the desired (lower) precision when comparing:
val HighPrecision = new java.math.MathContext(36, java.math.RoundingMode.HALF_EVEN);
val TargetPrecision = java.math.MathContext.DECIMAL128;
val a = BigDecimal(1, HighPrecision)
val N = BigDecimal(3, HighPrecision)
(a/N*N).round(TargetPrecision) == a.round(TargetPrecision)
In the example above, the last expression evaluates to true.
UPDATE
To answer your comment, although BigDecimal is arbitrary precision, it is still limited by a precision. It can be 34 or it can be 1000000 (if you have enough memory). BigDecimal does NOT know that 1 / 3 is 0.33<repeating>. If you think about how division works, there's no way for BigDecimal to conclusively know that it's repeating without performing the division to infinite decimal places. But since a precision of 2 indicates it can stop dividing after 2 decimal places, it only knows that 1 / 3 is 0.33.

Java Glitch? Subtracting numbers?

Is this a glitch in Java?
I go to solve this expression: 3.1 - 7.1
I get the answer: -3.9999999999999996
What is going on here?

A great explanation can be found here. http://www.ibm.com/developerworks/java/library/j-jtp0114/
Floating point arithmetic is rarely exact. While some numbers, such
as 0.5, can be exactly represented as a binary (base 2) decimal (since
0.5 equals 2-1), other numbers, such as 0.1, cannot be. As a result, floating point operations may result in rounding errors, yielding a
result that is close to -- but not equal to -- the result you might
expect. For example, the simple calculation below results in
2.600000000000001, rather than 2.6:
double s=0;
for (int i=0; i<26; i++)
s += 0.1;
System.out.println(s);
Similarly, multiplying .1*26 yields a result different from that of
adding .1 to itself 26 times. Rounding errors become even more serious
when casting from floating point to integer, because casting to an
integral type discards the non-integral portion, even for calculations
that "look like" they should have integral values. For example, the
following statements:
double d = 29.0 * 0.01;
System.out.println(d);
System.out.println((int) (d * 100));
will produce as output:
0.29
28
which is probably not what you might expect at first.
See the provided reference for more information.

As mentioned by several others you cannot count on double if you would like to get an exact decimal value, e.g. when implementing monetary applications. What you should do instead is to take a closer look at BigDecimal:
BigDecimal a = new BigDecimal("3.1");
BigDecimal b = new BigDecimal("7.1");
BigDecimal result = a.subtract(b);
System.out.println(result); // Prints -4.0

Computers are 100% so in the math world that is correct, to the average person it is not. Java cant have a error on a specific number as it is just code that runs the same way but has a different input!
P.S. Google how to round a number

rounding errors in floating points
same way that 3 * 0.1 != 0.3 (when it's not folded by the compiler at least)

Automatic type promotion is happening and that is the result.
Here is some resource to learn.
http://docs.oracle.com/javase/specs/jls/se5.0/html/conversions.html
The next step would be is to learn to use formatters to format it to the given precision / requirements.