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 did.)

Just now I want to ntpath (where I broke it, sorry) and I'm looking at issue #2120 in case it's related.

Jeff
Jeff Allen
On 24/04/2014 19:50, Jim Baker wrote:
Jeff,

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 in comparison.

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.

Thanks again!

- Jim



On Wed, Apr 23, 2014 at 4:40 PM, Jeff Allen <ja.py@farowl.co.uk> wrote:
I've now submitted a revised float.__format__, and one for complex too. It is correct (nearly) but I have two observations:
1. The contract for Double.toString(double) appears to be exactly what we need for float.__repr__, but it doesn't keep its contract every time (http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4511638). However, I am using this for repr().
2. The conversions in float.__format__ (and my fixed version of round) are based on BigDecimal. This is correct, but slow for numbers with large exponent, especially when the exponent is large and negative.

To do any better than this, I believe we would have implement our own conversion, as CPython have. This may yet have to happen if performance of float.__format__ turns out to be an issue.

%-formatting of floats is uncorrected. I'd like to make it use the new code but this isn't entirely straightforward.

Jeff
Jeff Allen