mlpack IRC logs, 2018-05-17

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

May 2018
Sun
Mon
Tue
Wed
Thu
Fri
Sat
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
--- Log opened Thu May 17 00:00:22 2018
00:05 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 260 seconds]
00:06 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
00:10 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 256 seconds]
00:16 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
00:23 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 240 seconds]
00:24 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
00:28 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 264 seconds]
00:29 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
00:29 -!- manish7294 [9d25fc3c@gateway/web/freenode/ip.157.37.252.60] has joined #mlpack
00:30 -!- manish72942 [~yaaic@2405:205:1500:6389:280d:977c:cb63:5012] has joined #mlpack
00:33 < manish7294> rcurtin: If I am correct, then it's a good step for separating the two parts and even Low rank property is remaining intact within first part
00:33 < manish7294> I think there is just a small typo of + sign in second part :)
00:35 < rcurtin> yeah, probably, I was not too exact when I did it, I just wanted to get the idea across
00:35 < manish7294> Right, I understand that
00:36 < manish7294> I assume that last M expression written in red, is not related to new formulation
00:36 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 240 seconds]
00:38 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
00:39 < rcurtin> ah hang on, let me look again
00:40 -!- manish72942 [~yaaic@2405:205:1500:6389:280d:977c:cb63:5012] has quit [Read error: Connection reset by peer]
00:40 -!- manish72942 [~yaaic@2405:205:1500:6389:280d:977c:cb63:5012] has joined #mlpack
00:40 < rcurtin> manish72942: yeah, right, that last line in red and blue is something I forgot to erase
00:40 < rcurtin> the basic idea here is that the slack variables don't need to be part of the optimization; they can be expressed entirely as a penalty term
00:41 < rcurtin> (again, I *think*; I am not 100% sure yet, but I am fairly sure)
00:41 < manish72942> rcturin: so we will be having single positive semidefinite constraint right?
00:41 < rcurtin> to minimize the objective function for _any_ M, we simply take for each slack variable e_ijk = max{ 0, 1 - ((x_i - x_j)^T M (x_i - x_j) - ...) }
00:42 < manish72942> sorry for name typo typing in half sleep :)
00:42 < rcurtin> actually we don't have any constraints at all! if we optimize for L where M = L^T L, then for _any_ L we have that M is positive semidefinite
00:42 < rcurtin> ah, sorry, I hope you are not up too late or something
00:42 < manish72942> ya, that's correct
00:42 < manish72942> no, I just woke up:)
00:42 < rcurtin> ah, ok :) I was thinking it should be the morning there
00:43 < rcurtin> you are... UTC + 8.5 ?
00:43 -!- manish7294 [9d25fc3c@gateway/web/freenode/ip.157.37.252.60] has quit [Ping timeout: 260 seconds]
00:43 < rcurtin> ah sorry UTC+5.5 I think
00:43 < manish72942> +5:30
00:43 < rcurtin> so it's like 6:15am there... I definitely do not wake up that early :)
00:44 < manish72942> I usually don't but today somehow I got up :)
00:44 < rcurtin> :)
00:44 < manish72942> so, I think we got a fair formulation now
00:45 < manish72942> Just need to figure out update step
00:47 < manish72942> I think that can be done by running LRSDP with max iteration of 1
00:48 < manish72942> and changing coordinates matrix according to update from second optimizer
00:49 < manish72942> So, whatever I said is even closer to what you are thinking, then which optimizer will be our second one?
00:52 < manish72942> rcurtin: Going back to sleep, see you soon :)
00:54 < rcurtin> ah, sorry, I stepped out
00:54 < rcurtin> if that reformulation is correct there is no need for an SDP solver at all
00:54 < rcurtin> we can just use SGD or L-BFGS or anything else
00:54 < rcurtin> since there are no constraints, it's just a regular objective to be optimized, not an SDP
00:56 < manish72942> rcurtin:Yeah! right, now it's not an SDP :)
00:59 < manish72942> rcurtin: So, shall I start implementing it.
00:59 < manish72942> rcurtin:If yes, then request you to please leave some starting comments :)
00:59 < manish72942> bye :)
01:10 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 248 seconds]
01:11 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
01:16 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 268 seconds]
01:16 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
01:22 -!- manish72942 [~yaaic@2405:205:1500:6389:280d:977c:cb63:5012] has quit [Ping timeout: 255 seconds]
01:28 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 260 seconds]
01:29 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
01:33 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 255 seconds]
01:34 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
01:48 < rcurtin> manish7294: sorry, I am not always at the computer in the evenings :)
01:49 < rcurtin> I think it would be wise to do a little bit of theory work to make sure that these objectives really are doing the same thing
01:49 < rcurtin> but if we can show that, you could actually implement it pretty quickly (just need an Evaluate() and Gradient(), then plug it into L_BFGS or whatever!)
01:49 < rcurtin> another idea could be empirically implementing that, and seeing if the results it gives are the same as the SDP
01:53 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 264 seconds]
01:55 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
02:00 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 260 seconds]
03:36 -!- govg [~govg@unaffiliated/govg] has joined #mlpack
04:43 -!- manish7294 [9d2598f8@gateway/web/freenode/ip.157.37.152.248] has joined #mlpack
04:47 < manish7294> rcurtin: I think the formulation you developed is similar to what authors have done. Insisted of solving SDP they have optimized the linear equation in M with standard optimizers.
04:48 < manish7294> you can refer to page 33 Appendix A. Solver http://www.cs.cornell.edu/~kilian/papers/jmlr08_lmnn.pdf
04:50 < manish7294> So, I think the proof will not be needed.
04:53 < manish7294> *Instead
05:23 < jenkins-mlpack> Project docker mlpack nightly build build #320: FAILURE in 22 hr: http://masterblaster.mlpack.org/job/docker%20mlpack%20nightly%20build/320/
07:50 < manish7294> rcurtin: I went over the algorithm and it's really a well developed algo with some nice tricks employed. I think we could work over it to exploit more speedups in various computational parts.
08:04 -!- travis-ci [~travis-ci@ec2-54-81-162-236.compute-1.amazonaws.com] has joined #mlpack
08:04 < travis-ci> ShikharJ/mlpack#151 (LayerNorm - 8405801 : Shikhar Jaiswal): The build has errored.
08:04 < travis-ci> Change view : https://github.com/ShikharJ/mlpack/compare/7ad07a8dd82c...840580116bfa
08:04 < travis-ci> Build details : https://travis-ci.org/ShikharJ/mlpack/builds/380065764
08:04 -!- travis-ci [~travis-ci@ec2-54-81-162-236.compute-1.amazonaws.com] has left #mlpack []
08:11 -!- manish7294 [9d2598f8@gateway/web/freenode/ip.157.37.152.248] has quit [Quit: Page closed]
08:20 -!- travis-ci [~travis-ci@ec2-54-211-101-244.compute-1.amazonaws.com] has joined #mlpack
08:20 < travis-ci> ShikharJ/mlpack#152 (LayerNorm - 7155ab1 : Shikhar Jaiswal): The build has errored.
08:20 < travis-ci> Change view : https://github.com/ShikharJ/mlpack/compare/840580116bfa...7155ab148e32
08:20 < travis-ci> Build details : https://travis-ci.org/ShikharJ/mlpack/builds/380079632
08:20 -!- travis-ci [~travis-ci@ec2-54-211-101-244.compute-1.amazonaws.com] has left #mlpack []
08:27 -!- travis-ci [~travis-ci@ec2-54-211-101-244.compute-1.amazonaws.com] has joined #mlpack
08:27 < travis-ci> ShikharJ/mlpack#153 (AtrousConv - aafc3cc : Shikhar Jaiswal): The build has errored.
08:27 < travis-ci> Change view : https://github.com/ShikharJ/mlpack/compare/7b5e4953d458...aafc3cc88e9f
08:27 < travis-ci> Build details : https://travis-ci.org/ShikharJ/mlpack/builds/380080089
08:27 -!- travis-ci [~travis-ci@ec2-54-211-101-244.compute-1.amazonaws.com] has left #mlpack []
08:34 -!- mayank98 [uid267201@gateway/web/irccloud.com/x-bamesyztwebvnzue] has joined #mlpack
08:36 -!- ankit [uid299402@gateway/web/irccloud.com/x-qyrknqdwqgxnzeej] has joined #mlpack
08:36 < ankit> Hello, I want to contribute. How should I start ?
09:51 < jenkins-mlpack> Project docker mlpack nightly build build #321: NOW UNSTABLE in 2 hr 37 min: http://masterblaster.mlpack.org/job/docker%20mlpack%20nightly%20build/321/
10:28 < zoq> ankit: Hello, http://www.mlpack.org/involved.html should be helpful.
10:53 -!- sumedhghaisas2 [~yaaic@148.252.129.21] has joined #mlpack
10:54 -!- sumedhghaisas [~yaaic@host-92-8-33-72.as43234.net] has quit [Ping timeout: 260 seconds]
11:14 -!- sumedhghaisas2 [~yaaic@148.252.129.21] has quit [Read error: Connection reset by peer]
11:14 -!- sumedhghaisas [~yaaic@2a00:79e0:d:fd00:4a3:d217:b63c:d812] has joined #mlpack
11:21 -!- travis-ci [~travis-ci@ec2-54-159-95-249.compute-1.amazonaws.com] has joined #mlpack
11:21 < travis-ci> ShikharJ/mlpack#154 (LayerNorm - e2f49ed : Shikhar Jaiswal): The build has errored.
11:21 < travis-ci> Change view : https://github.com/ShikharJ/mlpack/compare/7155ab148e32...e2f49ede3cd0
11:21 < travis-ci> Build details : https://travis-ci.org/ShikharJ/mlpack/builds/380136941
11:21 -!- travis-ci [~travis-ci@ec2-54-159-95-249.compute-1.amazonaws.com] has left #mlpack []
11:27 < zoq> ShikharJ: Looks like you solved the build issue, once travis confirmed this one, we can merge it.
11:35 < ShikharJ> zoq: Are we talking about the Atrous Convolution PR or the Layer Norm PR?
12:01 -!- travis-ci [~travis-ci@ec2-54-159-95-249.compute-1.amazonaws.com] has joined #mlpack
12:01 < travis-ci> ShikharJ/mlpack#155 (AtrousConv - 5b215ec : Shikhar Jaiswal): The build has errored.
12:01 < travis-ci> Change view : https://github.com/ShikharJ/mlpack/compare/aafc3cc88e9f...5b215ec8b82a
12:01 < travis-ci> Build details : https://travis-ci.org/ShikharJ/mlpack/builds/380137345
12:01 -!- travis-ci [~travis-ci@ec2-54-159-95-249.compute-1.amazonaws.com] has left #mlpack []
12:18 < ShikharJ> zoq: I'd prefer if the Atrous Convolution PR is merged first, as it is of higher priority now. It will lead to a merge issue in LayerNorm PR (as they both edit ann_layer_test.cpp file).
12:38 -!- travis-ci [~travis-ci@ec2-54-81-162-236.compute-1.amazonaws.com] has joined #mlpack
12:38 < travis-ci> mlpack/mlpack#4915 (master - a37c9ca : Marcus Edel): The build has errored.
12:38 < travis-ci> Change view : https://github.com/mlpack/mlpack/compare/d44d4cdfcea6...a37c9ca45499
12:38 < travis-ci> Build details : https://travis-ci.org/mlpack/mlpack/builds/380155283
12:38 -!- travis-ci [~travis-ci@ec2-54-81-162-236.compute-1.amazonaws.com] has left #mlpack []
13:34 -!- mayank98 [uid267201@gateway/web/irccloud.com/x-bamesyztwebvnzue] has quit [Quit: Connection closed for inactivity]
13:46 < rcurtin> manish7294: right, thanks for finding that
13:47 < rcurtin> the only additional trick would be the decomposition of M into L^T L, and then optimize over L; I think this may break the convexity of the algorithm but I would need to think about it
13:47 < rcurtin> in any case, I think it would be fine to start with the solver given in that paper
13:48 < rcurtin> if that's how you'd like to proceed, you should take a look at the existing optimizers like L_BFGS or SGD or others and see how you can use those in your implementation
13:48 < rcurtin> ideally you wouldn't want to implement the gradient step yourself, you would want to make it as generic as possible so that we could plug in different optimizers
14:08 -!- manish7294 [9d25fc3c@gateway/web/freenode/ip.157.37.252.60] has joined #mlpack
14:09 < manish7294> rcurtin: Thanks for reviewing it and working through this idea.
14:10 < manish7294> I think now we have good enough idea to work upon and should follow it now :)
14:11 < manish7294> Yeah you are absolutely right, we do want to have a generic implementation than a one dependent on a single optimizer.
14:12 < manish7294> Let's try to make best out of it :)
14:17 < manish7294> And regarding the M decomposition part, I think it is similar to page 34 A.2 Projection
14:18 < manish7294> The posiive semidefinite constraint is being handled by projection
14:18 < manish7294> *positive
14:21 -!- govg [~govg@unaffiliated/govg] has quit [Ping timeout: 240 seconds]
14:25 -!- sumedhghaisas [~yaaic@2a00:79e0:d:fd00:4a3:d217:b63c:d812] has quit [Read error: Connection reset by peer]
14:25 < rcurtin> there are definitely similarities, but the projection step would be a different approach than optimizing L directly
14:26 -!- sumedhghaisas [~yaaic@148.252.128.253] has joined #mlpack
14:26 -!- ImQ009 [~ImQ009@unaffiliated/imq009] has joined #mlpack
14:29 -!- sumedhghaisas [~yaaic@148.252.128.253] has quit [Read error: Connection reset by peer]
14:29 -!- sumedhghaisas [~yaaic@2a00:79e0:d:fd00:4a3:d217:b63c:d812] has joined #mlpack
14:33 < manish7294> rcurtin: Right! projection includes diagonalization process, which can be avoided while optimizing L directly.
14:45 -!- manish7294 [9d25fc3c@gateway/web/freenode/ip.157.37.252.60] has quit [Quit: Page closed]
15:23 -!- sumedhghaisas [~yaaic@2a00:79e0:d:fd00:4a3:d217:b63c:d812] has quit [Ping timeout: 256 seconds]
15:25 -!- sumedhghaisas [~yaaic@148.252.129.24] has joined #mlpack
15:26 -!- sumedhghaisas [~yaaic@148.252.129.24] has quit [Read error: Connection reset by peer]
15:27 -!- sumedhghaisas2 [~yaaic@148.252.129.24] has joined #mlpack
15:27 -!- sumedhghaisas2 [~yaaic@148.252.129.24] has quit [Read error: Connection reset by peer]
15:28 -!- sumedhghaisas2 [~yaaic@2a00:79e0:d:fd00:4a3:d217:b63c:d812] has joined #mlpack
15:31 -!- sumedhghaisas [~yaaic@148.252.129.24] has joined #mlpack
15:31 -!- sumedhghaisas [~yaaic@148.252.129.24] has quit [Read error: Connection reset by peer]
15:31 -!- sumedhghaisas [~yaaic@2a00:79e0:d:fd00:4a3:d217:b63c:d812] has joined #mlpack
15:33 -!- sumedhghaisas2 [~yaaic@2a00:79e0:d:fd00:4a3:d217:b63c:d812] has quit [Ping timeout: 265 seconds]
16:07 -!- sumedhghaisas2 [~yaaic@148.252.128.232] has joined #mlpack
16:08 -!- sumedhghaisas2 [~yaaic@148.252.128.232] has quit [Read error: Connection reset by peer]
16:08 -!- sumedhghaisas2 [~yaaic@2a00:79e0:d:fd00:4a3:d217:b63c:d812] has joined #mlpack
16:10 -!- sumedhghaisas [~yaaic@2a00:79e0:d:fd00:4a3:d217:b63c:d812] has quit [Ping timeout: 256 seconds]
16:13 -!- sumedhghaisas [~yaaic@2a00:79e0:d:fd00:4a3:d217:b63c:d812] has joined #mlpack
16:15 -!- sumedhghaisas2 [~yaaic@2a00:79e0:d:fd00:4a3:d217:b63c:d812] has quit [Ping timeout: 256 seconds]
17:03 -!- mayank98 [uid267201@gateway/web/irccloud.com/x-fcgqcrazoxmihchq] has joined #mlpack
17:14 -!- haritha1313 [0e8bf0fb@gateway/web/freenode/ip.14.139.240.251] has joined #mlpack
17:16 < haritha1313> zoq: I am writing tests for cf in compliance with the new design. Right now there are 6 decomposition policies. Should each function be tested for all decomposition policies or a few unique samples would be enough?
17:40 -!- sumedhghaisas2 [~yaaic@148.252.128.236] has joined #mlpack
17:42 -!- sumedhghaisas [~yaaic@2a00:79e0:d:fd00:4a3:d217:b63c:d812] has quit [Ping timeout: 256 seconds]
18:03 -!- haritha1313 [0e8bf0fb@gateway/web/freenode/ip.14.139.240.251] has quit [Ping timeout: 260 seconds]
18:10 -!- sumedhghaisas2 [~yaaic@148.252.128.236] has quit [Read error: Connection reset by peer]
18:10 -!- sumedhghaisas [~yaaic@host-92-8-33-72.as43234.net] has joined #mlpack
20:15 -!- witness_ [uid10044@gateway/web/irccloud.com/x-klzciujhkqqtbduu] has joined #mlpack
20:37 -!- ImQ009 [~ImQ009@unaffiliated/imq009] has quit [Quit: Leaving]
21:12 -!- mayank98 [uid267201@gateway/web/irccloud.com/x-fcgqcrazoxmihchq] has quit [Quit: Connection closed for inactivity]
22:25 -!- witness_ [uid10044@gateway/web/irccloud.com/x-klzciujhkqqtbduu] has quit [Quit: Connection closed for inactivity]
--- Log closed Fri May 18 00:00:24 2018