Hello.

Le lun. 29 nov. 2021 à 07:05, Avijit Basak <avijit.ba...@gmail.com> a écrit :
>
> Hi All
>
>        Here is a sample use of two options.
>
> *Option1*: Declaring factory interface in MutationPolicy, CrossoverPolicy
> and SelectionPolicy. A sample implementation has been shown here for
> MutationPolicy. Similar would be required for all other relevant interfaces
> and implemented classes.
>
> --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... args);
>
>          default MutationPolicy<P> create(RandomSource rng) {
>              return create(rng, null);
>          }
>          default MutationPolicy<P> create() {
>              return create(RandomSource.SPLIT_MIX_64);
>          }
>      }
>  }
> //Implementation Class
> public class IntegralValuedMutation<P> implements MutationPolicy<P> {
>
>     private final UniformRandomProvider provider;
>
>     private IntegralValuedMutation(RandomSource rng) {
>          provider = ThreadLocalRandomSource.current(rng);
>     }
>     ...
>     ...
>     public static class MutationFactory<Q> implements Factory<Q> {
>         private static final MutationFactory instance = new 
> MutationFactory<>();

Why a singleton?
[AFAICT, it is an unnecessary limitation, and such design choices should
be left to the application's developer.]

>         private MutationFactory() {}
>
>         @Override
>         public MutationPolicy<Q> create(RandomSource rng, Object... args) {
>             return new IntegralValuedMutation<>(args[0], args[1]);
>         }

Why is the "Object" type used here?

>         public static <Q> MutationFactory<Q> getInstance() {
>             return instance;
>         }

This is not part of my suggested API.

>     }
> //Usage
>         MutationPolicy<Integer> policy =
> IntegralValuedMutation.MutationFactory.<Integer>getInstance().create();
> --CUT--

This is not how I imagined an application developer (who is not
interested in the details of how the PRNG sequence is generated)
would call the library's API default factory for the given class.
Unless I'm mistaken, it should just be
---CUT---
MutationPolicy<Integer> policy = IntegralValuedMutation.getFactory().create();
---CUT---

Such "getFactory()" methods could be construed as a convenience
provided, or not, to the application's developer by the implementer of the
"Chromosome"-specific operator ("IntegralValuedMutation" in this case).

>
> Option2:  Optional constructor argument can also be used as an alternative
> solution.
> --CUT--
> public class IntegralValuedMutation<P> implements MutationPolicy<P> {
>     private final UniformRandomProvider provider;
>     public IntegralValuedMutation() {
>         provider = ThreadLocalRandomSource.current(RandomSource.DEFAULT);
> //DEFAULT is a chosen source.
>     }
>     public IntegralValuedMutation(RandomSource rng) {
>         provider = ThreadLocalRandomSource.current(rng);
>     }
>     ...
> }
> //Usages
> MutationPolicy<Integer> policy = new IntegralValuedMutation(rng);

As per the recent updates of the math-related code bases, the
public API should provide factory methods (constructors should
be private).

With the API suggested above, the equivalent usage would be
---CUT---
MutationPolicy<Integer> policy =
IntegralValuedMutation.getFactory().create(rng);
---CUT---

Regards,
Gilles

>
> Option2 looks to be much simpler regarding implementation and I would vote
> for the same if we decide to allow customization of RandomSource.
>
> Thanks & Regards
> --Avijit Basak
>
>
> On Mon, 22 Nov 2021 at 19:28, Gilles Sadowski <gillese...@gmail.com> wrote:
>
> > [...]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to