In fact “0.0” is the exception as it does no stripTrailingZeroes. A bug! public static void main(final String… args) { p(“0”); p(“0.0”); p(“1.0”); p(“1.00”); p(“1”); p(“11.0″); } private static void p(String s) { BigDecimal stripped = new BigDecimal(s).stripTrailingZeros(); System.out.println(s + ” – scale: ” + new BigDecimal(s).scale() + “; stripped: ” + stripped.toPlainString() + ” … Read more
Because in some situations, an indication of precision (i.e. the margin of error) may be important. For example, if you’re storing measurements made by two physical sensors, perhaps one is 10x more precise than the other. It may be important to represent this fact.
To solve my problem I found some expansion series, and them I had them implemented to solve the equation X^n = e^(n * ln x). // Adjust this to modify the precision public const int ITERATIONS = 27; // power series public static decimal DecimalExp(decimal power) { int iteration = ITERATIONS; decimal result = 1; … Read more
Just for informational sake, I can tell you that the creation of the BigDecimal coming back from the database is done by the proprietary JDBC driver’s implementation of the ‘getBigDecimal’ method of the database-specific ‘ResultSet’ sub-class. I found this out by stepping thru the Hibernate source code with a debugger, while trying to find the … Read more
Here you go : <s:property value=”getText(‘{0,number,#,##0.00}’,{profit})”/> This is how I format numbers in my projects. You can use it with <s:if> to attain what you require.
There are two common pitfalls when working with floating point arithmetic. The first problem is that Ruby floating points have fixed precision. In practice this will either be 1) no problem for you or 2) disastrous, or 3) something in between. Consider the following: # float 1.0e+25 – 9999999999999999900000000.0 #=> 0.0 # bigdecimal BigDecimal(“1.0e+25”) – … Read more
BigDecimal is immutable, any operation on it including setScale(2, BigDecimal.ROUND_HALF_UP) produces a new BigDecimal. Correct code should be BigDecimal bd = new BigDecimal(1); bd.setScale(2, BigDecimal.ROUND_HALF_UP); // this does change bd bd = bd.setScale(2, BigDecimal.ROUND_HALF_UP); System.out.println(bd); output 1.00 Note – Since Java 9 BigDecimal.ROUND_HALF_UP has been deprecated and you should now use RoundingMode.ROUND_HALF_UP.
To be short: firstBigDecimal.compareTo(secondBigDecimal) < 0 // “<” firstBigDecimal.compareTo(secondBigDecimal) > 0 // “>” firstBigDecimal.compareTo(secondBigDecimal) == 0 // “==” firstBigDecimal.compareTo(secondBigDecimal) >= 0 // “>=”
When you create a double, the value 0.3 cannot be represented exactly. You can create a BigDecimal from a string without the intermediate double, as in new BigDecimal(“0.3”) A floating point number is represented as a binary fraction and an exponent. Therefore there are some number that cannot be represented exactly. There is an analogous … Read more
I created a BigDecimal specialization of the generic summary statistics collector of this answer, which allowed extending it to also support summing, hence also calculating an average: /** * Like {@code DoubleSummaryStatistics}, {@code IntSummaryStatistics}, and * {@code LongSummaryStatistics}, but for {@link BigDecimal}. */ public class BigDecimalSummaryStatistics implements Consumer<BigDecimal> { public static Collector<BigDecimal,?,BigDecimalSummaryStatistics> statistics() { return … Read more