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 <[email protected]> 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 < > [email protected]> 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 > > [email protected] > > http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack > >
_______________________________________________ mlpack mailing list [email protected] http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack
