Hi.
Le mar. 30 nov. 2021 à 06:40, Avijit Basak <avijit.ba...@gmail.com> a écrit :
>
> 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.
Several problems with this approach (raised in previous messages IIRC):
1. Potential performance loss in sharing the same RNG instance.
2. Less/no flexibility (no user's choice of random source).
3. Error-prone (user can access/reuse the "UniformRandomProvider" instances).
Again: "ThreadLocalRandomSource" is an ad-hoc workaround for correct but
"light" usage of random number generation in a multi-threaded application; GAs
make "heavy" use of RNG, thus it is does not seem outlandish that all the RNG
"clients" (e.g. every "operator") creates their own instances.
IMHO, a more important discussion would be about the expectations in a
multithreaded context: E.g. should an operator be shareable by different
threads? And if not, how does the API help application developers to avoid
such pitfalls?
> 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.
Quite right. But the customization can come at zero cost for the users
who don't need it. Admittedly it's a little more work on the part of the
developer(s) but it's a one off cost (and I'm fine working on that part of
the library once other, more important, things have been settled).
> Even earlier I used Math.random()
> which worked equally well. So my *vote* should be *against* this
> customization.
Mine is against using "ThreadLocalRandomSource"...
> 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.
Allowing extensibility is a huge burden on library maintainers. The
library must have been designed to support it; hence, you should
first describe what kind(s) of extensions (with usage examples) you
have in mind.
Gilles
>
>
> 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
