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

[Raffaello Giulietti]

On 2018-09-27 16:55, Andrew Dinn wrote:
> Hi Raffaello,
> 
> On 27/09/18 15:20, raffaello.giulietti at gmail.com wrote:
>> Hi Andrew,
>> On the other side, in April this year I submitted another quite fast and
>> supposedly correct algorithm on this mailing list and I referred to an
>> accompanying paper by myself that gives full explanations on that
>> variant. Except for a couple of persons in private, nobody cared to send
>> me any observation or comment, neither on the code nor on the paper.
> 
> I'm sorry I didn't see that post. I would have been very happy to review
> the paper as well as the code. Unfortunately, none of us have time to
> catch everything and we certainly don't always see every contribution.
> 

I understand that most people are busy, so I was not really surprised 
not to get feedback on a rather tiny issue in the overall huge codebase.



>> The present algorithm is superior. I have the theory in notes, in my
>> head, on napkins, on paper sheets all over my desk and floors. But
>> rather than spending time on the paper itself, like I did almost in vain
>> for the April variant, I preferred investing it in coding, for several
>> reasons:
>> * Only code executes, not a paper.
>> * Only code gives results that can be compared against.
>> * Only code can give indications on performance enhancements.
>> * Only code is interesting to be submitted to the OpenJDK.
>> * Having a paper without having tried the ideas in code is half the fun
>> and half as useful.
> 
> I think this only presents one side of the argument here. For code of
> anything but the most basic complexity. Assuming that by paper you mean
> anything that goes beyond executable statements, including comments,
> list discussions and reviews like this one, design notes and documents,
> specifications et al
> 

My point is about priorities and the past experience with almost zero 
feedback on the former implementation, not that a paper isn't due or 
useless. On the contrary, I'm the first that would not trust my own code 
without an explanation.



> Only a paper tells you what an executing piece of code is actually doing
> 
> Only paper tells you what the results produced by that code need to be
> compared against to determine correctness, accuracy, etc
> 
> Only paper can tell you whether achieved performance is worse than or
> better than can be expected (or where in between it lies)
> 
> Only paper can explain what OpenJDK is supposed to be doing, why and how
> the specific elements of the implementation achieve that what/why i.e.
> withouth that audit trail OpenJDK will be dead in the water in no time
> at all
> 
> Having code without the paper to tell you what ideas it implements is no
> fun and n use at all.
> 

Why "no use at all"? That's unfair.

It might not be fun currently, but it is quite useful anyway in its 
present form, having produced, as of today, some 400 billions correct 
results in 1/13 of the time.



> I think that last one exemplifies a key asymmetry that always needs to
> be borne in mind. If your last contribution did not get any signifcant
> review on this or some other list then I think we really messed up.
> 

Except where noted above, I agree with these observations. Currently, 
however, I'm in the lucky position to have both the explanation and the 
code, so they don't apply for myself in this particular case.

I'm thinking on how to present the ideas in some sketchy form, just to 
share the fun and mathematically convince the inclined ones, before the 
paper is ready.



Greetings
Raffaello