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
