[mlpack] GSOC 21

[Marcus Edel]

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 <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/20210315/c1f12df6/attachment-0001.htm>