5 ms·

Working Around the Java Double.parseDouble Bug

15 points by bensummers 16y ago

wigginus 16y ago
From the comments of above post: A bug report for the same bug from almost 10 (ten!) years ago: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4421494 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4421494
- DanielRibeiro 16y ago
  Now this is even worse: State 5-Cause Known, bug Priority: 4-Low
tedunangst 16y ago
Correct me if I'm wrong, but couldn't the same bug exist in the BigDecimal to double conversion? It has to turn a precise value into an approximate double using a similar algorithm, no? return base.scaleByPowerOfTen(exponent).doubleValue();
- headius 16y ago
  I don't believe so; the conversion to imprecise doesn't follow the same logic that the String to double does. But I don't know what logic it does follow, nor if there's other bugs there :) In any case, for the original value and variations I tested, the workaround does function properly.
- jonshea 16y ago
  My understanding is that you are correct. I believe that BigDecimal.doubleValue() does the conversion by (wait for it…) converting to a string and parsing with Double.parseDouble(). Real quick: scala> val y y: java.math.BigDecimal = 2.2250738585072012E-308 scala> y.doubleValue() Hangs This is one of those “harder than it looks” problems.
  - headius 16y ago
    Yeah, I went back to my code and realized there was a precision problem I had to fix for numbers approaching 64-bit minimum. Once I fixed that issue, it went back to hanging again :( I updated the post, and I'm looking for new alternatives now.
    - fedd 16y ago
      maybe its okay to lose some precision as everybody knows that doubles are already inaccurate? :) http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems http://en.wikipedia.org/wiki/Floating_point#Accuracy_problem...
      - fedd 16y ago
        edit: i mean: normalize(!), check if it is textually the bad magic number, then either use builtin conversion or use your solution. a? :)
fedd 16y ago
i didn't think much about this, but couldn't we just check whether we have a string "2.2250738585072012e-308" to parse, and then decide, call the builtin function or not. at least, just check the input hash against a hashcode[1] of "2.2250738585072012e-308" and then call either custom function or the native one. normalizing, parseInt, cunstructing a bigDecimal may be a bit more expencive than the native func (don't know for sure) (and did anyone check whether it hangs on French (?) locale where there is a decimal comma, not dot?) [1] two hashcodes, with small and big "E"
- mquander 16y ago
  Not really, since you can come up with lots of ways to express 2.2250738585072012e-308 as a string: 0.22250738585072012e-307, 0000000.22250738585072012e-307, 0.222507385850720120000000e-307, and so on. As long as it's the same double, it seems like it should trigger the bug in the same fashion.
  - fedd 16y ago
    as people wrote that getting this double from integer part and then applying scale doesn't cause problems, i assumed that the problem in parsing that specific string, but not in that particular double value, which can be represented differently

15 points by bensummers 16y ago

From the comments of above post: A bug report for the same bug from almost 10 (ten!) years ago: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4421494 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4421494

DanielRibeiro 16y ago
Now this is even worse: State 5-Cause Known, bug Priority: 4-Low

tedunangst 16y ago

Correct me if I'm wrong, but couldn't the same bug exist in the BigDecimal to double conversion? It has to turn a precise value into an approximate double using a similar algorithm, no? return base.scaleByPowerOfTen(exponent).doubleValue();

headius 16y ago
I don't believe so; the conversion to imprecise doesn't follow the same logic that the String to double does. But I don't know what logic it does follow, nor if there's other bugs there :) In any case, for the original value and variations I tested, the workaround does function properly.
jonshea 16y ago
My understanding is that you are correct. I believe that BigDecimal.doubleValue() does the conversion by (wait for it…) converting to a string and parsing with Double.parseDouble(). Real quick: scala> val y y: java.math.BigDecimal = 2.2250738585072012E-308 scala> y.doubleValue() Hangs This is one of those “harder than it looks” problems.
- headius 16y ago
  Yeah, I went back to my code and realized there was a precision problem I had to fix for numbers approaching 64-bit minimum. Once I fixed that issue, it went back to hanging again :( I updated the post, and I'm looking for new alternatives now.
  - fedd 16y ago
    maybe its okay to lose some precision as everybody knows that doubles are already inaccurate? :) http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems http://en.wikipedia.org/wiki/Floating_point#Accuracy_problem...
    - fedd 16y ago
      edit: i mean: normalize(!), check if it is textually the bad magic number, then either use builtin conversion or use your solution. a? :)

fedd 16y ago

i didn't think much about this, but couldn't we just check whether we have a string "2.2250738585072012e-308" to parse, and then decide, call the builtin function or not. at least, just check the input hash against a hashcode[1] of "2.2250738585072012e-308" and then call either custom function or the native one. normalizing, parseInt, cunstructing a bigDecimal may be a bit more expencive than the native func (don't know for sure) (and did anyone check whether it hangs on French (?) locale where there is a decimal comma, not dot?) [1] two hashcodes, with small and big "E"

mquander 16y ago
Not really, since you can come up with lots of ways to express 2.2250738585072012e-308 as a string: 0.22250738585072012e-307, 0000000.22250738585072012e-307, 0.222507385850720120000000e-307, and so on. As long as it's the same double, it seems like it should trigger the bug in the same fashion.
- fedd 16y ago
  as people wrote that getting this double from integer part and then applying scale doesn't cause problems, i assumed that the problem in parsing that specific string, but not in that particular double value, which can be represented differently