03:33 < sumedhghaisas> rcurtin, zoq: Sorry for the delay. Removing the prevOutput copy in GRU is creating some memory issues in my code. I am sure is something small. I will definitely figure this out tomorrow and finish that task.

03:36 < sumedhghaisas> For the shift to arma::cube... it does more slightly better results. But resize cost is really high compared to that boost....

14:02 < kris1> if i making changes to some file and do make actually compiles the old(cached files only). This is happening on clang. I don’t want to do make clean again and again as this takes a lot of time to make

14:02 < kris1> any ideas only to make the changed files

14:06 < kris1> okay this happens only if i make changes to hpp files not to the cpp files.

14:06 < kris1> cpp files are build again okay i think i got it

14:15 < sgupta> rcurtin: I was trying to add docker pipeline plugin (it is the most popular with ~64k downloads) but it requires restart and some plugin changes. Please have a look.

14:33 < rcurtin> sgupta: hm, unfortunately we definitely can't restart Jenkins until the benchmark jobs for mlpack and shogun are done

14:33 < rcurtin> I expect the mlpack benchmarking job to be done by June 16th (just guessing by last time)

14:34 < rcurtin> that's too long to wait, so why don't you just run the containers like you are for now, and we will add the plugin later?

14:34 < rcurtin> it should be a pretty easy change

14:34 < sgupta> rcurtin: okay. No issues. Meanwhile, let me know what to do next?

14:34 < rcurtin> yes, let me send you an email

14:34 < sgupta> rcurtin: sure thanks :)

14:35 < rcurtin> kris1: unfortunately if you modify a header that is used by a lot of the library, then basically everything will need to be rebuilt

14:35 < rcurtin> if you are trying to save some time, one thing you could do (in your local branch only) is to comment out all the test files that you don't care about in src/mlpack/tests/CMakeLists.txt, then the tests will be a lot quicker to build

14:38 < kris1> Okay thanks :) i will do that

16:22 < sumedhghaisas_> zoq: Hey marcus....

16:22 < sumedhghaisas_> have a quick doubt if you are free?

16:23 < sumedhghaisas_> also I submitted the version which saves copies. Its a very slight boost.

16:23 < sumedhghaisas_> but I suspect it will be better for deeper and bigger outputs

16:50 < cult-> rcurtin: i would have a rather beginner question: kde vs gmm, while using 1dimensional 1 gaussian gmm, the distribution is always cupola like /\, but if i use kde on a data it might be look like /\/\. Why?

16:51 < cult-> to illustrate http://seaborn.pydata.org/_images/distributions_22_0.png, red line is gmm and the others are like kde

17:30 < cult-> so how is it possible that 1d gmm has 1 peak while kde has multiple on the same data?

17:44 < rcurtin> cult-: with a 1D GMM that has one Gaussian, you are essentially just fitting a single Gaussian to the distribution

17:45 < rcurtin> this means the free parameters for fitting are only the mean and covariance of that Gaussian, and it will always have the shape of a gaussian

17:45 < rcurtin> in the case of KDE, KDE doesn't assume any model at all---the density estimate at a given point is only the sum of the kernels of all other points

17:46 < rcurtin> so KDE can take basically arbitrary shapes

17:46 < cult-> ahhhhh

17:46 < cult-> thanks!!!!

17:46 < rcurtin> the bandwidth you use for KDE controls how "smooth" the resulting density will be

17:46 < rcurtin> sure, glad to help :)

17:47 < cult-> so if i take the mean and cov of the distribution i can just draw a distribution that would look like kde with high bandwidth?

17:50 < cult-> ok nvm

17:50 < rcurtin> hm, I'm not sure I understood that question

17:51 < cult-> yes i asked it incorrectly, but i understand it now anyway

17:53 < rcurtin> ah, ok

18:44 < zoq> sumedhghais: Sounds good, and I think you are right the impact might be helpful for deeper networks.

18:46 < zoq> sumedhghais: Also, you can always just ask your questions, I'll answer everything once I get the chance.