[
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
