Hi Raffaello
While I don't have feedback on the actual math, here's a few suggestions: - there's some use of non-ASCII characters in the patch. I don't think this is common in the JDK's Java sources, so you might want to replace them with their Unicode escapes. The characters are: ≤ (\u2264), ∞ (\u221e), × (\u00d7), ≥ (\u2265), … (\u2026), ≠ (\u2260), ⌊ (\u230a), ⌋ (\u230b), · (\u00b7), β (\u03b2) - there are 2 invocations of a deprecated String constructor for performance reasons. I don't know how big the performance difference is, but I would suggest replacing these invocations with `new String(bytes, StandardCharsets.US_ASCII)` instead, and filing a bug for the performance difference with the deprecated constructor - there are 2 occurrences of a typo "left-to-tight" Other than that, I can only say this is an impressive piece of work, so I hope some official Reviewers will help you add your contribution to the JDK. Kind regards Anthony ________________________________ From: core-libs-dev <[email protected]> on behalf of Raffaello Giulietti <[email protected]> Sent: Monday, May 6, 2019 2:08:48 PM To: core-libs-dev Subject: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results Hi, no new code this time, only a warm invitation to review the rather substantial patch submitted on 2019-04-18 [1] and the CSR [2]. I spent an insane amount of (unpaid) free time offering my contribution to solve a bug known since about 15 years. Thus, I think it is understandable that I'd like to see my efforts come to a successful conclusion, ideally for OpenJDK 13. Greetings Raffaello P.S. Some enjoyable properties of the novel algorithm: * No objects are instantiated, except, of course, the resulting String. * Loop-free core algorithm. * Only int and long arithmetic. * No divisions at all. * 16x speedup (jmh). * Randomized, yet reproducible deep diving tests (jtreg). * Clear, unambiguous spec. * All floats have been tested to fully meet the spec. * Fully documented in [3] or in comments. ---- [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-April/059783.html [2] https://bugs.openjdk.java.net/browse/JDK-8202555 [3] https://drive.google.com/open?id=1KLtG_LaIbK9ETXI290zqCxvBW94dj058
