Hi All
Please see my comments. Sorry for the delayed response.
>Several problems with this approach (raised in previous messages IIRC):
>1. Potential performance loss in sharing the same RNG instance.
-- As per my understanding ThreadLocalRandomSource creates separate
instances of UniformRandomProvider for each thread. So I am not sure how a
UniformRandomProvider instance is being shared. Please correct me if I am
wrong.
>2. Less/no flexibility (no user's choice of random source).
-- Agreed.
>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?
-- Once we implement multi-threading in GA, same crossover and mutation
operators will be re-used across multiple threads. So even if we provide
the customization at the operator level we cannot avoid sharing.
>> 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"...
-- What is the wayout other than that. Please suggest.
>> 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.
--The library should be extensible to support customization. Users should
be able to customise or provide their own implementation of genetic
operators for crossover and mutation. The chromosome classes should also be
open for extension. E.g. any developer should be able to extend the
IntegralChromosome class and define a child class which explicitly
specifies the range of integers to be used. I have initially implemented
the Binary chromosome and the corresponding binary mutation following the
same pattern. However, restricting extension of concrete classes by private
constructor does not prevent users from extending the abstract parent
classes.
Thanks & Regards
--Avijit Basak
On Tue, 30 Nov 2021 at 19:20, Gilles Sadowski <gillese...@gmail.com> wrote:
> 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
>
>
--
Avijit Basak
