Using BigDecimal without any doubles (improved on the answer from marcolopes): public static BigDecimal round(BigDecimal value, BigDecimal increment, RoundingMode roundingMode) { if (increment.signum() == 0) { // 0 increment does not make much sense, but prevent division by 0 return value; } else { BigDecimal divided = value.divide(increment, 0, roundingMode); BigDecimal result = divided.multiply(increment); return … Read more
If you look at the fields in the source for BigDecimal there is: BigDecimal: long intCompact +8 bytes int precision +4 bytes int scale +4 bytes String stringCache +? BigInteger intVal +? BigInteger: int bitCount +4 bytes int bitLength +4 bytes int firstNonzeroIntNum +4 bytes int lowestSetBit +4 bytes int signum +4 bytes int[] mag … Read more
You can specify locale for DecimalFormat this way: DecimalFormatSymbols symbols = new DecimalFormatSymbols(Locale.US); DecimalFormat format = new DecimalFormat(“##.########”, symbols);
Try this // Create a DecimalFormat that fits your requirements DecimalFormatSymbols symbols = new DecimalFormatSymbols(); symbols.setGroupingSeparator(‘,’); symbols.setDecimalSeparator(‘.’); String pattern = “#,##0.0#”; DecimalFormat decimalFormat = new DecimalFormat(pattern, symbols); decimalFormat.setParseBigDecimal(true); // parse the string BigDecimal bigDecimal = (BigDecimal) decimalFormat.parse(“10,692,467,440,017.120”); System.out.println(bigDecimal); If you are building an application with I18N support you should use DecimalFormatSymbols(Locale) Also keep in mind … Read more
Use a String literal: private static final BigDecimal sd = new BigDecimal(“0.7”); If you use a double, actually public BigDecimal(double val) is called. The reason you do not get 0.7 is that it cannot be exactly represented by a double. See the linked JavaDoc for more information.
Since we have native support for BigInt, it doesn’t require much code any more to implement BigDecimal. Here is a BigDecimal class based on BigInt with the following characteristics: The number of decimals is configured as a constant, applicable to all instances. Whether excessive digits are truncated or rounded is configured as a boolean constant. … Read more
If this is not the right answer, what CAN we use for exact division in financial calculation? (I mean, I don’t have a finance major, but they still use division, right???). Then I was in primary school1, they taught me that when you divide by 1 by 3 you get a 0.33333… i.e. a recurring … Read more
What you actually want is new BigDecimal(“0.1”) .add(new BigDecimal(“0.1”)) .add(new BigDecimal(“0.1”)); The new BigDecimal(double) constructor gets all the imprecision of the double, so by the time you’ve said 0.1, you’ve already introduced the rounding error. Using the String constructor avoids the rounding error associated with going via the double.
Use toPlainString() BigDecimal d = new BigDecimal(“600.0”).setScale(2, RoundingMode.HALF_UP).stripTrailingZeros(); System.out.println(d.toPlainString()); // Printed 600 for me I’m not into JSF (yet), but converter might look like this: @FacesConverter(“bigDecimalPlainDisplay”) public class BigDecimalDisplayConverter implements Converter { @Override public Object getAsObject(FacesContext context, UIComponent component, String value) { throw new BigDecimal(value); } @Override public String getAsString(FacesContext context, UIComponent component, Object value) … Read more
If you want an exact representation for financial purposes, then doubles or floating point values are unsuitable as the fractional parts are subject to rounding error. Certain decimal values cannot not be represented using binary-based floating points and must be approximated. For a less technical intro, see The trouble with rounding floating point numbers; if … Read more