On Wed, 21 Feb 2024 02:18:08 GMT, Chris Hennick <d...@openjdk.org> wrote:
>> This provides a slightly more accurate bounding limit for >> `computeNextExponentialSoftCapped` when calling it from >> `computeNextGaussian`. This could cause the `while >> (computeNextExponentialSoftCapped(rng, limit) < limit)` check in >> `computeNextGaussian` on line 1402 to always be true, making the >> `nextGaussian` runtime unbounded in the worst case; but more likely, it >> would give a result that was truncated too close to zero. >> >> This change is being tested prior to submission to OpenJDK by >> https://github.com/openjdk/jdk/pull/17703/commits/b8be051cbf40a6a05fafc6a2c76942e9e0b11fdf. > > Chris Hennick has updated the pull request incrementally with one additional > commit since the last revision: > > Bug fix: add-exports was for wrong package src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 1222: > 1220: // Math.round rounds toward infinity in conversion to long; > adding 1.0 corrects for any > 1221: // downward rounding error in the division > 1222: maxExtraMinus1 = Math.round(1.0 + maxValue / > DoubleZigguratTables.exponentialX0); We had asked Guy Steele for his inputs on these proposed changes. Guy reviewed these changes and for this specific if/else block change, he notes that (I've paraphrased it): > the (proposed new) computation of `maxExtraMinus1` looks okay to me: it’s > always okay for maxExtraMinus1 to be a bit larger than you might expect; the > only downside is that the (for) loop starting (on the next line) might take > extra iterations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17703#discussion_r1636013052
