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
< 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>
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?