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

[Andrew Dinn]

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.

> 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

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.

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.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander