16:28 < qwertea> hello everyone :)

16:29 < qwertea> I have a some questions, I'm on mac os x and the Debug logs are never displayed, even if my program is compiled with debugging symbols

16:30 < qwertea> (-g -rdynamic)

16:30 < qwertea> any ideas?

16:31 < qwertea> and second question: how can I debug the mappings of a DatasetInfo object? just display what string maps to what numerical value; I didn't find any function that could help

16:31 < qwertea> thx in advance!

16:58 < zoq> qwertea: Hello there, have you build mlpack with -DDEBUG=ON? You could also do mlpack::Log::Debug.ignoreInput = false; before calling the specific method.

17:02 < zoq> qwertea: I guess, one easy solution would be to serialize the model and take a look at the model file to see the mapping e.g. define the "--output_model_file=model.xml" unless you like to write some C++ code to do that

17:06 < qwertea> zoq: oh I didn't know mlpack had to be built with this DEBUG=ON, I thought only my executable had to have debugging symbols..

17:07 < qwertea> zoq: ok that makes sense, would be the easiest solution haha

17:07 < qwertea> zoq: thanks for your answers!

17:09 < zoq> qwertea: If you build mlpack with DEBUG=OO which isn't recommended since all optimizations are turned off, mlpack::Log::Debug.ignoreInput is already set, but you could manually set the parameter.

17:17 < qwertea> zoq: yep, however I can't set it if mlpack hasn't been built with DEBUG=ON bc Log::Debug is an NullOutStream

17:17 < qwertea> zoq: it doesn't have the attribute ignoreInput

17:23 < zoq> qwertea: You are right, in this case you have to build with DEBUG=ON, which I think is fine if you use it just for debugging?

17:26 < qwertea> zoq: yep that's cool :) thanks!

22:02 < sumedhghaisas_> rcurtin, zoq: Hey Marcus, Ryan... I think we have reached the limit of boost variant size. I am not able to add more layers. Do you have any idea how to solve this?

22:07 < sumedhghaisas_> ahh got it. We have defined the limit prereqs.hpp header

22:07 < sumedhghaisas_> I will increase it to 50 for now...

22:21 < rcurtin> sumedhghaisas_: just out of curiosity, as you add more types to the boost::variant, do you notice any compile-time slowdown? (hopefully not)

22:23 < sumedhghaisas_> rcurtin: I have tried noticing it... But technically there should be some minor slowdown. Cause the mpl sequence will go through more recursion.

22:24 < sumedhghaisas_> but I dont think there is big difference from recursion depth 20 to recursion depth 40

22:24 < sumedhghaisas_> maybe we will notice some slowdown at depth 100 or so

22:26 < sumedhghaisas_> also I have setup a testing framework for layers which handle memory. This testing framework creates fake memory from a linear layer and checks if the gradient w.r.t input and memory are both correct.

22:28 < sumedhghaisas_> But requires me to add extra parameter of 'input' of the layer to the BackwardVisitor ... cause the gradient w.r.t. memory might depend on input as well. Will that be okay? I have inserted a check if Backward function accepts 3 parameters or 4 parameters to check if a layer requires 'input' or not

22:28 < sumedhghaisas_> this way we don't have to change the Backward function of existing layers

22:29 < rcurtin> sumedhghaisas_: I'd prefer not to add an extra parameter for the BackwardVisitor if possible, maybe there is some other way?

22:29 < rcurtin> but unfortunately I am on vacation now so I can't dig too deep today... need to go get some breakfast

22:31 < sumedhghaisas_> even I am thinking about it.... but layers which takes memory also as input might need 'input' as parameter to compute the gradient w.r.t. memory. Other way is to store the inputs while in forward ...

22:31 < sumedhghaisas_> but thats a major drawback... as we are storing the same matrix again in the network

22:31 < sumedhghaisas_> RNN framework already stores all the input .... as they are passed in Gradient call

22:33 < sumedhghaisas_> rcurtin: Ohh and backporting is just copying that function to arma extra headers in mlpack right?

22:40 < rcurtin> sumedhghaisas_: basically yes, and then wrapping it with an #ifdef to make sure it doesn't get backported to incorrect versions

22:41 < rcurtin> so you'll need to find the first version of armadillo that has what you need

22:41 < rcurtin> if you have trouble finding old armadillo versions, send Saurabh an email, he has been collecting them :)

22:44 < sumedhghaisas_> rcurtin: collecting them? haha... nice hobby...

22:44 < sumedhghaisas_> okay I will send him a mail then. So I find the first version that has that function ... so disable our code at that cersion right...?

22:46 < rcurtin> right