I have a list of BigDecimal that could be as elements: I would like to calculate the absolute difference between elements not next to Zero value, in this example difference between 3 and 4, 4 and 5. Expected result should be also of type List<BigDecimal>. Of course, the value of Zero could be in any position and I should keep
Tag: bigdecimal
BigDecimal setScale ROUND_HALF_UP don’t seem to operate on each number
When I ROUND_HALF_UP 10.12445 with scale 2, I expect to get 10.13, because 10.12445 -> 10.1245 -> 10.125 -> 10.13 But the result is 10.12 Therfore if I succesively round with scales 4, 3 and 2, I get the result that I expect: Did I miss something? Is there a way to get the result I expect directly? Answer HALF_UP:
Big Decimal array not sorting 0 and 000.000
I was solving a java HackerRank problem in which I had to sort an array consisting decimal numbers using BigDecimal class in descending order. The solution works fine except for one case in which 0 and 000.000 comes. Now as they are equal, the problem tells us not keep them in the same order of their occurrence, but it is
How to round a BigDecimal before the decimal?
I have a BigDecimal like this var a = new BigDecimal(“1234.56”) and I want to round it to commercially to two places before the decimal, so that I get something equivalent to var b = new BigDecimal(“1200.00”) so that (new BigDecimal(“1200.00”)).equals(b). My best approach currently is var b = new BigDecimal(a.setScale(-2, RoundingMode.HALF_UP).toPlainString()).setScale(2); but I’m unsure if this is the right
How to make BigDecimal division more precise
I’m having an issue with BigDecimals, the simplified idea is to: define a value for the total split the total in 3 parts defined by weights, these weights are 3 double values that add up to 100.0 sum up the parts the sum should be close to the total, the error should be at most 0.00000001 Here’s the failing test:
why is my primality test failing so often when randomizing a BigInteger?
I wasn’t able to get true for both p and q, most of the results is both false or rarely p is true but q is false, why wouldn’t this test ever be true for both p and q? Answer First of all BigDecimal randomizer = new BigDecimal(Math.random()).multiply(new BigDecimal(bitSize100)) does not result in 100 bit of randomness. Math.random returns a
Create BigDecimal from unscaled long
I’m trying to convert long 1099 to BigDecimal 10.99; This gives me 11.00: AFAIK this should work. What’s my bonehead error? Answer The error is that there’s a distinction between scale and precision. The constructor of MathContext accepts a precision, which is a total number of decimal digits on either side of the decimal point. (For example, the original BigDecimal
BigDecimal gives unexpected results for numbers larger than 7 or 0 decimal numbers
While trying to calculate a ratio of the volume of 2 objects, I noticed some weirdness in the calculation, here is a sample you can run for yourself: And the result is: There are 3 ways I could make it give me the expected result 1. If I change the decimal part from 0 to 1 (or any non-0 number):
How likely is BigDecimal to cause memory issues for a POS program?
I understand that BigDecimal is the most accurate way to express currency because treating currency values as a floating-point data type tends to cause rounding errors. However, I also understand that BigDecimal calculations require more memory. That said, is using BigDecimal instead of float or double really the best practice for programs that deal with currency values? If I make
How to get the BigDemical in SQLite?
I’m grabbing the data of the database. If integer I can use getInt, If String I can use getString. But BigDecimal I don’t know what to use… Please Help. Thanks in advance! Answer Use BigDecimal.valueOf(double val):