On 1/26/16 6:10 AM, Phil Steitz wrote:
> On 1/26/16 1:47 AM, Luc Maisonobe wrote:
>> Le 26/01/2016 01:13, Gilles a écrit :
>>> Hi.
>> Hi Gilles,
>>
>>> In CM, a base class "BitsStreamGenerator" contains methods for
>>> generating various primitive types from a bit source (to be
>>> implemented by subclasses by overriding the "next(int bits)"
>>> method).
>>> For example, to get a random "long" value, the following code
>>> is called:
>>> ---CUT---
>>> public long nextLong() {
>>> final long high = ((long) next(32)) << 32;
>>> final long low = (next(32)) & 0xffffffffL;
>>> return high | low;
>>> }
>>> ---CUT---
>>>
>>> If the bit source were provided by the JDK's "Random" class,
>>> is it assumed that the "long" value generated by the above
>>> code will always be equal to the "long" value generated by
>>> the call to JDK's "Random" class?
>> No. There is nothing said anywhere in the javadoc that would imply
>> one implementation of nextLong is the same as another implementation.
>> The only thing that user can exapect is that when they choose one
>> implementation, it is consistent, i.e. it is "random enough" and
>> "not biased". Two different implementations can fulfill these
>> requirements without producing the same sequence.
>>
>>> In other words, how "standard" are the default implementations
>>> of the methods defined in "BitsStreamGenerator"?
>> I don't think there are any standard to abide by.
>>
>>> And what are the compatibility requirements with respect to
>>> reproducibility of the sequences (between releases of the
>>> library)?
>> It's a grey zone, IMHO. It is nice to preserve reproducibility
>> as changing it changes the reference test cases with fixed seeds.
> Did the original test cases for the generators that came in with
> Mantissa come from external references? If so, it would be good to
> keep them for at least the bit streams themselves so we can be sure
> that what we have implemented is the standard implementation of the
> algorithm. If we leave the standard algorithms themselves behind,
> it's then on us to produce tests to verify lots of properties beyond
> just lack of bias and uniformity.
>
> Phil
>> On the other hand, too much compatibility really is a pain, we
>> feel it constantly, so I would say that as soon as we need to
>> change the sequence, we can just do it, and check all the tests
>> we know of (i.e. those of our own library) still pass and we
>> go forward.
Sorry, I mean to add that while (maybe a bit strangely) the JDK
commits to a specific long-from-bits recipe (see the javadoc for
j.u.Random#nextLong) we have never done that and I am OK with
changing that if we get better performance as long as uniformity
tests pass.
Phil
>>
>> best regards,
>> Luc
>>
>>> Regards,
>>> Gilles
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
