Hello. Le mar. 21 déc. 2021 à 16:21, Avijit Basak <avijit.ba...@gmail.com> a écrit : > > 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.
Within a given thread there will be *one* RNG instance; that's what I meant by "shared". Of course you are right that that instance is not shared by multiple threads (which would be a bug). The performance loss is because it will be necessary to call ThreadLocalRandomSource.current(RandomSource source) for each access to the RNG (since it would be a bug to store the returned value in e.g. an operator instance that would be shared among threads (as you suggest below). > >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. I would be wary to go on that path; better consider making (deep) copies. We can have multiple instances of an operator, all being configured in the same way but being different instances with no risk of a multithreading bug. > So even if we provide > the customization at the operator level we cannot avoid sharing. We can, and we should. What we probably can't avoid sharing is the instance that represents the population of chromosomes. > > >> 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 I did. Maybe it's time to create a dedicated branch for the GA functionality so that we can try out the different approaches. > > >> 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. I don't get why we should support extensions outside this library. Initially we discussed about having a light-weight library, for easier usage than alternative existing framework(s). > 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. It does not look like this would need an extension, only configuration of the range. > 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. We should aim at coding the GA logic through (Java) interfaces, and not expose the "abstract" classes. Extending the functionality, if necessary, should be contributed back here. Regards, Gilles >>> [...] --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
