mlpack IRC logs, 2018-06-20

Logs for the day 2018-06-20 (starts at 0:00 UTC) are shown below.

June 2018
--- Log opened Wed Jun 20 00:00:11 2018
00:23 -!- yaswagner [4283a544@gateway/web/freenode/ip.] has quit [Quit: Page closed]
03:48 -!- Atharva [sid288001@gateway/web/] has quit [Ping timeout: 260 seconds]
03:48 -!- witness_ [uid10044@gateway/web/] has quit [Ping timeout: 256 seconds]
03:49 -!- gtank [sid147973@gateway/web/] has quit [Ping timeout: 256 seconds]
05:23 -!- gtank_ [sid147973@gateway/web/] has joined #mlpack
05:51 -!- witness_ [uid10044@gateway/web/] has joined #mlpack
05:56 -!- witness_ [uid10044@gateway/web/] has quit [Ping timeout: 240 seconds]
05:57 -!- gtank_ [sid147973@gateway/web/] has quit [Ping timeout: 256 seconds]
06:19 -!- Atharva [sid288001@gateway/web/] has joined #mlpack
06:19 -!- witness_ [uid10044@gateway/web/] has joined #mlpack
06:20 -!- gtank_ [sid147973@gateway/web/] has joined #mlpack
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:
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:51 -!- manish7294 [8ba7a66d@gateway/web/freenode/ip.] has joined #mlpack
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:
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> 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: &
11:47 < zoq> manish7294: okay, uploaded
11:47 < manish7294> zoq: great :)
12:38 -!- manish7294 [8ba7a66d@gateway/web/freenode/ip.] has quit [Ping timeout: 260 seconds]
14:25 -!- ImQ009 [~ImQ009@unaffiliated/imq009] has joined #mlpack
14:26 -!- K4k [elw@unaffiliated/k4k] has quit [Ping timeout: 256 seconds]
14:29 -!- K4k [elw@unaffiliated/k4k] has joined #mlpack
14:35 -!- manish7294 [8ba7a66d@gateway/web/freenode/ip.] has joined #mlpack
14:36 < manish7294> rcurtin: I performed some benchmarking and here's the results. Please have a look at them as you get chance
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:01 -!- manish7294 [8ba7a66d@gateway/web/freenode/ip.] has quit [Ping timeout: 260 seconds]
15:37 -!- manish7294 [8ba7a66d@gateway/web/freenode/ip.] has joined #mlpack
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:08 -!- manish7294 [8ba7a66d@gateway/web/freenode/ip.] has quit [Ping timeout: 260 seconds]
16:09 -!- manish7294 [8ba7a66d@gateway/web/freenode/ip.] has joined #mlpack
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 :)
17:12 -!- manish7294 [8ba7a66d@gateway/web/freenode/ip.] has quit [Ping timeout: 260 seconds]
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:15 -!- sumedhghaisas_ [5c082148@gateway/web/freenode/ip.] has joined #mlpack
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:13 -!- ImQ009 [~ImQ009@unaffiliated/imq009] has quit [Quit: Leaving]
20:20 < Atharva> sumedhghaisas_: Are you free right now?
20:32 -!- sumedhghaisas_ [5c082148@gateway/web/freenode/ip.] has quit [Ping timeout: 260 seconds]
--- Log closed Thu Jun 21 00:00:13 2018