[jira] [Commented] (MATH-936) RandomDataGenerator#nextLong violates bounds

["Luc Maisonobe (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MATH-936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13597986#comment-13597986 ] 

Luc Maisonobe commented on MATH-936:
------------------------------------

Shouldn't we completely avoid using nexDouble() here?
The underlying RandomGenerator does provide nextBytes(). Looking at BitsStreamGenerator, we see how the stream of bytes is used to implement nextInt(int) with a rejection method. The same could be done for a long.

As a side note, it would even be worth (for 4.0) to add nextLong(long) in the RandomGenerator interface too.
                
> RandomDataGenerator#nextLong violates bounds
> --------------------------------------------
>
>                 Key: MATH-936
>                 URL: https://issues.apache.org/jira/browse/MATH-936
>             Project: Commons Math
>          Issue Type: Bug
>    Affects Versions: 3.1
>            Reporter: Ralf Wiebicke
>              Labels: random
>         Attachments: MATH-936.patch, RandomGeneratorLongTest.java
>
>
> I attached a test.
> If the underlying RandomGenerator returns 0.0, then nextLong returns Long.MIN_VALUE, although the lower bound is Long.MIN_VALUE+1.
> The javadoc of RandomGenerator#nextDouble does not clearly define, whether the result includes the lower border of 0.0 or not.
> In java.util.Random it clearly defined as included: "uniformly from the range 0.0d (inclusive) to 1.0d (exclusive)". And the existence of JDKRandomGenerator suggests, that RandomGenerator should have the same contract.
> I tested with version 3.1.1 from mvnrepository

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira