Hi >Isn't a GA inherently parallel? >If so, why not take advantage of the concurrency tools provided by the JDK? -- Are we planning to implement multi-threading for GA operations even as part of a single population or only for multi-population parallel GA. -- We can implement different types of co-evolution as part of parallel GA. Need to decide on the corresponding strategies we are going to incorporate.
Thanks & Regards --Avijit Basak On Wed, 14 Apr 2021 at 05:53, Gilles Sadowski <gillese...@gmail.com> wrote: > Le mar. 13 avr. 2021 à 18:21, Avijit Basak <avijit.ba...@gmail.com> a > écrit : > > > > Hi > > > > Please find my comments below. > > > > >> I don't follow the distinction "prod" vs "non-prod". > > -- Actually in Prod we really need a very high performing system. So > > use of implicit parallelism in spark would help us to achieve it. But for > > other types of work like POC or R&D we may not need such performance. > > Isn't a GA inherently parallel? > If so, why not take advantage of the concurrency tools provided by the JDK? > > > >> the question was actually whether you are willing to modularize CM > > -- I am not much aware of other ml components in commons. I would > look > > into it. > > I've mentioned them in earlier messages: > * Self-organizing feature map (artificial neural net) > * Clustering > > The former is multi-threaded; the latter should be refactored to > take advantage of multi-threading. > > > >>You did not expand about the usability/performance (e.g. the issue of > > multi-threading) > > -- Are we planning to incorporate parallel GA. > > Aren't you? > > > Then multi-threading > > would be a more appropriate option. > > IMHO, a necessary one. > > > >> So, as a way forward, I would suggest that you create a project on > > GitHub (copying all the settings from a *Commons modular* component, > such as > > "Commons Numbers") > > -- Could you kindly share the GitHub repository URL for any Commons > > modular component. > > https://github.com/apache/commons-rng > https://github.com/apache/commons-numbers > https://github.com/apache/commons-geometry > https://github.com/apache/commons-statistics > > > > > Thanks & Regards > > --Avijit Basak > > > > > > On Tue, 13 Apr 2021 at 18:29, Gilles Sadowski <gillese...@gmail.com> > wrote: > > > > > Hello. > > > > > > Le lun. 12 avr. 2021 à 17:21, Avijit Basak <avijit.ba...@gmail.com> a > > > écrit : > > > > > > > > Hi > > > > > > > > Sorry for the delayed response. Thanks for your patience. > Please > > > > find my comments below: > > > > > > > > (1) Why not Spark? [At least post over there (?).] > > > > --We can move to Spark. But it will be very much useful if the > > > things > > > > can also run without Spark. The use of Spark would make more sense > in a > > > > production environment. But the portability of the library will be > more > > > > useful for the non-prod environment. > > > > > > I don't follow the distinction "prod" vs "non-prod". > > > > > > > Definitely, we can reach the Spark > > > > team and query. > > > > > > That would be a good idea... > > > > > > > (2) Further develop a monolithic CM? [Who will do it?] > > > > --I can help with the upgrade of the existing library related > to > > > GA > > > > functionality. > > > > > > Sure, but nobody is currently working on (2). > > > > > > > (3) Modularize CM? [Who will do it?] > > > > --I can help with the upgrade of the existing library related > to > > > GA > > > > functionality. > > > > > > I don't doubt it; but the question was actually whether you are willing > > > to modularize CM (that is: in addition to, and before, contributing to > > > the GA functionality). > > > > > > > (4) New component (with another name) with the proposed contents? > > > > --This is the best option if permitted. > > > > > > Currently, only the two of us are in favour of this alternative. > > > > > > Nobody, by their action, is really in favour of any of the other > > > alternatives. > > > So, as a way forward, I would suggest that you create a project on > GitHub > > > (copying all the settings from a Commons modular component, such as > > > "Commons Numbers"), to be eventually integrated here, once its > potential > > > has been demonstrated. > > > > > > > The code which I have written can be reused with minor > > > modifications. > > > > So it won't take too much effort for this activity. > > > > > > You did not expand about the usability/performance (e.g. the issue of > > > multi-threading)... > > > > > > Regards, > > > Gilles > > > > > > >> [...] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Avijit Basak
