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.
>
> 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
