Le mar. 20 avr. 2021 à 16:09, Avijit Basak <avijit.ba...@gmail.com> a écrit : > > Hi > > > Did you ask "Spark" people about their opinion about it? > -- Not yet. I am not sure what would be the right option for > this communication. It will be good if you can approach them.
You are the one who proposes a functionality that might be of interest to the "Spark" project, perhaps on some condition on their part which *you* are going to have to accept (or not). In other words: It would be useless that *I* go and tell them there exist some code in Commons Math which they could take an adapt for their project (they can always do that). What might be of value to them (as to the Commons project, too), is a contributor willing to do the necessary work to create or improve a community-supported feature. > > where it can be used in real-life (performance-wise) > applications, then you should demonstrate it > -- Do we have any kind of performance benchmark or use case > regarding this? Please assume that *you* are the person with the most GA expertise in this forum. There certainly are unit tests for the GA functionality, but I don't think there are benchmarks; certainly, one task would be to set up a module for (JMH-based) experimentation. > Once that is decided, One mantra of ASF communities is that "those who do the work get to decide". [The PMC can decide (by vote) whether to accept a new component; but it's up to you to show that it's worth it (with the risk that the PMC won't accurately judge the contribution, unfortunately)...] > then I can proceed with this. There is already a long list of things that can be done. You don't *have* to contact "Spark" if you don't feel that it's the right project for your work. You could just hope for the best, and start somewhere else (modularization of Commons Math, a fork on GitHub of of CM ML-related codes, and so on). The one thing which I won't be helping with is merging ad-hoc GA-related changes into the current CM codebase. This doesn't preclude that other committers might want to do that for you; however judging by the last 5 years, I wouldn't count too much on it. ;-) Regards, Gilles > > > Thanks & Regards > --Avijit Basak > > On Mon, 19 Apr 2021 at 18:51, Gilles Sadowski <gillese...@gmail.com> wrote: > > > Hello. > > > > Le lun. 19 avr. 2021 à 08:35, Avijit Basak <avijit.ba...@gmail.com> a > > écrit : > > > > > > 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 > > > > This seems an obvious improvement to our current implementation > > (in case a chromosome's evaluation is not population-dependent). > > > > > 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. > > > > The discussion is still about the "administrative" question of whether > > any of this should be implemented in the "Commons" project... > > > > Did you ask "Spark" people about their opinion about it? > > > > As I said, if you are confident that you can bring our implementation to > > a state where it can be used in real-life (performance-wise) applications, > > then you should demonstrate it (in order to convince other people from > > the Commons PMC that it is worth engaging in long-term maintenance). > > AFAICT, a way to do it would be to create a GitHub project (aimed at > > becoming a new "machine learning" component, or a maven/JPMS > > module within Commons Math). > > > > Best regards, > > Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
