06:17 < AakashkaushikGit> Hey @zoq I am getting this error where it says that the `GradientUpdate` function is not defined even though i have included the `gradient_update.hpp` from utils, can you take a look [here](https://github.com/zoq/mlpack/pull/1), also anybody's helps would be appreciated. been stuck on it for a while.

06:18 < ABHINAVANAND[m]> https://github.com/mlpack/mlpack/pull/2887

06:21 < AakashkaushikGit> Hey Abhinav i don't exactly understand what about this PR ?

06:22 < ABHINAVANAND[m]> What you didn't understand?

06:22 < AakashkaushikGit> you randomly dropped it so i couldn't understand why

06:25 < ABHINAVANAND[m]> The tests of this PR just passed and I told zoq that when the PR is ready I will let him know.

06:25 < ABHINAVANAND[m]> <https://mlpack.slack.com/archives/CQBGGKL9F/p1616608988110000?thread_ts=1616608988.110000&cid=CQBGGKL9F|https://mlpack.slack.com/archives/CQBGGKL9F/p1616608988110000?thread_ts=1616608988.110000&cid=CQBGGKL9F>

06:26 < AakashkaushikGit> Oh okay all right, thanks for taking the time to explain this. :D

08:28 < OleksandrNikolsk> <OleksandrNikolsk "And implement the LM CMA Es - i"> Wow, already running out of memory while optimizing a tiny deep nn with 4 13x13 convolutional filters and 32 hidden units.

13:40 < zoq> OleksandrNikolsk: Might be a good idea to decrease the population size.

13:43 < zoq> AakashkaushikGit: From the build log it looks like you solved the issue?

13:44 < zoq> AakashkaushikGit: Also, I had some trouble with the Highway layer, some matrix out of bounds issue, so I think some error happend during the conversion.

13:45 < rcurtin[m]1> ABHINAV ANAND: I saw that Oleksandr Nikolskyy had also opened a PR for MeanPooling: https://github.com/mlpack/mlpack/pull/2865 ; I haven't looked into either yet but maybe it is worth taking a look to see if you aren't both solving the same issue?

13:46 < ABHINAVANAND[m]> zoq the issues are different.

13:56 < ABHINAVANAND[m]> Hi, While I was going through pooling layers code, I was able to understand them completely. Upon further inspection I think I may have found some ways to significantly improve the speed of pooling and unpooling operation in max and mean pooling layer. The details of them are in the last 4 pages of the attached document. Please take a look at them and maybe they can be worth implementing.

13:57 < zoq> ABHINAVANAND[m]: Thanks, I'll take a look at the document later today.

15:40 < jonpsy[m]> hey zoq , about the proposal, can I directly skip to the work I'm planning to add (with very brief intro about algo) instead of doing a full breakdown with pseudo codes, I can just link the PR (but that might be a little inconsiderate). Let me know if that's cool

15:40 < jonpsy[m]> * hey zoq , about the proposal, can I directly skip to the work I'm planning to add for MOEAD (with very brief intro about algo) instead of doing a full breakdown with pseudo codes, I can just link the PR (but that might be a little inconsiderate). Let me know if that's cool

15:49 < zoq> jonpsy[m]: You can, also a full breakdown is not needed; you can go into more details if you think it adds something to the proposal, like if you identified an important aspect that is worth to point out how this can be intergrated/implemented into mlpack.

15:50 < jonpsy[m]> Cool, i've taken the liberty to add a lot of pseudo codes + sample codes for SPEA-II since we havent started a PR on it + its a pretty complex algo

15:53 < rcurtin[m]1> at least for me, when I read a proposal, the most important question is "how will this fit into the rest of the package?", so I'm generally looking for API, so I can see that (a) a user will be able to use it in all the ways one might want to use it, and (b) the proposed code "matches" other similar classes in the package (whether that's mlpack or ensmallen), so that it will feel familiar to a user who's worked with other

15:53 < rcurtin[m]1> parts of the package

15:53 < rcurtin[m]1> of course, it's useful for the proposer to show that they have a clear and deep knowledge of the algorithm they are planning to implement to; I just wanted to highlight what is, at least for me, the most important part

15:54 < rcurtin[m]1> writing the code is easy... fitting it into the rest of the library so that the entire library is one coherent product is the hard part

15:54 < zoq> Same, also you can expect that a reviewer has some understanding of the things you propose.

