Variable type for precise calculations (JAVA)

Asked

Viewed 603 times

2

What is the best type of variable for very precise calculations ?

I’ve used double and Bigdecimal and the rounding is diverging much in the end result.

java mathematics

  • For financial application the best is Bigdecimal or for other applications Double serves. This is what you seek?

  • I’m using bigDecimal and is giving a margin of error in not acceptable harnessing.. :|

  • 1

    Until then, by my little knowledge, the best variable really is Bigdecimal. Maybe the calculation is being done wrong? You have already tried using Double or the application is really financial and works with larger numbers that Double can support?

  • If currency calculation, there is Moneta implementing JSR 354(Money API) - http://javamoney.github.io/ri.html, there is also Joda Money - http://www.joda.org/joda-money/. Now for mathematical calculations there is Commons Math - https:/commons.apache.org/proper/commons-math/

  • not for currency.

  • With Lucas that’s the fourth person to tell you that your problem isn’t the BigDecimal (I’m using BigDecimal for problems where it is unacceptable errors before the 30th house, and this does not come close to being such an extreme use case). The only problem with the BigDecimal is that his API is somewhat verbose, I usually do complicated calculations on Scala which has a richer API. With respect to accuracy, even if you use a scientific API with an alternative Decimal type, it won’t be able to fix your entries.

  • Show your code to allow help.

  • I suspended the reply as "cannot be reproduced" because there is no problem of accuracy with BigDecimal and no serious problems with `double. As we have noticed, the AP problem is external data, program entries. The only answer possible without the context is the one that already exists: "the guy won’t solve his problem".

Show 3 more comments

1 answer

4

No kind of data will solve for you the problems of precision, be floating point (double), fixed point (BigDecimal) or any other. You need to identify in what sense your calculations are accumulating errors, and try to take measures to circumvent them.

  • Are you comparing data of very different quantities? (e.g.: adding a very large number and a very small number) If that’s the case, the floating point could lose accuracy, and the way would be to use a BigDecimal with sufficient significant number of digits to represent the full range of numbers you are dealing with.

  • Are you doing a very long sequence of calculations, using the minimum representation required for the numbers you are dealing with? If so, the small rounding errors in each individual calculation end up accumulating, giving a big difference in the end. Some possible solutions would be:

    • Increase the number of significant digits. If your entries are numbers with 5 decimal places, for example, increase them to 10. There is no rule for this, just see how long is your sequence of calculations and determine which major error can be propagated at the end of this sequence.

      (an example solution via more digits: in that reply I needed to calculate PI through a series. Using the exact number of digits gave the wrong result because the individual contributions of the series terms were truncated. It was necessary to add more digits to the numbers during the calculation, although in the final result these digits were discarded)

    • Use ranges instead of simple numbers. This technique (which if I remember correctly was proposed by Knuth) consists of taking the result of an operation taking into account both its ceiling and its floor (in relation to the desired precision), and when applying the next operation, combine ceiling, floor-floor, floor-ceiling and ceiling-floor, using the maximum and minimum found as the new range. Repeat for each operation, and at the end average the resulting interval (and still break you have an error margin).

Browser other questions tagged java mathematics

You are not signed in. Login or sign up in order to post.