02:57 < theeviltwin> hey, any veterans there? newbie here

04:35 < nilay> zoq: can you still run that test once, actually what's happening there is that the test completes and after that it gives a memory error, which is very weird considering there isn't anything to do once the test completes (the last line is printed).

10:34 < zoq> ilay: sure no problem, I'll take a look at it later today.

12:09 < zoq> nilay: Can you post the complete test? I used the test from the gist and it runs without any errors on my machine.

13:40 < rcurtin> mentekid: I'm not sure where lines 82-86 in the program you sent came from... I think that should be from Equation 10 in the Minka paper?

13:41 < mentekid> rcurtin: I was actually correcting precisely that part

13:42 < rcurtin> I came up with this:

13:42 < mentekid> I tried to simplify the equation but probably messed something

13:42 < rcurtin> double nominator = meanLogx - logMeanx + log(aEst) - digamma(aEst);

13:42 < rcurtin> double denominator = pow(aEst, 2) * (1 / aEst - trigamma(aEst));

13:42 < rcurtin> aEst = 1.0 / ((1.0 / aEst) + nominator / denominator);

13:42 < rcurtin> and that seems to converge to a relatively close approximation (I guess we could modify the tolerance if we wanted it closer):

13:42 < rcurtin> $ ./a.out

13:42 < rcurtin> aEst = 7.20323

13:42 < rcurtin> aEst = 7.20331

13:43 < rcurtin> 7.20331(Should be: 7.3)

13:43 < mentekid> yep I get exactly the same thing

13:43 < rcurtin> 4.55148(Should be: 4.5)

13:43 < mentekid> I tried to simplify the fraction

13:43 < mentekid> and probably fumbled along the way

13:43 < rcurtin> yeah, maybe it can be simplified, but I have not thought about how very much

13:43 < rcurtin> I had that happen recently too... the hashing paper I submitted, it turns out, had a big error in the proof

13:43 < mentekid> I'll stick with the Minka formula I think

13:44 < rcurtin> I accidentally expanded (1 - a) * (1 + a) to (1 + a^2)...

13:44 < mentekid> it's not even that significant to optimize the loop, it seems to mostly converge in 3-4 iterations or less even with high tolerance

13:44 < rcurtin> luckily I was still able to preserve the proof result when I fixed it, but still, bah! you check it over again and again and still there's something wrong you didn't see... :)

13:45 < mentekid> yeah, I did it a few times and got different results each time

13:45 < mentekid> I think I'll actually plug it in wolfram|alpha and see if they can do anything smart

13:45 < rcurtin> hm, even when I set the tolerance to 1e-10, I still get 7.20331, not 7.3

13:45 < rcurtin> but I guess it is possible that since there are only 200 samples, it is possible that the generated points actually fit the distribution better with 7.20331

13:46 < mentekid> yeah I was going to say that, a bigger sample might come closer to the real alpha

13:46 < rcurtin> yeah, with 200k points I'm getting 7.28

13:47 < rcurtin> ah, there we go... you have to set the seed for the std::default_random_engine

13:47 < rcurtin> now I get different results each run, after adding

13:47 < rcurtin> generator.seed(time(NULL));

13:51 < mentekid> I was wondering why it was the same result every time

13:51 < mentekid> cool :)

13:54 < rcurtin> when you implement this in the mlpack code, see if you can find some way to only include the boost digamma and trigamma headers inside of the implementation in such a way that it won't be included somewhere else

13:54 < rcurtin> whether or not that is really possible, I am not sure, it depends on whether or not the code is templatized

13:54 < travis-ci> mlpack/mlpack#1228 (master - f21439c : Ryan Curtin): The build is still failing.

13:54 < travis-ci> Change view : https://github.com/mlpack/mlpack/compare/8900b8ca1591...f21439c2b65c

13:54 < travis-ci> Build details : https://travis-ci.org/mlpack/mlpack/builds/145822375

13:55 < rcurtin> if it is, you might be able to use explicit template instantiations

13:55 < rcurtin> (this is in the interest of trying to reduce compile time)

13:55 < mentekid> I'm not sure how to check if it is included only on my class

13:55 < rcurtin> basically, if you include the boost headers in any hpp file, then any mlpack code that includes that hpp file will also include the boost headers

13:55 < mentekid> the code is template-based, the input argument is a template

13:56 < rcurtin> if you instead include it in a cpp file, then it won't be included anywhere else

13:56 < rcurtin> ok; don't spend too much time on it, but I may play around with it once you submit a PR and see if I can figure anything out

13:56 < rcurtin> I am trying to do the same with some other mlpack code, because compile time is pretty long...

13:57 < mentekid> so if I develop my class in an hpp file and include boost at the top, any file including my file will need to recompile digamma/trigamma. I see

13:57 < mentekid> I can implement the class in a cpp file instead, that shouldn't be a problem... I'm not sure how it would be possible for it to be included then

14:00 < rcurtin> yeah, exactly, things that are included in cpp files only will not be included by the rest of mlpack

14:01 < rcurtin> in fact, if we managed to move all of our dependencies on any Boost library into cpp files only, then the Boost headers would only be a build-time dependency and you would not need them once mlpack was built (unless you were using some other Boost functionality)

14:33 < mentekid> might be a stupid question - would what you said be doable this way: define the class in a gamma_dist.hpp, then implement the functions in gamma_dist_impl.cpp where I include the boost functions?

14:34 < mentekid> I'm not sure if that's possible though - can I do #include <gamma_dist_impl.cpp> or somehow link against the implementation of my class?

16:01 < mentekid> rcurtin: So, I ended up doing it like the other distributions, but I'm not sure how to link my code. In mlpack/core/dists/ I created a gamma_distribution.hpp and a gamma_distribution.cpp. I added both to the CMakeLists. They compile fine.

16:03 < mentekid> The problem is when I #include "mlpack/core/dists/gamma_distribution.hpp", the compiler can't find the implementation of the functions (which are in gamma_distribution.cpp along with the boost #include directives)

16:03 < mentekid> (I am compiling with g++ simpleTest.cpp -I include/ -L lib/ -larmadillo -std=c++11)

16:06 < zoq> nilay: There is something wrong with the modified pooling layer.

16:28 < nilay> zoq: could you pinpoint error, or should i look into it?

16:29 < zoq> nilay: It would be great if you could take a look, maybe you see something.

16:34 < zoq> nilay: if I set stride = kSize it works

16:37 < nilay> zoq: ok, but do you not think its strange that after reached here is printed, the error comes?

16:38 < zoq> nilay: yeah, but it's definitely a side effect of the pooling layer

16:39 < nilay> ok, i'll look into it then, thanks.

16:39 < zoq> input(arma::span(i, i + rStep - 1), arma::span(j, j + cStep - 1))

16:39 < zoq> we should use the ksize instead of rStep and cStep

16:41 < zoq> that works for me: https://gist.github.com/zoq/ff2f830ecf248d71e7f8c88e48b59be0

16:45 < zoq> nilay: no more errors on my side

16:50 < nilay> thanks zoq :)

16:51 < zoq> Can you take a look at the modification, not sure If I missed something.

16:53 < nilay> ok