0

Is there anyway to check if a Double has java rounding e.g. -260.01079999999996

I have one system that passes a computed Double value. By right should be -260.0108.

bittersour
  • 937
  • 2
  • 11
  • 32
  • 1
    Why bother? Just use `BigDecimal` and don't worry about it. – TedTrippin Feb 06 '17 at 17:30
  • 2
    Typically you'd compare it to an arbitrary epsilon value. Although calling it a "rounding issue" seems a bit weird since nobody's doing any rounding and nobody asked for it either. – Jeroen Vannevel Feb 06 '17 at 17:30
  • 1
    You should always assume there is a potential rounding issue unless you know there isn't – Peter Lawrey Feb 06 '17 at 17:31
  • 1
    @TedTrippin You can still have rounding and representation issues with BigDecimal so you still have to worry about it. – Peter Lawrey Feb 06 '17 at 17:32
  • 2
    If you know how the maximum number of digits the number can theoretically have, then you can check if it has more than that. But this sounds a lot like an XY problem – what problem are you trying to solve with this? – JJJ Feb 06 '17 at 17:33
  • @PeterLawrey yes, i understand rounding issue may happen. But is there any way to check if a Double/BigDecimal has rounding issue? – bittersour Feb 06 '17 at 17:35
  • 1
    @bittersour If you know what the number should be you can see if there is a difference. There is no number which is inherently incorrect without assumptions. You can round it to say 4 decimal places for example. – Peter Lawrey Feb 06 '17 at 17:36
  • 1
    @PeterLawrey To satisfy the ops question, would it be possible to catch an exception? From the BigDecimal javadoc " If no rounding mode is specified and the exact result cannot be represented, an exception is thrown". Would that work? – TedTrippin Feb 06 '17 at 17:37
  • 1
    @TedTrippin this would detect representation errors which most likely the OPs real problem. It would depend on the operations the OP is performing. If this is an input Double.pauseDouble("-260.01079999999996") it doesn't help. If the error is the result of say addition/subtraction/multiplication of decimal values, then BigDecimal will avoid the issue entirely. – Peter Lawrey Feb 06 '17 at 17:39
  • @PeterLawrey it is a computed Double value. So if is computed, i will need to use BigDecimal to avoid it? – bittersour Feb 06 '17 at 17:45
  • @bittersour yes, or round the result. I use a tuility method to round to 4 decimal places https://github.com/OpenHFT/Chronicle-Core/blob/master/src/main/java/net/openhft/chronicle/core/Maths.java#L93 – Peter Lawrey Feb 06 '17 at 17:48

2 Answers2

0

When using floats and doubles, the "issues" with rounding are due to the limitations of digital computers.

If you don't want rounding, use integers. If you need to save a number with a fixed number of digits after comma, use a BigDecimal; or always round your double at Xth digit after comma; or use the number as integer while dividing or multiplying it by 10^n before showing in view (elaboration below).

For example, you could save -2600108 as integer and a factor 1000. Addition, subtraction, multiplication and saving work flawlessly and without side-effects in this case. Division needs doubles though.

Hubert Grzeskowiak
  • 15,137
  • 5
  • 57
  • 74
0

If you know from external evidence that the exact answer at a certain point in your code must be an integer, round to nearest integer there.

Otherwise, you get the most accurate double result by carrying the full precision through your calculations, using DecimalFormat to print only the meaningful digits.

There is nothing special about "java rounding". The special thing is that the default output preserves enough digits to uniquely identify the double. Many other languages, by default, round to fewer digits, losing accuracy but making results look tidier.

Using BigDecimal is a major win if every number in the calculation can be exactly represented as a short decimal fraction. That often happens for currency calculations. However, as soon as you hit a fraction such as 1/3 that cannot be exactly represented by any finite number of decimal digits, you have to deal with rounding error anyway. For many financial calculations, there are fixed rules for rounding.

In theory, BigDecimal could also be used to get extra precision, but that is rarely practical.

Patricia Shanahan
  • 25,849
  • 4
  • 38
  • 75