mlpack IRC logs, 2018-05-16

Logs for the day 2018-05-16 (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 Wed May 16 00:00:21 2018
00:49 < rcurtin> zoq: thanks, hopefully that will fix some issues
00:49 < rcurtin> I will start the monthly build just to see :)
00:50 < rcurtin> I see it's only 35C in Tucson where masterblaster is, so hopefully we can help make it a little warmer
01:45 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 276 seconds]
01:45 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
02:35 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 248 seconds]
02:36 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
03:51 < rcurtin> manish7294: unfortunately I wasn't able to look into the LMNN issue at all today; I hope to have some more time tomorrow. sorry about that
03:52 < rcurtin> my only thought is, maybe it's worth seeing if you can find a different implementation of LMNN or some SDP with slack variables that need to be updated in order to give you some ideas
03:53 < rcurtin> alternately, there is also the idea of implementing a "wrapper" matrix class that just holds an arma::mat for the M matrix and then an arma::vec for the slack variables
03:53 < rcurtin> but that gives a problem for LRSDP, which is that the diagonal part of the matrix means that the overall matrix being solved is going to be high-rank, thus violating the idea of LRSDP (low-rank)
03:54 < rcurtin> so it's probably better if we figure out a way to handle the slack variables separately
03:54 < rcurtin> I will read more tomorrow
06:07 < zoq> Forgot to install cppcheck ...
06:11 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 260 seconds]
06:13 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
06:17 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 256 seconds]
06:25 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
06:29 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 255 seconds]
06:30 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
06:34 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 255 seconds]
06:36 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
06:45 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 255 seconds]
06:52 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
06:59 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 256 seconds]
07:06 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
07:13 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 255 seconds]
07:14 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
11:03 -!- sumedhghaisas [~yaaic@148.252.128.222] has joined #mlpack
11:06 -!- sumedhghaisas2 [~yaaic@host-92-8-33-72.as43234.net] has quit [Ping timeout: 265 seconds]
11:15 -!- wenhao [731bc783@gateway/web/freenode/ip.115.27.199.131] has joined #mlpack
11:19 -!- sumedhghaisas [~yaaic@148.252.128.222] has quit [Read error: Connection reset by peer]
11:19 -!- sumedhghaisas [~yaaic@2a00:79e0:d:fd00:4a3:d217:b63c:d812] has joined #mlpack
11:43 -!- wiking [~wiking@huwico/staff/wiking] has quit [Read error: Connection reset by peer]
11:43 -!- wiking [~wiking@huwico/staff/wiking] has joined #mlpack
11:55 < wiking> rcurtin, around?
11:57 < rcurtin> just woke up... give me 20-30 minutes and I'll be back
12:20 < wiking> kk
12:20 < wiking> nothing urgent :)
12:33 < rcurtin> ok, back. what's up?
12:40 -!- sourabhvarshney1 [8ba726c4@gateway/web/freenode/ip.139.167.38.196] has joined #mlpack
12:40 -!- manish7294 [9d259e3a@gateway/web/freenode/ip.157.37.158.58] has joined #mlpack
12:41 < sourabhvarshney1> zoq: I have started with the BRNN work. I was busy with some travelling and home stuff. Will open a PR by tomorrow : )
12:42 < manish7294> rcurtin: In the meantime, while wiking is not here, shall I disturb you?
12:42 < rcurtin> manish7294: I left some messages last night, did you take a look at them? I haven't done anything since then except sleep...
12:42 < manish7294> rcurtin: Yup! I went over them
12:44 < manish7294> rcurtin: According to my findings there is only a single way to add slack constraints which is block diagonalization (what we are currently doing)
12:44 < manish7294> sadly, I didn't find any method to reduce the complexity
12:46 < manish7294> As far other LMNN implementation, I think I have scanned majority of them over last months and they all implement the same algorithm which author proposed :(
12:46 < rcurtin> the block diagonalization strategy is almost certainly incompatible with the fundamental assumptions of LRSDP, therefore, it seems we will need to develop some kind of iterative algorithm
12:46 < manish7294> The slack part in itself is a LP problem
12:47 < manish7294> I am wondering, can something like combining to optimizers be done. It may sound stupid though!
12:47 < manish7294> *two
12:48 < rcurtin> no, I don't think that sounds stupid, I think that is the approach we'll have to take
12:49 < rcurtin> what I have in mind right now would be something where you (1) take an SDP step (2) update the slack variables (3) return to step 1 until convergence
12:49 < rcurtin> or something to this effect
12:49 < rcurtin> really the slack variables are used as a penalty because it's not possible to fully satisfy all the constraints
12:49 < zoq> sourabhvarshney1: Sounds great, hope you had fun.
12:49 < manish7294> That sounds cool :)
12:50 < manish7294> rcurtin: But then SDP we will have to generate a extra constraint for SDP
12:51 < sourabhvarshney1> zoq: Yup I loved the work. I am trying to do some more work before opening the PR : )
12:51 < manish7294> rcurtin: That constraint should determine the dependece of two part.
12:52 < rcurtin> manish7294: I'm not fully sure what you mean. in any case, I do think the optimization can be either expressed like I suggested above, or it may be possible to replace the slack variables entirely with a penalty to the objective
12:53 < rcurtin> I will need to consider each idea carefully, but it will take some time before I am able to do that fully, so you should also spend some time looking into the issue---don't just wait on my input :)
12:54 < manish7294> rcurtin: That's right! I myself was not clear while writing that message, but as for SDP what will be the constraints then
12:55 < manish7294> rcurtin: Don't worry, I am continously looking for this from past 3 months :)
12:56 < rcurtin> I need to think about it, but to me, the constraints seem a little odd. each of the slack variables must be set (for each i-j-l tuple) such that the constraint is satisfied
12:58 < rcurtin> so, I wonder, can the slack variables be removed from the constraints and be replaced with something similar to the LHS of the slack variable constraint in the objective?
12:58 < rcurtin> but like I said, it needs some amount of thought, and I need to review the existing LMNN MATLAB implementation to understand it better
13:00 < manish7294> rcurtin: Originally, slacks variables weren' t there. They are just an alias for constraint generation.
13:09 -!- sourabhvarshney1 [8ba726c4@gateway/web/freenode/ip.139.167.38.196] has quit []
13:19 -!- manish7294 [9d259e3a@gateway/web/freenode/ip.157.37.158.58] has quit [Quit: Page closed]
13:31 -!- sumedhghaisas [~yaaic@2a00:79e0:d:fd00:4a3:d217:b63c:d812] has quit [Read error: Connection reset by peer]
13:31 -!- sumedhghaisas [~yaaic@2a00:79e0:d:fd00:4a3:d217:b63c:d812] has joined #mlpack
13:38 < rcurtin> manish7294: I know what my strategy for approaching the problem is; maybe if I write that down it will be helpful to you
13:39 < rcurtin> first, I want to derive what a single update step for the augmented matrix [M 0; 0 s] (where 's' is the diagonal matrix of slack variables) looks like
13:40 < rcurtin> my intuition is that the updates to each element of 's' will basically be whatever update is needed to satisfy the constraint (or some otherwise simple gradient step)
13:41 < rcurtin> or, more specifically, that the gradient for each element of 's' will turn out to be something that is basically the same as just the gradient of that penalty term for the objective
13:42 < rcurtin> if that is true, then the slack constraints are quite literally just a way to stuff the "margin" idea into an SDP, and if the penalty were just placed in the objective alone and optimized that way, there would be no actual need for the slack constraints
13:42 -!- manish7294 [9d259e3a@gateway/web/freenode/ip.157.37.158.58] has joined #mlpack
13:42 < rcurtin> if the slack constraints can indeed be seen as superfluous, then the only remaining constraint is the positive semidefiniteness of the matrix
13:43 < rcurtin> and if we then solve for L where M = L^T L (so, L may be low rank, but it is not required to be positive semidefinite), then we actually have an unconstrained optimization that is not an SDP!
13:44 < rcurtin> that's a big long chain of dependencies to investigate, but if those things are all true (or, if something similar enough to LMNN can be expressed in that way), we can use mlpack's off-the-shelf solvers like L_BFGS and SGD variants
13:44 < rcurtin> anyway, I hope the thoughts are helpful. I haven't dug into the reality of any of those conjectures yet though
13:44 < manish7294> rcurtin: I think all of that make good sense.
13:45 < rcurtin> the starting place would be deriving what a single-step update to the augmented matrix [M 0; 0 s] is
13:45 < manish7294> rcurtin: As for s gradient step, the original LMNN implementation re-calculates impostors after every step.
13:45 < manish7294> It thought it would be helpful to mention that.
13:46 < manish7294> And one more important point is that target neighbors remain fixed. So only impostors are recalculated
13:47 < rcurtin> this makes sense. it may be possible to add some optimizations to reduce the runtime needed for that kNN step to calculate the new impostors
13:47 < rcurtin> but I think that is something we can deal with later :)
13:48 < manish7294> Ya, that can be added at back of priority list, hahaha :)
13:48 < rcurtin> also, in the absolute worst case, where we can't think of anything clever to do here, I think the right thing to do is implement a fast C++ version of the LMNN solver and then use this to implement BoostMetric (without LRSDP or other optimizations)
13:49 < rcurtin> but... I spent a little while thinking about it, and I think it is possible to get some really nice speedup by re-expressing the LMNN optimization to remove the slack variables or some other trick
13:55 -!- manish7294 [9d259e3a@gateway/web/freenode/ip.157.37.158.58] has quit [Ping timeout: 260 seconds]
13:55 -!- manish7294_ [9d25f88b@gateway/web/freenode/ip.157.37.248.139] has joined #mlpack
13:55 < manish7294_> rcurtin: I think we won't be able to use LMNN solver to solve BoostMetric , as they have redfinied the LMNN gradient step to exponential one
13:56 -!- manish7294_ [9d25f88b@gateway/web/freenode/ip.157.37.248.139] has quit [Client Quit]
13:56 < rcurtin> manish7294_: fair, sorry for the error on my part
13:56 -!- manish7294 [9d25f88b@gateway/web/freenode/ip.157.37.248.139] has joined #mlpack
13:57 < manish7294> rcurtin: But if we can bring speed ups to LMNN solver, I think that would be good enough.
13:59 -!- manish7294_ [9d25a316@gateway/web/freenode/ip.157.37.163.22] has joined #mlpack
14:02 -!- manish7294 [9d25f88b@gateway/web/freenode/ip.157.37.248.139] has quit [Ping timeout: 260 seconds]
14:02 < rcurtin> manish7294: agreed
14:04 -!- manish7294_ [9d25a316@gateway/web/freenode/ip.157.37.163.22] has quit [Ping timeout: 260 seconds]
14:06 -!- ImQ009 [~ImQ009@unaffiliated/imq009] has joined #mlpack
14:07 -!- manish7294 [~yaaic@2405:205:1500:6389:280d:977c:cb63:5012] has joined #mlpack
14:17 < wiking> rcurtin, oh sorry haven't seen your ping
14:17 < wiking> i was wondering if you know some details about boost serialization fw regarding templates
14:28 < rcurtin> I know boost serialization fairly well, how can I help?
14:30 < wiking> do you need to do type registration for supporting templated classes?
14:30 < wiking> say i have something like template<typename T> class A {... }; where T is not a primitive type
14:30 < wiking> and i wanna be able to serialize A
14:30 < wiking> as well as deserialize
14:33 < rcurtin> when we do this, we just make sure that T is serializable and there are no problems there
14:36 < wiking> mmm
14:53 -!- manish7294_ [9d25da66@gateway/web/freenode/ip.157.37.218.102] has joined #mlpack
14:57 < manish7294_> zoq: rcurtin: There is still python-cython written instead of cython in mlpack 3.0.0 debian dependencies. I thought it would be good to point it out.
14:57 < manish7294_> http://mlpack.org/docs/mlpack-3.0.0/doxygen/build.html
14:59 < zoq> manish7294_: The issue is fixed in mlpack-3.0.1: http://mlpack.org/docs/mlpack-3.0.1/doxygen/build.html
15:02 < manish7294_> zoq: Maybe updating 3.0.0 page too will be good, as it exists :)
15:05 -!- govg [~govg@unaffiliated/govg] has quit [Ping timeout: 264 seconds]
15:08 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 248 seconds]
15:08 < rcurtin> manish7294_: users should look at the newest documentation, so I don't really want to hand-patch old documentation
15:12 < manish7294_> rcurtin: It's fine, as 3.0.1 is out. Mentioned that because few days back when 3.0.1 was not there, I faced the problem.
15:12 < manish7294_> Was configuring a system so took a look at that issue and though to point it.
15:12 < manish7294_> *thought
15:13 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
15:19 < rcurtin> right, I remember updating it when you pointed it out, thank you for doing that :)
15:19 < rcurtin> if you find anything else wrong in the future definitely point it out also
15:19 -!- travis-ci [~travis-ci@ec2-54-211-49-26.compute-1.amazonaws.com] has joined #mlpack
15:19 < travis-ci> ShikharJ/mlpack#149 (GAN - 60addf3 : Shikhar Jaiswal): The build has errored.
15:19 < travis-ci> Change view : https://github.com/ShikharJ/mlpack/compare/110ebf413944...60addf395b00
15:19 < travis-ci> Build details : https://travis-ci.org/ShikharJ/mlpack/builds/379747257
15:19 -!- travis-ci [~travis-ci@ec2-54-211-49-26.compute-1.amazonaws.com] has left #mlpack []
15:21 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 276 seconds]
15:21 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
15:26 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 248 seconds]
15:29 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
15:32 -!- manish7294 [~yaaic@2405:205:1500:6389:280d:977c:cb63:5012] has quit [Read error: No route to host]
15:33 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 255 seconds]
15:34 -!- manish7294 [~yaaic@2405:205:1500:6389:280d:977c:cb63:5012] has joined #mlpack
15:35 -!- manish7294_ [9d25da66@gateway/web/freenode/ip.157.37.218.102] has quit [Ping timeout: 260 seconds]
15:38 -!- manish7294 [~yaaic@2405:205:1500:6389:280d:977c:cb63:5012] has quit [Ping timeout: 255 seconds]
15:39 -!- manish7294 [~yaaic@2409:4052:617:397:280d:977c:cb63:5012] has joined #mlpack
15:40 < rcurtin> manish7294: I spent some more time thinking about it and reviewing the details of your proposal, and I want to be careful not to force you to change your idea too much if you don't want to
15:40 < rcurtin> so, while I think that it's possible to reformulate the LMNN optimization (and similarly the BoostMetric optimization) to remove the need for the "augmented" matrix [L 0; 0 \epsilon] (in the terminology of your proposal)
15:41 < rcurtin> I also think it's possible that the idea given in your proposal could also work, but the efficiency of the implementation would hinge on making some "wrapper class" that can efficiently hold [L 0; 0 \epsilon]
15:42 < rcurtin> which do you think would be better to pursue? if you'd prefer to stick with your approach, I won't sit down and try to do derivations on the LMNN objective function :)
15:46 < manish7294> rcurtin: Hosnestly, I had my doubts related to LMNN SDP approach scalability from the starting.
15:46 < manish7294> rcurtin: I would prefer a approach that can do the job in best way.
15:47 < manish7294> rcurtin: And is best for the end user.
15:48 < rcurtin> manish7294: I think, for the end user, the API will look the same so that's no issue
15:48 < manish7294> rcurtin: If we could even improvise existing algorithm to gain speedup that would be better too from my point of view.
15:49 < manish7294> rcturin: you got the point but I reffered to benchmarks :)
15:49 < rcurtin> true :)
15:49 < manish7294> and memory too
15:50 < rcurtin> for the scalability, I think it could be okay with your approach, but it will definitely need a custom matrix class so that the operation trace(C*R*R^T) is efficient
15:50 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
15:50 < rcurtin> (I think that's not the exact operation... but it's something like that, I don't remember off the top of my head right now)
15:51 < rcurtin> the custom matrix class would be... semi-simple, but a decent amount of code
15:52 < manish7294> ya but storing a large number of matrices in SparseA and with all of them having a huge size will definitely lead to problems at some point of time
15:53 < manish7294> as a result we can see primal dual giving bad_alloc() on small dataset too
15:54 < manish7294> while the same works for LRSDP
15:57 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 255 seconds]
15:58 < manish7294> rcurtin: So shall we think more about two optimizers approach?
15:59 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
16:00 -!- travis-ci [~travis-ci@ec2-54-81-74-116.compute-1.amazonaws.com] has joined #mlpack
16:00 < travis-ci> mlpack/mlpack#4908 (master - a30f5f8 : Ryan Curtin): The build has errored.
16:00 < travis-ci> Change view : https://github.com/mlpack/mlpack/compare/d77f04097759...a30f5f8c119e
16:00 < travis-ci> Build details : https://travis-ci.org/mlpack/mlpack/builds/379750115
16:00 -!- travis-ci [~travis-ci@ec2-54-81-74-116.compute-1.amazonaws.com] has left #mlpack []
16:03 < rcurtin> manish7294: sure, I will try to set aside some time tomorrow
16:04 < manish7294> rcurtin: Great! I will try out some more things from my side too :)
16:06 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 264 seconds]
16:07 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
16:12 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 240 seconds]
16:13 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
16:30 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 276 seconds]
16:31 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
16:37 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 240 seconds]
16:39 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
16:43 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 248 seconds]
16:44 -!- wenhao [731bc783@gateway/web/freenode/ip.115.27.199.131] has quit [Ping timeout: 260 seconds]
16:48 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
16:50 -!- travis-ci [~travis-ci@ec2-54-211-49-26.compute-1.amazonaws.com] has joined #mlpack
16:50 < travis-ci> ShikharJ/mlpack#150 (AtrousConv - 7b5e495 : Shikhar Jaiswal): The build has errored.
16:50 < travis-ci> Change view : https://github.com/ShikharJ/mlpack/compare/1d0ce3ffb29a...7b5e4953d458
16:50 < travis-ci> Build details : https://travis-ci.org/ShikharJ/mlpack/builds/379790416
16:50 -!- travis-ci [~travis-ci@ec2-54-211-49-26.compute-1.amazonaws.com] has left #mlpack []
16:53 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 240 seconds]
16:57 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
16:59 -!- KevinAvignon [1825eaf2@gateway/web/freenode/ip.24.37.234.242] has joined #mlpack
16:59 < KevinAvignon> hi everyone
17:00 < KevinAvignon> how's the gsoc going so far?
17:02 < rcurtin> KevinAvignon: hi there, I would say it is going pretty well so far :)
17:02 < rcurtin> the channel is pretty active these days
17:03 < zoq> Agreed, a bunch of really neat improvements, additions and discussions so far.
17:03 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 255 seconds]
17:06 < KevinAvignon> @rcurtin: I was wondering, while I'm mentoring Yasmine, when I make progress on the C# automatic bindings, should I include progress reports on the development blog?
17:07 < KevinAvignon> rcurtin: I was wondering, while I'm mentoring Yasmine, when I make progress on the C# automatic bindings, should I include progress reports on the development blog?
17:07 < rcurtin> if you'd like to make blog posts too, definitely feel free! there is no restriction on who can write to the blog
17:07 < rcurtin> although, actually, I need to get your github account so I can get your permissions set right for that repo
17:07 < rcurtin> username Kavignon?
17:10 < KevinAvignon> Yes my handle is indeed Kavignon! That's good! I wanted readers to have the perspective on the automatic binding from a student and from a mentor and see it from two different tech stacks to have a sound idea of how big a project it can be.
17:11 < rcurtin> yeah, that would be great---let me get the permissions set up now
17:11 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
17:12 < rcurtin> ok, set it up, but I think you'll need to click a link in an email to confirm :)
17:14 < KevinAvignon> I've accepted your invitation! As for the repo's permission, all you'd need would be to be a collaborator of my project or do you need something specfic?
17:15 < rcurtin> yeah, you should be able to push to the blog repo now; I don't think that I would need to be a collaborator of a project of yours (maybe I misunderstood the question?)
17:16 < KevinAvignon> I've misunderstood what you said. When you first mentioned permissions, I thought you were speaking of my binding repo* It's my fault
17:16 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 264 seconds]
17:16 < rcurtin> ah, nah, sorry, I just meant permissions for the mlpack/blog repo, in case you wanted to push your blog writings to there so it gets displayed on mlpack.org/blog/
17:21 < KevinAvignon> All right! Oh so you'll know, I think, for at least now, I'll meet with Yasmine for at least 2h a week. We'll work side by side so if she has any questions, I can answer them quickly.
17:22 < rcurtin> sounds great, it is really nice that you are in the same place :)
17:22 < rcurtin> I will be in Montreal in December for NIPS, so if you like, we can meet up
17:22 < rcurtin> (maybe some other mlpack-ers will be there also?)
17:24 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
17:29 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 260 seconds]
17:29 -!- vpal [~vivek@unaffiliated/vivekp] has joined #mlpack
17:30 -!- KevinAvignon [1825eaf2@gateway/web/freenode/ip.24.37.234.242] has quit [Quit: Page closed]
17:33 -!- vpal [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 240 seconds]
17:40 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
17:54 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 240 seconds]
17:56 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
18:02 -!- haritha1313 [2ff7fe8d@gateway/web/freenode/ip.47.247.254.141] has joined #mlpack
18:05 < haritha1313> zoq: The complete structure of CF class is now done after refactoring based on decompositionpolicy. I was intending to make a PR today, but unfortunately I'm stuck up with some errors in the new policy classes when building..
18:08 < haritha1313> So I guess I can start NCF only tomorrow.
18:11 < zoq> Okay, no worries, I'll take a look at the PR once it#s open; I can also help with the build issue, if you need any help with that.
18:13 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 268 seconds]
18:16 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
18:16 < haritha1313> zoq: It looks solvable to me as of now - some header inclusion troubles, just that the error log is too long to comprehend easily :D . I'll let you know if there's any trouble, thanks :).
18:19 < zoq> haritha1313: Right, using template doesn't beautify the output :)
18:23 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 240 seconds]
18:24 -!- sumedhghaisas2 [~yaaic@148.252.129.10] has joined #mlpack
18:24 -!- sumedhghaisas [~yaaic@2a00:79e0:d:fd00:4a3:d217:b63c:d812] has quit [Ping timeout: 256 seconds]
18:25 -!- sumedhghaisas2 [~yaaic@148.252.129.10] has quit [Read error: Connection reset by peer]
18:25 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
18:26 -!- sumedhghaisas [~yaaic@2a00:79e0:d:fd00:4a3:d217:b63c:d812] has joined #mlpack
18:30 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 256 seconds]
18:32 -!- haritha1313 [2ff7fe8d@gateway/web/freenode/ip.47.247.254.141] has quit [Ping timeout: 260 seconds]
18:35 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
18:43 < rcurtin> manish7294: I spent a few minutes talking with a colleague about the LMNN reformulation today. we ended up writing on a whiteboard, and I think that the proposition in this image I took is correct:
18:43 < rcurtin> http://www.ratml.org/misc_img/lmnn_reformulation.jpg
18:44 < rcurtin> (the original formulation in red, my reformulation in brown)
18:44 < rcurtin> next I will need to show more explicitly that that is the case
18:44 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 264 seconds]
18:45 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
18:49 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 240 seconds]
18:50 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
18:55 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 256 seconds]
19:03 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
19:09 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 240 seconds]
19:19 -!- manish7294 [~yaaic@2409:4052:617:397:280d:977c:cb63:5012] has quit [Ping timeout: 256 seconds]
19:23 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
19:23 -!- travis-ci [~travis-ci@ec2-54-224-128-239.compute-1.amazonaws.com] has joined #mlpack
19:23 < travis-ci> mlpack/mlpack#4910 (master - d44d4cd : Marcus Edel): The build passed.
19:23 < travis-ci> Change view : https://github.com/mlpack/mlpack/compare/a30f5f8c119e...d44d4cdfcea6
19:23 < travis-ci> Build details : https://travis-ci.org/mlpack/mlpack/builds/379850633
19:23 -!- travis-ci [~travis-ci@ec2-54-224-128-239.compute-1.amazonaws.com] has left #mlpack []
19:30 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 256 seconds]
19:31 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
19:35 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 240 seconds]
19:39 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
19:46 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 260 seconds]
19:46 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
19:50 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 240 seconds]
19:51 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
20:06 -!- sumedhghaisas2 [~yaaic@2a00:79e0:d:fd00:4a3:d217:b63c:d812] has joined #mlpack
20:06 -!- sumedhghaisas [~yaaic@2a00:79e0:d:fd00:4a3:d217:b63c:d812] has quit [Ping timeout: 256 seconds]
20:11 -!- sumedhghaisas2 [~yaaic@2a00:79e0:d:fd00:4a3:d217:b63c:d812] has quit [Ping timeout: 256 seconds]
20:11 -!- sumedhghaisas2 [~yaaic@148.252.128.254] has joined #mlpack
20:23 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 256 seconds]
20:25 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
20:33 -!- sumedhghaisas2 [~yaaic@148.252.128.254] has quit [Read error: Connection reset by peer]
20:33 -!- sumedhghaisas [~yaaic@host-92-8-33-72.as43234.net] has joined #mlpack
20:39 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 240 seconds]
20:41 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
20:51 -!- ImQ009 [~ImQ009@unaffiliated/imq009] has quit [Quit: Leaving]
20:54 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 256 seconds]
21:09 -!- vivekp [~vivek@146.196.38.86] has joined #mlpack
21:09 -!- vivekp [~vivek@146.196.38.86] has quit [Changing host]
21:09 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
21:54 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 260 seconds]
22:01 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
22:06 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 260 seconds]
22:08 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
22:12 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 240 seconds]
22:14 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
22:19 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 260 seconds]
22:21 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
22:26 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 248 seconds]
22:41 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
22:45 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 264 seconds]
22:46 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
23:20 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 240 seconds]
23:22 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
23:44 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 268 seconds]
23:46 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
23:52 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 240 seconds]
23:53 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
23:58 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 260 seconds]
23:58 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
--- Log closed Thu May 17 00:00:22 2018