Hello Oleksandr, I'm not sure how feasible it is to build the complete mlpack lib using the web assembly stack, so I would take a look into that first. mlpack has a few dependencies like armadillo and some parts of boost that I think have to be integrated into the wasm build pipeline. I guess as a starting point you can see if you can build armadillo and run a simple test.
About the PoC of bringing ES to RL, I like the idea, and I think that could be an interesting starting point as well. It would be interesting to see if CMAES can find a solution in a reasonable time. Thanks, Marcus > On 17. Mar 2021, at 14:45, Oleksandr Nikolskyy <[email protected]> wrote: > > Hello Marcus and Omar > > Thanks for the fast response. > > I think web assembly would be interesting for me. > I read that c++ can be translated to web assembly. Do you have some proposed > vectors of attack/nice-to-have's for a potential mlpack-web edition? Just for > me to have a starting point for brain-storming. > According to the Evolutional Strategies applied to RL: > The proof of concept of bringing ES to RL I thought of is training a net in > an environment from Open-Ai-Gym using @Zoq's gym_tcp_api and CMA-ES to > optimize weights. If you think this is too week or something else would be a > better warm-up, please let me know. > > I try to finish by the end of the week and push it to a repo on Github. > > Best > > Oleksandr > > Marcus Edel <[email protected] <mailto:[email protected]>> > schrieb am Mo., 15. März 2021, 16:34: > Hello Oleksandr, > > right now, the implementation we have in ensmallen is not directly applicable > to the RL code that is in the mlpack repository; that said it would be an > interesting project to combine the two. In combination with an extension of > the > existing CMA-ES implementation, it could make a neat project. > > About the Rust bindings, I agree with Omar would be nice to have, since C++ > can be used from within Rust, it might be a tangible project for this GSoC. > About > the JS bindings, wondering if webassembly might be a better way to go to bring > mlpack to the web, what do you think? > > I'm not sure about the Graph NN idea; supporting Graph NN's would come with a > completely new representation of the network structure we currently support, > so > I'm not sure we would have enough time to implement a solid solution by the > end > of the summer. > > I hope anything I said was helpful, let us know if you have any further > questions. > > Thanks, > Marcus > >> On 15. Mar 2021, at 05:59, Omar Shrit <[email protected] <mailto:[email protected]>> >> wrote: >> >> Hello Oleksandr, >> >> Thank you for you interest in mlpack. >> >> Evolutionary algorithms are welcomed and can be a good project, we >> already have several algorithms in ensmallen such as PSO and cmaes. >> I do not think that moving cmaes to mlpack would be a good idea. The >> objective of ensmallen is to have all optimization methods in one place, >> knowing that ensmallen was already part of mlpack. >> >> Rust binding is a good idea too, as GNN. However, non of these ideas is >> related to one another, which will make it very hard to create a solid >> and consistent GSoC project, knowing that GSoC this year is shorter. >> Therefore, I would concentrate on one idea and build a proposal on it, >> and try to have some proof of concept in order to make the proposal more >> convincing. >> >> Hope you find this helpful. >> >> Thanks, >> >> Omar >> >> On 03/15, Oleksandr Nikolskyy wrote: >>> Hi, I am Oleksandr, CS Masters student from Bonn, Germany. >>> >>> I was reading about cma es and its extensions(which is one of gsoc ideas) >>> and it is really interesting.Found also some additional sources about >>> evolution algorithms in general e.g >>> https://openai.com/blog/evolution-strategies/ >>> <https://openai.com/blog/evolution-strategies/> >>> https://blog.otoro.net/2017/10/29/visual-evolution-strategies/ >>> <https://blog.otoro.net/2017/10/29/visual-evolution-strategies/> >>> Sounds also like the results of evolutional algorithms can be used for some >>> RL problems.I would be interested to work on a proposal for GSOC, if this >>> topic is still free.Currently, the cma es is living in the ensmallen >>> library.If working on this topic, is it a good idea to work towards the >>> implementation of cma-es enhancements in the mlpack package? For example to >>> enable bindings? >>> >>> >>> Also, I had some other ideas: >>> >>> >>> 1. Create Rust bindings >>> 2. Start mlpack.js, as a ready to use node package >>> 3. Add explicit support for graph neural networks to the ann module >>> along with the core module. >>> >>> Would be happy about your feedback! :) In the meanwhile, I will continue my >>> research on the realizability of these ideas. >> >>> _______________________________________________ >>> mlpack mailing list >>> [email protected] <mailto:[email protected]> >>> http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack >>> <http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack> >> >> _______________________________________________ >> mlpack mailing list >> [email protected] <mailto:[email protected]> >> http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack >> <http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack>
_______________________________________________ mlpack mailing list [email protected] http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack
