[mlpack] Proposing a possible project for GSOC 2021

[Nippun Sharma]

Hi Ryan,
I have submitted my draft proposal through the GSoC portal.
There, I have written my ideas in a much more clear way and giving examples
wherever possible. I have also provided proof of concept.
It would be better if you can provide your feedback over there.
Thanks in advance.

Regards,
Nippun Sharma

On Tue, Mar 30, 2021 at 7:29 PM Nippun Sharma <inbox.nippun at gmail.com>
wrote:

> Hi Ryan,
> Thanks for your feedback.
>
>
>> Why not just use the existing algorithms that we have implemented?  They
>> are already grouped into categories.
>>
>
> I meant the currently implemented algorithms only. Yes, I saw that they
> are already
> grouped for documentation purposes, thanks.
>
> Please keep in mind that the questions highlighted in that issue are
>> starting places for a design.  The purpose is not to provide specific
>> questions which require specific answers, but instead to mention some
>> issues that probably require some deep thought as part of a proposal.
>> The questions aren't even comprehensive---as you work on your proposal,
>> be sure to spend time understanding the existing code and system so that
>> you can have an idea of whether what you're proposing is feasible to do
>> in the amount of time that you'll have.
>>
>>
> Sure, I will keep these points in mind while writing the proposal and try
> to include things that
> are feasible in the limited period of time.
>
>
> I had some doubts that I encountered while writing my proposal:
> 1) This is related to changing the markdown binding documentations. An
> easy way to tackle this problem can be to write the documentation of the
> "_fit_main.cpp", "_predict_main.cpp" individually (similar to what has been
> done for "gmm_generate", "gmm_train"). Here, we might have to change
> certain macros such as the PRINT_CALL macro to change the code snippet
> shown in the docs. We can also group all the "_main.cpp" files related to
> the same method, so that all related files are shown together inside the
> documentation (for example, we can group
> "linear_regression_train_main.cpp", "linear_regression_predict_main.cpp"
> and call that group as "linear_regression"). This grouping might also be
> helpful elsewhere. What do you think about this?
>
> 2) This is a big refactoring, as it would also involve changing the tests
> (and adding more tests) in "tests/main_tests" along with changing all
> "mlpack/methods" available. So, it might not be possible to complete all
> the things in the limited GSoC period. One solution that I thought was to
> implement all the required functions and create the framework during GSoC
> and change some (depending on the time left) bindings. I can then change
> the rest of the bindings post-gsoc. Do you think that this can be possible?
>
> Regards,
> Nippun Sharma
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://knife.lugatgt.org/pipermail/mlpack/attachments/20210402/011d2209/attachment.htm>