Here are a few hints: Use BigDecimal for computations if you need the precision that it offers (Money values often need this). Use the NumberFormat class for display. This class will take care of localization issues for amounts in different currencies. However, it will take in only primitives; therefore, if you can accept the small … Read more
To get exactly 10.0001 you need to use the String constructor or valueOf (which constructs a BigDecimal based on the canonical representation of the double): BigDecimal bd = new BigDecimal(“10.0001”); System.out.println(bd.toString()); // prints 10.0001 //or alternatively BigDecimal bd = BigDecimal.valueOf(10.0001); System.out.println(bd.toString()); // prints 10.0001 The problem with new BigDecimal(10.0001) is that the argument is a … Read more
No, you appear to have a legit bug. The bug presents in JDK7 but fixed in JDK8. Your values are correctly representable as BigDecimals, and should behave correctly, but don’t. Tracing through the source code of BigDecimal, on line 2585, this.precision() is 1, and this.scale is -2147483647. this.precision() – this.scale therefore overflows, and the following … Read more
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
Using double has enough precision for accurate lat/lon down to inches for 6-7 decimal places. In aviation, if decimal degrees are used, they typically go to at least 7 decimal places. In our NASA simulations, lat/lon data are doubles while all other attitude and altitude are floats. In other words, the 6th decimal place for … Read more
I used DecimalFormat for formatting the BigDecimal instead of formatting the String, seems no problems with it. The code is something like this: bd = bd.setScale(2, BigDecimal.ROUND_DOWN); DecimalFormat df = new DecimalFormat(); df.setMaximumFractionDigits(2); df.setMinimumFractionDigits(0); df.setGroupingUsed(false); String result = df.format(bd);
GMP is the popular choice. Squeak Smalltalk has a very nice library, but it’s written in Smalltalk. You asked for relevant books or articles. The tricky part of bignums is long division. I recommend Per Brinch Hansen’s paper Multiple-Length Division Revisited: A Tour of the Minefield.
The BigDecimal(double) constructor can have unpredictable behaviors. It is preferable to use BigDecimal(String) or BigDecimal.valueOf(double). System.out.println(new BigDecimal(135.69)); //135.68999999999999772626324556767940521240234375 System.out.println(new BigDecimal(“135.69”)); // 135.69 System.out.println(BigDecimal.valueOf(135.69)); // 135.69 The documentation for BigDecimal(double) explains in detail: 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 … Read more
BigDecimal all the way. I’ve heard of some folks creating their own Cash or Money classes which encapsulate a cash value with the currency, but under the skin it’s still a BigDecimal, probably with BigDecimal.ROUND_HALF_EVEN rounding. Edit: As Don mentions in his answer, there are open sourced projects like timeandmoney, and whilst I applaud them … Read more
The reason of such behaviour is that the string that is printed is the exact value – probably not what you expected, but that’s the real value stored in memory – it’s just a limitation of floating point representation. According to javadoc, BigDecimal(double val) constructor behaviour can be unexpected if you don’t take into consideration … Read more