12:31 < saksham189Gitter> hi @himanshupathak21061998 are you there?

12:34 < HimanshuPathakGi> Yup hello

12:34 < HimanshuPathakGi> @saksham189

12:35 < saksham189Gitter> hi ;)

12:35 < saksham189Gitter> so I think the work on the RBFN is complete. I have suggested one change. If you make that I would merge it in.

12:36 < HimanshuPathakGi> We will dicsuss today about Kernel-svm

12:36 < HimanshuPathakGi> > so I think the work on the RBFN is complete. I have suggested one change. If you make that I would merge it in.

12:36 < HimanshuPathakGi> Yup:)

12:37 < HimanshuPathakGi> So, I am thinking of naming it RBF as GaussianFunction. What do you think

12:40 < saksham189Gitter> do you know where you would be adding it?

12:40 < HimanshuPathakGi> > do you know where you would be adding it?

12:40 < HimanshuPathakGi> As I discussed as well as @zoq suggested that we should new directory kernel_svm for it

12:41 < saksham189Gitter> yeah that is what I was thinking as well.

12:42 < saksham189Gitter> I think the kernel would be a template parameter since we could let the user specify different kernels with the SVM, right?

12:42 < HimanshuPathakGi> It will be a better thing because if we want to add polynomial kernel function we can do that in kernel_svm

12:43 < saksham189Gitter> also have you shared your blog post for the week?

12:44 < HimanshuPathakGi> > also have you shared your blog post for the week?

12:44 < HimanshuPathakGi> I will share it today :)

12:44 < HimanshuPathakGi> I always get late in this

12:46 < saksham189Gitter> alright great. Is there anything we need to discuss?

12:47 < HimanshuPathakGi> > alright great. Is there anything we need to discuss?

12:47 < HimanshuPathakGi> Done from my side.

12:47 < HimanshuPathakGi> If you want to ask anything??

12:48 < saksham189Gitter> Also we have an implementation of `linear_svm` that could be helpful

12:48 < saksham189Gitter> I think you could try to adapt that and add kernel as a template parameter and then add different kernels like linear, RBF etc.

12:50 < HimanshuPathakGi> > Also we have an implementation of `linear_svm` that could be helpful

12:50 < HimanshuPathakGi> Yes, it is helpful:) I was also thinking of doing this

12:51 < saksham189Gitter> Let me know if you need any help or if there are any blockers we can discuss them here.

12:52 < HimanshuPathakGi> > Let me know if you need any help or if there are any blockers we can discuss them here.

12:52 < HimanshuPathakGi> Yup, if I have got while implementing I will ask for help :)

12:53 < saksham189Gitter> Alright great ! Bye. Hope you have a great day.

12:53 < HimanshuPathakGi> Have a great day bye :)

13:12 < rcurtin> shrit[m]1: sorry for the slow response

13:13 < rcurtin> I think it's ok to leave all the trees in mlpack_knn---after all, the bindings are meant to provide decent functionality to languages other than C++ (including the command line)

13:14 < rcurtin> so if the user wants a very specific and small KNN program that only uses one tree type, then they should use a custom C++ program that will be much smaller

13:14 < rcurtin> let me know what you think :)

13:14 < rcurtin> also, with cereal and CLI11, do you know the "new" smaller size of mlpack_knn? I'm curious how much those changes helped :)

13:28 < shrit[m]1> We have gained 1.3 MB, The final size for mlpack_knn is 3.4

13:28 < shrit[m]1> The issue now is all the traverse functions are called of all the trees, even If the user specified one tree

13:29 < shrit[m]1> That is the reason I tough of a template function that called depending on what the user is calling

13:29 < shrit[m]1> *thought

13:52 < shrit[m]1> rcurtin knn_low_resource is 2.3 MB

14:00 < jeffin143[m]> rcurtin (@freenode_rcurtin:matrix.org): do python binding build is off by default

14:00 < jeffin143[m]> And we have to specify ??? Using cmake flag ?? To build python binding ?

14:07 < shrit[m]1> no I think they are on see here: https://github.com/mlpack/mlpack/blob/5d6f85c1d5344855d4c984ef147d4834752db19b/CMakeLists.txt#L19

14:33 < rcurtin> shrit[m]1: awesome, nice size improvement :)

14:33 < jeffin143[m]> Thanks shrit

14:34 < rcurtin> I don't know any way around having all of the traversals instantiated in the mlpack_knn program though, unless we reduce the number of trees supported (and ideally we should avoid reducing functionality of the bindings)

14:35 < rcurtin> it sounds like maybe we are getting close to the limit of how small we can make mlpack_knn with its current functionality?

14:36 < rcurtin> shrit[m]1: do you have an updated breakdown for the sizes of functions in mlpack_knn now?

