

Working Around the Java Double.parseDouble Bug - bensummers
http://blog.headius.com/2011/02/working-around-java-doubleparsedouble.html

======
wigginus
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>

~~~
DanielRibeiro
Now this is even worse:

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

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

~~~
jonshea
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
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
maybe its okay to lose some precision as everybody knows that doubles are
already inaccurate? :)

[http://en.wikipedia.org/wiki/Floating_point#Accuracy_problem...](http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems)

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

------
fedd
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
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
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

