[mlpack] GSOC 21

[Marcus Edel]

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 <onikolskyy at gmail.com> 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 <marcus.edel at fu-berlin.de <mailto:marcus.edel at fu-berlin.de>> 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 <omar at shrit.me <mailto:omar at shrit.me>> 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
>>> mlpack at lists.mlpack.org <mailto:mlpack at lists.mlpack.org>
>>> http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack <http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack>
>> 
>> _______________________________________________
>> mlpack mailing list
>> mlpack at lists.mlpack.org <mailto:mlpack at lists.mlpack.org>
>> http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack <http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://knife.lugatgt.org/pipermail/mlpack/attachments/20210318/4c7e8870/attachment-0001.htm>