RFR: 8326227: Rounding error that may distort computeNextGaussian results [v3]

[Jaikiran Pai]

On Wed, 21 Feb 2024 02:18:08 GMT, Chris Hennick <duke at 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