Why thank you!
Yes, I expect those two are in-lined (is that what you mean?), but a
glance into the source of either BigDecimal or even the
highly-optimised Double.toString(double) will convince you the call
overhead (or its absence) in using those methods is of no
consequence by comparison.
I'd like to do more rationalisation around this soon, but not our
own conversion at the mo. (And I found some small mistakes in what I
Just now I want to ntpath (where I broke it, sorry) and I'm looking
at issue #2120 in case it's related.
On 24/04/2014 19:50, Jim Baker wrote:
Wow, this is really impressive!
Any number of times some of us have dipped our toes into working
on this problem, but this work is just so nicely comprehensive
As you noted, it would be nice to avoid using BigDecimal.
However, in looking at your changes, you are already using
Double.doubleToLongBits and Math.getExponent (which presumably
are intrinisified). So using BigDecimal for part of the heavy
lifting makes sense to me. Perhaps this is something that can
be revisited in 2.7.1.