[mlpack] GSoC'22 Project Proposal: Better Stack Layering & Ready-to-Use Model

[Shubham Agrawal]

Hello Marcus,

By breaking API, I meant both old and new API as I am thinking about
defining the link between layers.
Example -
Layer2 = Layer2Type(..PrevLayerRequired)
Something on this line. So that people do not need to know complex API for
making links between layers as it might be confusing for many people. I
have thought about giving backward compatibility, and it probably will be
easy to give backward compatibility as every ANN created earlier comes
under DAG.
I will convert all std::vector to std::map in multi_layer.hpp file <
https://github.com/shubham1206agra/mlpack/blob/ann-vtable/src/mlpack/methods/ann/layer/multi_layer.hpp>
so that I can convert everything to DAG structure. I am thinking of
storing graph edges in as adjacency lists format.

About the 2nd project, let us implement most of the models as in Pytorch.
All models only for a forward pass don't take much memory. When GPU support
comes, it will be helpful if we can give more variety of models
architecture. And I will look for non-implemented layers too.

Regards
Shubham Agrawal

On Sat, Mar 26, 2022 at 8:56 PM Marcus Edel <marcus.edel at fu-berlin.de>
wrote:

> Hello Shubham,
>
> Thanks for your interest in the project. I think you are aware that Ryan
> is currently refactoring the ann codebase.
> So when you say "This project will introduce breaking changes in ANN API."
> is that based on the current API or
> the updated API, from the table PR? There was already some discussion on
> the mailing list about the DAG project:
>
> http://knife.lugatgt.org/pipermail/mlpack/2022-March/004648.html
>
> In case you haven't seen it already. It should be possible to implement
> DAG without breaking the new API,
> especially since it introdcues some new concepts, like the MultiLayer
> which we can build on.
>
> I like the second idea as well, one thing you should keep in mind that we
> currently don't have GPU support
> (will change soonish), that is why we focused in the past on smaller
> models that you can run on a resource
> constrained device, mobilenet is one example. So in your proposal I would
> go through the list and select reasonable
> models, also, you should check if one of the models require the
> implemenation of a non implemented operation.
>
> I hope anything I said was helpful, let me know if I should clarify
> anything further.
>
> Thanks
> Marcus
>
>
> > On Mar 15, 2022, at 12:09 AM, Shubham Agrawal <
> shubham.agra1206 at gmail.com> wrote:
> >
> > Hello everyone
> >
> > I hope this email finds you well. My name is Shubham Agrawal. I am
> currently doing my undergrad studies (3rd year) at IITD, India. I have been
> contributing to mlpack organization for the past 2 to 3 months, and I want
> to participate in GSoC '22 under this organization. I wanted to propose two
> large projects (~350 hours), and I wish to work on at least one of the
> ideas. Or any other idea can work too if there is some issue with my
> proposal.
> >
> > I am attaching a pdf document that contains my proposal. I hope to get
> valuable feedback from the community for building my proposal with this
> thread.
> >
> > I am looking forward to hearing from you.
> >
> > Regards
> > Shubham Agrawal
> > GitHub username - shubham1206agra
> > <gsoc_proposal_draft.pdf>_______________________________________________
> > 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/20220327/9949c9a6/attachment.htm>