[mlpack] GSOC 21

[Oleksandr Nikolskyy]

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> 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> 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://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
> http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack
>
>
> _______________________________________________
> mlpack mailing list
> mlpack at lists.mlpack.org
> http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://knife.lugatgt.org/pipermail/mlpack/attachments/20210317/99ffc43a/attachment-0001.htm>