15:54 < jonpsy[m]> > at least for me, when I read a proposal, the most important question is "how will this fit into the rest of the package?", so I'm generally looking for API, so I can see that (a) a user will be able to use it in all the ways one might want to use it, and (b) the proposed code "matches" other similar classes in the package (whether that's mlpack or ensmallen), so that it will feel familiar to a user who's worked with other

15:54 < jonpsy[m]> parts of the package

15:54 < jonpsy[m]> this was super useful!

15:54 < zoq> At the end I can always read the paper.

15:55 < jonpsy[m]> how do i prove that it would fit well into the codebase?

15:55 < zoq> E.g. by showing you can reuse code or design patterns.

15:55 < jonpsy[m]> there's already NSGA-II, we could take similar approach.

15:56 < rcurtin[m]1> right, if you are adding an optimizer, I'd basically be looking to see if it fits in one of the types of optimizers we already have (differentiable, separable, etc.); and if it doesn't fit into the existing types and we'd need to add a new one, I'd be looking to see that the new type of optimizer is well thought through

15:56 < jonpsy[m]> > E.g. by showing you can reuse code or design patterns.

15:56 < jonpsy[m]> ah, so as in how the ```Optimize()``` and other mandatory MOO functions fit in this algo and how it interacts

15:57 < zoq> In your case it's easy, since you are building on something that already exsists.

15:57 < rcurtin[m]1> and in the proposal, details can be flexible---if someone proposes returning a `std::tuple<double, double>` and I think it would be better to have the function take two `double&`s, that's something we can work out later---from the perspective of reviewing the proposal, it's a pretty minor detail

15:57 < zoq> Agreed

15:57 < jonpsy[m]> > In your case it's easy, since you are building on something that already exsists.

15:57 < jonpsy[m]> lucky me, I guess

15:58 < jonpsy[m]> but I think these advice will suite very well for the ZDT and DLTZ test suites.

15:59 < rcurtin[m]1> well, do still make sure you think through whether our multiobjective optimizer design is sufficient to handle everything you want to implement 😃 if it's not, we can change it as needed, for sure, but the proposal should definitely point out that these types of changes will be needed

15:59 < rcurtin[m]1> (in your case... I think what we have should work---but you have thought about the optimizer more than I have, so I may be overlooking a detail!)

15:59 < jonpsy[m]> no, youre completely right. SPEA-II will blend right in :)

16:00 < jonpsy[m]> although I was thinking of Policy based design(remember our discussion :)?) but that'd be too overreaching imo, so sticking to old route..

16:02 < rcurtin[m]1> go with whatever you think is right :) we can always change it later if needed---if it's accepted, a proposal can always be changed during the summer as needed

16:02 < rcurtin[m]1> there have been projects where the original idea just plain didn't work out and the student and mentor had to figure out something completely different over the summer :) so a design change or an API change after the proposal stage is perfectly fine

16:03 < jonpsy[m]> i'll do my best!

16:03 < rcurtin[m]1> 👍️

16:03 < jonpsy[m]> thanks, off to dinner. Nice chat

16:04 < rcurtin[m]1> enjoy! see you later

17:04 < OleksandrNikolsk> <zoq "Oleksandr Nikolskyy: Might be a "> Its already coming up by evaluating the first sample, exactly at the first attempt of Cholesky Decomposition.

18:42 < AakashkaushikGit> > `zoq on Freenode` Aakash kaushik (Gitter): From the build log it looks like you solved the issue?

18:42 < AakashkaushikGit> Nope, I am still facing the issue it's in the build log too.

18:43 < AakashkaushikGit> > `zoq on Freenode` Aakash kaushik (Gitter): Also, I had some trouble with the Highway layer, some matrix out of bounds issue, so I think some error happend during the conversion.

18:43 < AakashkaushikGit> Yup, i have seen it, I was thinking to take a look at those after i could get a successful build, taking one things at a time. i probably know there would be failed tests cases in ann_layer_test too but i am thinking to take a look after i can solve all the build issues.

18:43 < AakashkaushikGit> (edited) ... one things at ... => ... one thing at ...

18:44 < AakashkaushikGit> would be great if you can help identify the `GradientUpdate` function not found issue.

19:00 < AakashkaushikGit> I feel so dumb, so i created other utils and while creating them i copied the structure from gradient_update to create gradient_set and forgot to change the include guard.

19:00 < AakashkaushikGit> @zoq that is now solved.

19:00 < AakashkaushikGit> thanks for taking a look too.