Hello.
Le mar. 9 nov. 2021 à 13:05, Avijit Basak <avijit.ba...@gmail.com> a écrit :
>
> Hi All
>
> >Depending on released code (e.g. version 3.6.1 of Commons Math)
> >is fine too for the "main" codes of the "examples" module.
> >Setting up all the "policies" (mutation, crossover, ...) must be done
> >anyways, by the user; the above factories just add an argument to
> >be passed at instantiation.
>
> >> Separate RandomSource for each place may be
> >> redundant.
>
> >I'm not sure what you mean by "redundant".
> >Since the RNG instances are not thread-safe, either separate sources
> >*must* be used or the synchronization must be handled separately (as
> >done for the "ThreadLocalRandomSource" possibly with a performance
> >loss).
>
> >> I also believe the system should provide a default option for
> >> RandomSource instead of completely depending on the choice of users.
>
> >Why?
> >This is a library, and the RNG should be viewed as an input (user's choice
> >to be made at the application level).
> >There are multiple problems (already noted previously):
> >1. It hardcodes a specific "default" source (whereas the GA functionality
> >is "agnostic" about which source is actually used).
> >2. The RNG instance is shared among all the classes that need it (which
> >makes access unnecessarily slower).
> >3. The static field "randomSource" is mutable; this is looking for trouble
> >(race condition).
>
> --The way I tried to design this is that GA functionality should likely be
> agnostic to the rng feature. If we accept the randomsource as a parameter
> to GA operators it would likely mandate the users having knowledge about
> rng.
Usage of [RNG] is pretty obvious.
> Given the vast amount of RandomSources I am not sure how many options
> will be really considered by users and mostly might go for JDK source.
This is the only one they should *not* use!
> This
> will increase the learning curve of users as well as a bit of complexity of
> API.
IIUC, there is already a significant increase in the API complexity wrt
the previous implementation.
Moreover we could add another default method to interface:
---CUT---
public interface MutationPolicy<P> {
Chromosome<P> mutate(Chromosome<P> original, double mutationRate);
interface Factory<P> {
/**
* Creates an instance with a dedicated source of randomness.
*
* @param rng RNG algorithm.
* @param seed Seed.
* @return an instance that must <em>not</em> be shared among threads.
*/
MutationPolicy<P> create(RandomSource rng, Object seed);
default MutationPolicy<P> create(RandomSource rng) {
return create(rng, null);
}
default MutationPolicy<P> create() {
return create(RandomSource.SPLIT_MIX_64);
}
}
}
---CUT---
> Customization of any operators will mandate the implementation of the
> factory as well.
What kind of customization are you referring to?
I'd have thought that this library would provide all the common operators
for all the commonly used genotypes.
> [IMHO] The users do not need to choose the RandomSource for each operator
> separately.
With the above default method, they won't need to.
[The "create()" method won't specify the actual algorithm being used,
so that we can change it at any time. We could even imagine it to be
randomly chosen at instantiation (similar to how the seeds can be
auto-generated in "RandomSource").]
> That is the reason I proposed the use of customization option
> in the RandomNumberGenerator class itself. But this is also true that it
> cannot mandate the configuration only once. In case that is configured
> inside any custom operator then that might result in race conditions once
> we go for parallel implementation.
IMO, this would be a plain bug.
> [IMHO] We really don't need users to customize RandomSource for each and
> every operator or for the application. Can we stick to the previous
> implementation and remove the configure(RandomSource rng) method of
> RandomNumberGenerator class? Kindly share your thoughts.
I did, above.
Hopefully we can get other opinions as to what is the better design choice.
Gilles
>>> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