15:40 < shrit[m]1> Yes of course, I will send you one by mail

15:40 < shrit[m]1> I am still convinced we can gain up to 500KB without lossing any functionality

16:10 < rcurtin> shrit[m]1: sounds good---maybe let's think tomorrow about ways that we can improve further

16:11 < rcurtin> the templated traversers for each tree type actually do make a difference in terms of runtime; it's important to have each traverser compiled specifically for each tree type

16:11 < rcurtin> however, maybe there are still some tricks we can do to reduce the size of each individual compiled traverser

16:32 < jeffin143[m]> Shouldn't we have generic things to reduce size , I mean here making changes will only reduce knn size and other would still remain of significant size and then we have to reduce them as well by changing code right ?

16:34 < jeffin143[m]> GitHub trying to remove racist words from GitHub , such as master to main , and whitelist to something

16:54 < shrit[m]1> @rcurtin, Perfect, In the meanwhile I will try to understand mlpack_knn in details.

16:56 < rcurtin> jeffin143[m]: yeah, a lot of the changes have been for generic parts of the codebase and would make a difference to everything (like the boost::serialization and boost::program_options changes)

16:57 < jeffin143[m]> rcurtin (@freenode_rcurtin:matrix.org): oh I see :)

18:23 < abernauer[m]> Does anyone in the community have any tips for building a deep learning image data set from scratch?

18:38 < abernauer[m]> Yeah I can just use wget totally blanked.

18:52 < HimanshuPathakGi> Hey, everyone, this is my weekly blog post https://medium.com/@hpathak336/week-2-gsoc2020-b2b8a8f6e745

18:52 < HimanshuPathakGi> :)

19:10 < kartikdutt18[m]> Hey everyone, Here is the [link] (https://medium.com/@kartikduttmd/gsoc-week-3-3rd-june-11-june-4f396c196315?source=friends_link&sk=b9b7cf604f344dd64b7c0f0907982744) for my weekly blog. Kindly let me know what you think.

21:51 < zoq> kartikdutt18[m]: Great update, thanks; I like INZO's - Overthinker, Alan Watts voice matches perfectly.

21:53 < zoq> kartikdutt18[m]: Also, not sure if you have seen -> Responding to the Controversy about YOLOv5 - https://blog.roboflow.ai/yolov4-versus-yolov5/

21:58 < zoq> shrit[m]1: Nice update as well, is the current plan to replace boost serialization with cereal independently of the other steps?

22:15 < shrit[m]1> @zoq In fact, boost serialization have been replaced, I have only raw pointer left

22:16 < shrit[m]1> Since cereal does not serialize raw pointer out of the box, we need to figure out a way to do it properly, otherwise the overall is good I think

22:16 < zoq> shrit[m]1: I think it's part of #2415?

22:17 < rcurtin> I figured maybe it might make sense to cherry-pick some things out of #2415 as we go into their own PRs?

22:18 < zoq> Yes, the PR is already quite large.

22:18 < rcurtin> yeah I can't even load the diff automatically :-D

22:19 < zoq> Sounds like CLI and the serialization part are two seperate things.

22:19 < rcurtin> agreed, it would be nice to split them out

22:22 < shrit[m]1> rcurtin zoq agree, how to do this ?

22:23 < shrit[m]1> I am sure it would be easier to review

22:23 < rcurtin> shrit[m]1: I guess we could just cherry-pick the relevant commits into a different branch, and then review that branch?

22:25 < shrit[m]1> I am looking into cherry-pick never used that before.

22:26 < shrit[m]1> I hope I did not mix modification related to two different things in one commit, I usually do not do that

22:26 < rcurtin> it's ok, even if you did do that, if the commit was small, you could cherry-pick without committing, then modify locally to revert the unwanted changes, then commit

22:27 < rcurtin> alternately, you could even just make a new branch and not use git and copy over all the changes you wanted from the original branch, in the worst case :)

22:35 < shrit[m]1> Perfect, I will create two different pull requests one for cereal and other for CLI11

23:22 < shrit[m]1> rcurtin The idea is good, actually it is extremely easy to use cherry-pick

23:22 < shrit[m]1> in this case we will keep #2415 as a draft, and will extract all features as cherry picks in different pull requests

23:39 < rcurtin> shrit[m]1: that sounds good to me, I guess we can ask in our meeting tomorrow if Roberto has any ideas or comments too :)

23:40 < shrit[m]1> Agreed

23:45 < rcurtin> I am spending the evening setting up some new (old) build slaves for Jenkins... hopefully should have them online tonight, and then when the builds break I can learn which packages I forgot to install :)

23:51 < shrit[m]1> Great, that would requires the addition of cereal I think

23:51 < shrit[m]1> I do not know for CLI11, It will never build in Jenkins if the sources is not in mlpack