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

[Shubham Agrawal]

Sorry for the late reply.

My thought of representing DAG as an adjacency list approach. Storing
pointers to the next and previous layers is required for backward and
forward passes in the layer itself. That's why I am trying to use 2 utility
layers to handle start and end points. I think I have provided some
pseudocode for these passes. But I haven't thought about anything too
specific for now. We can also set up a meeting to discuss this.

About the models list, I have selected some candidates models.
1. AlexNet -
https://proceedings.neurips.cc/paper/2012/file/c399862d3b9d6b76c8436e924a68c45b-Paper.pdf
2. SqueezeNet - https://arxiv.org/pdf/1602.07360.pdf
3. VGG 11, 13, 16, 19 - https://arxiv.org/pdf/1409.1556.pdf
4. Xception - https://arxiv.org/pdf/1610.02357.pdf
5. PolyNet - https://arxiv.org/pdf/1611.05725.pdf
6. NASNet - https://arxiv.org/pdf/1707.07012.pdf
About NASNet and PolyNet, they can't be retrained for now on mlpack because
of missing GPU support, and they take time on GPU for training.

Please guide me on further actions.

Regards
Shubham Agrawal

On Tue, Apr 5, 2022 at 8:13 AM Marcus Edel <marcus.edel at fu-berlin.de> wrote:

> Okay, that makes it more clear; not sure did you already think about how
> the DAG
> graph should look from a very high-level point of view? The pdf has some
> pointers in that direction. I wondered if you have some further
> pseudo-code that
> goes in that direction?
>
> My recommendation is to select between 2-4 models, depending on the
> complexity;
> we would have to implement some additional operations for some of the
> models, so
> we should keep that in mind.
>
> On Apr 3, 2022, at 8:09 AM, Shubham Agrawal <shubham.agra1206 at gmail.com>
> wrote:
>
> A gentle reminder, as you may have missed the previous email.
>
> On Sun, Mar 27, 2022 at 1:13 PM Shubham Agrawal <
> shubham.agra1206 at gmail.com> wrote:
>
>> 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
>>>
>>> _______________________________________________
> 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/20220407/6468d243/attachment.htm>