verne.freenode.net changed the topic of #mlpack to: http://www.mlpack.org/ -- We don't respond instantly... but we will respond. Give it a few minutes. Or hours. -- Channel logs: http://www.mlpack.org/irc/
curiousguy13 has joined #mlpack
stephentu has quit [Ping timeout: 244 seconds]
prakhar2511 has joined #mlpack
stephentu has joined #mlpack
curiousguy13 has quit [Ping timeout: 255 seconds]
curiousguy13 has joined #mlpack
prakhar2511 has quit [Ping timeout: 256 seconds]
curiousguy13 has quit [Quit: Leaving]
prakhar2511 has joined #mlpack
kshitijk has joined #mlpack
kshitijk has quit [Ping timeout: 246 seconds]
kshitijk has joined #mlpack
kshitijk has quit [Ping timeout: 245 seconds]
stephentu has quit [Quit: Lost terminal]
prakhar2511 has quit [Ping timeout: 264 seconds]
curiousguy13 has joined #mlpack
apir8181 has joined #mlpack
< apir8181> Hi, I don't understand why mlpack need the class mlpack/core/util/NullOutputStream. If not in debug mode, we can just pass true to constructor argument ignoreInput.
< apir8181> At present, if DEBUG mode is enabled, core/util/Log::Debug would be type of PrefixedOutputStream. If not, it would be type of NullOutputStream.
prakhar2511 has joined #mlpack
< naywhayare> apir8181: the NullOutputStream causes every single call to Log::Debug to be optimized out entirely
< naywhayare> although it's possible that a smart compiler could realize that ignoreInput was true and Log::Debug was an unnecessary class, I don't think we can reasonably assume that every compiler will do that
kshitijk has joined #mlpack
< apir8181> naywhayare: That sounds cool.
govg has joined #mlpack
curiousguy13 has quit [Ping timeout: 264 seconds]
curiousguy13 has joined #mlpack
prakhar2511 has quit [Ping timeout: 245 seconds]
prakhar2511 has joined #mlpack
prakhar2511 has quit [Ping timeout: 264 seconds]
prakhar2511 has joined #mlpack
prakhar2511 has quit [Ping timeout: 252 seconds]
apir8181 has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
kshitijk has quit [Ping timeout: 264 seconds]
prakhar2511 has joined #mlpack
kshitijk has joined #mlpack
stephentu has joined #mlpack
stephentu has quit [Ping timeout: 246 seconds]
stephentu has joined #mlpack
< naywhayare> stephentu: sorry about the delay on the generalized eigensolver
< naywhayare> the SuperLU wrapping is going super slow
< naywhayare> the documentation isn't all that great and the package is really hard to work with... (that plus my time is pretty limited)
< naywhayare> but if I had to guess, you're pretty busy too :)
kshitijk has quit [Ping timeout: 255 seconds]
kshitijk has joined #mlpack
< stephentu> naywhayare: ya i'm trying to grind through some idea
< stephentu> naywhayare: while doing psets during the weekend
< stephentu> no rush man
< stephentu> i'm excited for this to be a gsoc project though
< naywhayare> yeah, I think it will be a good one
< stephentu> when do the apps start coming in?
< naywhayare> March 2 is when they announce accepted organizations
< naywhayare> if mlpack is accepted (it probably will be -- google likes machine learning), then the mailing list will explode
< naywhayare> applications start a few weeks later (March 16)
< naywhayare> the first year we got 50 or so, but last year we got fewer (I think because we made the applications a decent amount more difficult and were more realistic with students about what they needed to do to have a competitive chance)
< naywhayare> the quality of applicants last year was a lot higher
< naywhayare> (or, the average quality, that is)
lezorich has joined #mlpack
curiousguy13 has quit [Ping timeout: 272 seconds]
curiousguy13 has joined #mlpack
< stephentu> oh god screening 50 applications sounds horrible
< stephentu> haha lets make it super restrictive: "must be intimiately familiar with nesterov's volumes on convex opt"
< stephentu> :)
< naywhayare> the applications are generally bimodal
< naywhayare> and most of the applications that are seriously considered are from students we've already been in touch with and who have already made a decent number of contributions
< naywhayare> so throwing away the ones that are crap is easy
< naywhayare> I got one the first year where the applicant had said "I didn't have time to finish the application, please click this link in a few days"
Jigar54 has joined #mlpack
Jigar54 has quit [Ping timeout: 250 seconds]
kshitijk has quit [Ping timeout: 255 seconds]
< lezorich> naywhayare: should I contribute first in order to be a GSoC student? I know that's the ideal, but the project I'm interested in is more research oriented (Fast k-centers algorithm & implementation)
< naywhayare> lezorich: a contribution isn't required, so don't take what I wrote earlier to heart as "I need to have 3 or more contributions to be accepted!"
< naywhayare> contributions are definitely helpful in showing us that you are capable of writing good code
< naywhayare> for the k-centers algorithm, you're right, it is more research oriented
vlad_gl has joined #mlpack
< naywhayare> even so, the mlpack abstractions for dual-tree algorithms are complex, so it's certainly worth poking around with them and playing with them, and I wouldn't be surprised if you ended up contributing in the course of learning about the framework mlpack has
< vlad_gl> naywhayare: Hi! I tried to do #406, but have a different neighbours for X.col(i) and H.col(i). I build query for H.col([users list]) and then just compute AllkNN for H and query. Is that right?
< naywhayare> hi vlad, I'm still working on writing up the document for single-tree GMM training :)
< naywhayare> I hope to have it done in a day or two...
< naywhayare> anyway...
stephent1 has joined #mlpack
< naywhayare> if we use H instead of X, it should give us the same neighborhood of users unless my derivation is wrong
stephentu has quit [Ping timeout: 250 seconds]
< naywhayare> so if I run AllkNN(H) (which uses H as both the queries and references), the resulting neighborhood should be identical to if we ran AllkNN(X) (with X as both the queries and the references)
< naywhayare> you're saying that you're doing that, but the results are different?
< vlad_gl> I try run AllkNN(H, query), there query is the matrix of H.col(user) columns.
< vlad_gl> where* :)
< naywhayare> yeah; and this gives different results than AllkNN(X, query) (where query is built from X.col(user))?
< vlad_gl> yes
< naywhayare> oh, right, I think my derivation is wrong
< naywhayare> X.col(i) = W * H.col(i)
< naywhayare> that part is correct
< vlad_gl> yeah :)
< naywhayare> but it is not true that the distance d(X.col(i), X.col(j)) = d(H.col(i), H.col(j))
< vlad_gl> d(x1,x2) = d(h1,h2)? i think you mean just order.
< naywhayare> yeah, that statement can't be true:
< naywhayare> d(X.col(i), X.col(j)) = d(W * H.col(i), W * H.col(j))
< naywhayare> but d(W * H.col(i), W * H.col(j)) != d(H.col(i), H.col(j))
< vlad_gl> ok
< naywhayare> so I guess I need to rethink my derivation a little bit
< naywhayare> the GMMs are higher on my priority list, though, so I'll get to those first...
prakhar2511 has quit [Ping timeout: 252 seconds]
< naywhayare> thanks for pointing that out :)
< lezorich> naywhayare: I agree with you that contributions are helpful :) And yes, Ryan Curtin also suggested me to look implementations of dual-tree algorithms in mlpack, so may be there I can contribute in order to make a strong application
< vlad_gl> naywhayare: not at all : )
Jigar54 has joined #mlpack
< vlad_gl> so, while you working gmm document, I also looked at #345. gmm_diag only supports from armadillo version 4.40. and it's does not support real probabilities as parameter. So, I can try to implement this.
< vlad_gl> or it is depends on what are you working now?
vlad_gl has quit [Quit: Page closed]
prakhar2511 has joined #mlpack