[PATCH] 4511638: Double.toString(double) sometimes produces incorrect results
brian.burkhalter at oracle.com
Thu Mar 14 20:50:38 UTC 2019
The CSR for this issue is available for review at https://bugs.openjdk.java.net/browse/JDK-8202555 <https://bugs.openjdk.java.net/browse/JDK-8202555>. If you have a JBS user name you can add yourself as reviewer by editing the issue directly, assuming you concur with the content.
> On Mar 8, 2019, at 8:56 AM, raffaello.giulietti at gmail.com wrote:
> On 2019-03-08 14:35, Andrew Haley wrote:
>> On 3/7/19 7:16 PM, Raffaello Giulietti wrote:
>>> a couple of weeks ago I tried to refactor the code assuming the
>>> existence of unsignedMultiplyHigh() (either as some future intrinsic or
>>> as a Java method) and a wider representations of g with either 127 or
>>> 128 bits:
>>> g = g1 2^64 + g0
>>> with either
>>> 2^63 <= g1 < 2^64 (128 bits)
>>> 2^62 <= g1 < 2^63 (127 bits)
>>> Unfortunately, the resulting code of rop() isn't any simpler. That's
>>> because then an intermediate sum can overflow the 64 bits of a long. As
>>> a consequence, there's need for more elaborate logic to determine
>>> the carry and other slightly more complicated computations to assemble
>>> the final result. All in all, the resulting code has more operations and
>>> looks longer.
>> Ah, I see. I agree, we still don't quite have the full set of operations
>> that we need in Java, in particular a nice way of doing an add with carry.
>> Thank you for the explanation.
> You're welcome.
>>> In the meantime I got rid of the last division. There's no division at
>>> all in the whole algorithm.
>> Excellent. This is looking very good indeed.
More information about the core-libs-dev