Working Around the Java Double.parseDouble Bug | Hacker News Reader

Working Around the Java Double.parseDouble Bug

blog.headius.com

15 pointsbensummers11 comments

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

Now this is even worse:

State 5-Cause Known, bug Priority: 4-Low

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();

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.

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.

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.

maybe its okay to lose some precision as everybody knows that doubles are already inaccurate? :)

http://en.wikipedia.org/wiki/Floating_point#Accuracy_problem...

edit: i mean: normalize(!), check if it is textually the bad magic number, then either use builtin conversion or use your solution. a? :)

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"

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.

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

Reply on news.ycombinator.com