08:10 < Atharva> sumedhghaisas: Hey Sumedh

08:17 < Atharva> I have been trying to debug the gradent check for the reconstruction loss since yesterday with no luck. Will you please check the LogProbBackward function once?

08:17 < Atharva> I checked it multiple times and can't find any mistake

08:17 < Atharva> zoq: Do you think there can be any other reasons for gradient check to fail?

08:25 < Atharva> sumedhghaisas: zoq: No worries, it just passed ! :D

10:05 < jenkins-mlpack> Project docker mlpack nightly build build #355: STILL UNSTABLE in 2 hr 51 min: http://masterblaster.mlpack.org/job/docker%20mlpack%20nightly%20build/355/

10:10 < zoq> Atharva: Good, how did you solve the issue?

10:13 < Atharva> Turns out I changed the loss function from NegativeLogLikelihood to ReconstructionLoss but I was still using the LogSoftMax activation. Also, I wasn't applying softmax before using the standard deviation

10:16 < Atharva> zoq: I had a doubt.

10:17 < Atharva> I want to add this gradient check test for the reconstruction loss, should I add it in the layer test file or the loss test file?

10:17 < Atharva> If the loss test, then we would have to define the checkgradient function again.

10:21 < Atharva> softplus*

10:30 < zoq> We could write a new file something like ann_test_tools.hpp which implements the gradient check function and include the file inside the test, but I'm fine with either one.

10:31 < Atharva> Yes, I think the ann_test_tools.hpp is a good option. That way it can be used both in ann_layer_test and loss_function_test

10:52 < manish7294> zoq: Is it necessary to have labels in integer format for mlpack?

10:56 < zoq> manish7294: That depends on the method, some store the labels as arma::row<size_t>

10:57 < zoq> manish7294: You could map the labels before passing them and remap the results afterwards, not sure that is an option.

10:58 < manish7294> zoq: Thanks, I am doing that for now.

11:01 < zoq> manish7294: https://github.com/mlpack/mlpack/blob/3d3d733ba3c41c4f51764f44185767384ab6d9c7/src/mlpack/core/data/normalize_labels.hpp#L33

11:02 < zoq> this function does exactly that

11:05 < manish7294> zoq: Then it seems strange why lmnn is throwing labels related error for the letters and balance dataset, while working on the integer format versions of the same.

11:05 < manish7294> I shall look more into it, as why it's happening

11:06 < zoq> manish7294: For the balance dataset isn't the label a string?

11:06 < manish7294> zoq: It's a char

11:07 < zoq> manish7294: And if you load the dataset it's converted to int?

11:08 < manish7294> zoq: verifying it.

11:12 < manish7294> zoq: somehow after normalize(), all labels are turning to 0.

11:14 < manish7294> Before normalize too rawLabels have all 0 enteries.

11:21 < zoq> are you pasing a seperate labels file or do you use the last column?

11:22 < manish7294> last column

11:22 < zoq> okay, how does data look like?

11:23 < zoq> https://github.com/manish7294/mlpack/blob/8a6709f089b72001bee41f23989205fda694a113/src/mlpack/methods/lmnn/lmnn_main.cpp#L254 already converts the labels so I'm not sure I see the reason for NormalizeLabels

11:24 < manish7294> zoq: initially we have A, B, C, D as labels and finally we are getting 0 , 0 , 0 ....

11:24 < zoq> same in the data matrix before the split?

11:24 < manish7294> zoq: just a sec

11:25 < zoq> manish7294: I guess an easy solution would be to manually convert the dataset.

11:26 < manish7294> zoq: I was thinking of the same, shall I drop a converted version here. Maybe you or Ryan can upload it

11:27 < manish7294> zoq: After just loading that data we are getting 0's as the last column.

11:27 < zoq> manish7294: Sure, I think it would be great to get this one working but for now I guess it makes sense to upload a new dataset.

11:28 < manish7294> zoq: I will be sending a link within some time

11:28 < zoq> okay

11:39 < manish7294> zoq: Here are the links: https://www.pastefile.com/dRgP6x & https://www.pastefile.com/HChhCd

11:47 < zoq> manish7294: okay, uploaded

11:47 < manish7294> zoq: great :)

14:36 < manish7294> rcurtin: I performed some benchmarking and here's the results. Please have a look at them as you get chance https://github.com/mlpack/mlpack/pull/1407#issuecomment-398772089

14:40 < rcurtin> I saw your post, let me finish this other thing first. just at a quick glance it looks great so far (but I need to look closer)

14:40 < manish7294> rcurtin: sure

15:39 < manish7294> rcurtin: I saw your comment, Additionally I would like to say that --- we have quite a number of parameters and I strongly feel that we can get accuracy comparable to shogun's by some tuning.

15:40 < manish7294> And then there's balance dataset on which mlpack performs totally on other level :)

15:44 < manish7294> and I think shogun is using pca for distance initialization process since I have been passing anything to shogunLMNN

15:47 < manish7294> *not been passing

16:11 < manish7294> zoq: rcurtin: matlab doesn't seems to accessible from benchmarks. The error this time is [FATAL] Exception: 'MATLAB_BIN' , Can you help with this?

16:13 < manish7294> zoq: I saw the matlab scripts and looking at the way you implemented them, I think it is possible to take out lmnn implementation out of drtoolbox and include it similar to existing ones.

16:26 < rcurtin> try 'export MATLAB_BIN=/opt/matlab/bin/matlab', I think that will fix it

16:27 < rcurtin> and I agree, I think we can just take lmnn.m and drop it into place

16:27 < rcurtin> I agree with your comments too---I don't think we need to exactly match shogun's accuracy everywhere

16:28 < rcurtin> just get an idea that we perform roughly the same and get an idea that we could tune to match the accuracy

16:50 < manish7294> rcurtin: Thanks! It looks like there is some progress now.

16:51 < manish7294> Ah! finally letter comes to a stop with a timing of 6416.926464s against our's 19.975593 with accuracies almost same :)

18:04 < ShikharJ> rcurtin: Could you review the BatchSupport PR, so that we may merge it?

18:24 < rcurtin> sure, give me a little while and I will do that

19:17 < sumedhghaisas_> Atharva: Hi Atharva, could you fix the third static code check error so that we can merge that PR? :)

19:49 < Atharva> sumedhghaisas_: Yes, I will do it right now.

19:52 < Atharva> Do you mean this one - "Not all members of a class are initialized inside the constructor." ?

19:54 < zoq> Atharva: Yes, that's the one.

19:55 < Atharva> zoq: Okay, so in the constructor I will just initialize them to zero.

19:56 < zoq> Atharva: or you can use the constructor list

19:57 < Atharva> Okay

20:20 < Atharva> sumedhghaisas_: Are you free right now?