Hi All

        Please see my comments:

>The provider returned from ThreadLocalRandomSource.current(...) should
>only be used within a single method.
-- I missed the context of the thread in my previous mail. Sorry for the
previous communication. We can only cache the RandomSource's enum value and
reuse the same locally in other methods. According to the analysis, the
current implementation(In PR#199) with pre-configured RandomSource would
work correctly.
--CUT--
public final class RandomProviderManager {
    /** The default RandomSource for random number generation. **/
    private static RandomSource randomSource =
RandomSource.XO_RO_SHI_RO_128_PP;
    /**
     * constructs the singleton instance.
     */
    private RandomProviderManager() {}
    /**
     * Returns the (static) random generator.
     * @return the static random generator shared by GA implementation
classes
     */
    public static UniformRandomProvider getRandomProvider() {
        return
ThreadLocalRandomSource.current(RandomProviderManager.randomSource);
    }
}
--CUT--

@Alex Herbert <alex.d.herb...@gmail.com>, kindly share if you see any
challenge to this.
My original implementation did not allow any customization of RandomSource
instances. There was a thought in review for customization of RandomSource,
so these options were considered. I don't think this would make any
difference to algorithm functionality. Even earlier I used Math.random()
which worked equally well. So my *vote* should be *against* this
customization.
I think first we need to decide on whether we really need this
customization and if yes then why. Then we can decide on alternate
implementation options.

>As per the recent updates of the math-related code bases, the
>public API should provide factory methods (constructors should
>be private).
-- private constructors will make public API classes non-extensible. This
will severely restrict the extensibility of this framework which I want to
avoid. I am not sure why we need to remove public constructors. It would be
helpful if you could refer me to any relevant discussion thread.


Thanks & Regards
--Avijit Basak


On Mon, 29 Nov 2021 at 23:47, Gilles Sadowski <gillese...@gmail.com> wrote:

> Le lun. 29 nov. 2021 à 19:07, Alex Herbert <alex.d.herb...@gmail.com> a
> écrit :
> >
> > Note that your examples have incorrect usage of ThreadLocalRandomSource:
>
> The detailed explanation confirms what I hinted at previously: We
> should not use "ThreadLocalRandomSource" from within the library
> because we can easily do otherwise (and just as transparently for
> the user).
>
> Gilles
>
> > [...]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-- 
Avijit Basak

Reply via email to