# [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results

Raffaello Giulietti raffaello.giulietti at gmail.com
Thu Mar 7 19:16:58 UTC 2019

On 2019-03-07 11:10, Brian Burkhalter wrote:
>
>> On Mar 7, 2019, at 10:04 AM, Andrew Haley <aph at redhat.com
>> <mailto:aph at redhat.com>> wrote:
>>
>> On 3/6/19 7:31 PM,raffaello.giulietti at gmail.com
>> <mailto:raffaello.giulietti at gmail.com>wrote:
>>> the latest version of the patch, replacing the one found at [1].
>>> In the next days, my sponsor Brian Burkhalter will publish it as a
>>> webrev.
>>
>> I still believe you'd be better off defining an unsigned multiplyHigh than
>
> There is in fact an open issue for unsigned multiplyHigh:
>
> https://bugs.openjdk.java.net/browse/JDK-8188044
>
> Brian

Hi Andrew,

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)

or
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.

I tried with four variants. In addition to the mults, which are needed
anyway, the current code has 3 shifts, 3 adds, 2 bitwise logicals. As
mentioned, I couldn't come up with a solution that would help reducing
this count.

I would be glad to hear of better solutions and to write down a
mathematical proof for the document.

In the meantime I got rid of the last division. There's no division at
all in the whole algorithm.

Greetings
Raffaello