On 2018-09-27 16:55, Andrew Dinn wrote:
Hi Raffaello,
On 27/09/18 15:20, raffaello.giulietti@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