> On 24 Mar 2019, at 23:57, Gilles Sadowski <gillese...@gmail.com> wrote:
>
>> [...]
>
> I think that we mostly agreed in another thread.
>
>>
>> Summary of my proposals:
>>
>> - Keep the order in the user guide as is but move MT next to MT_64
>> - Auto generate the GeneratorsList from the RandomSource enum
>> - Update all the file names and the user guide to point to the renamed files
>> for the new order
>> - New generators can go anywhere in the user guide table if related to
>> others, or at the end
>> - Assert that the ProviderList in [simple] matches RandomSource in size
>> - Add test that a null seed passed to RandomSource.create can build a
>> generator that passes the test for randomness
>> - Update the ProviderBuilder to handle zero filled seeds for generators that
>> cannot handle them
>> - Update the ProviderBuilder to handle an empty array as if it were a null
>> seed
>
> I'm not sure about the last two points; I imagined that one would want to be
> able to explicitly see the limitation of some algorithm.
> A "null" seed is convention for telling the library to provide a good sequence
> without much hassle, but if a user says that the seed is zero, then it might
> be useful to honor that. One should read the doc. :-)
OK. So only try and guarantee a functional provider if no seed is given and the
seed is ‘correctly' made by the library. Let the user mess up their own seed.
That follows from having no checks on the input seeds (beyond length) in the
actual generators in the core module too.
I’ll do this when I have an attempt to update the ProviderBuilder code for
building generators.
Currently I am still refining the command line program to run the stress test.
It started as a small job that got big. I’ll create a PR for discussion and
testing when it is done. Hopefully this week.
>
> 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
