ChanServ changed the topic of #mlpack to: "mlpack: a fast, flexible machine learning library :: We don't always respond instantly, but we will respond; please be patient :: Logs at http://www.mlpack.org/irc/
caiojcarvalho has quit [Ping timeout: 268 seconds]
soonmok has joined #mlpack
caiojcarvalho has joined #mlpack
ronit has joined #mlpack
soonmok has quit [Remote host closed the connection]
soonmok has joined #mlpack
soonmok has quit [Ping timeout: 268 seconds]
caiojcarvalho has quit [Ping timeout: 246 seconds]
soonmok has joined #mlpack
soonmok has quit [Remote host closed the connection]
soonmok has joined #mlpack
vivekp has joined #mlpack
krishna has joined #mlpack
< krishna>
Respected sir,
< krishna>
I am a B.Tech student in Computer Science and Engineering from India
< krishna>
Previously I have been looking into mlpack organisation from different source like github
< krishna>
after going through it I wish to contribute to this open source organisation
< krishna>
any input I can get regarding this?
soonmok has quit [Remote host closed the connection]
< krishna>
I wish to contribute by adding a differential evolution algorithm to the existing mlpack libraries. Can that be an effective addition to it?
soonmok has quit [Remote host closed the connection]
soonmok has joined #mlpack
soonmok has quit [Ping timeout: 250 seconds]
soonmok has joined #mlpack
soonmok has quit [Remote host closed the connection]
< rcurtin>
lots of people misunderstanding why someone would use C++ in that thread
< zoq>
not the first time I see the discussion about armadillo and autodiff
< ShikharJ>
Hmm, I've been looking at the comments, and they really seem to be interested in an autodiff solver. Might be a good project for GSoC?
< rcurtin>
I feel like it would be a huge amount of maintenance. but, one thing that might be useful is seeing if ensmallen could use some existing C++ autodiff package
< zoq>
Agreed, getting autodiff right is a huge effort, not sure GSoC is a good fit for such a project.
< ShikharJ>
That could be a good option too.
< rcurtin>
it's probably enough work to get some autodiff package working with ensmallen and then write up tutorials and documentation for it, I suspect :)
< rcurtin>
one of the important things will be benchmarking, since often autodiff implementations can be slower
< zoq>
right, I think the paper has some compelling numbers in that direction
< ShikharJ>
Some people also seem to be concerned with the non-use of Eigen and the compile times for ensmallen. How big of an issue is that?
< ShikharJ>
I didn't see compile times reduce by much when we shifted ensmallen to a separate repository, so I think it might be safe to assume that it doesn't lead to a huge compile time overhead?
< rcurtin>
if you're driven to using C++ for your application, it's likely that compile time doesn't really matter all that much
< rcurtin>
certainly compiling some program that uses ensmallen will increase the compile time, but not by too much more than what Armadillo already does
< rcurtin>
I don't understand everyone's focus on Eigen instead of Armadillo either. sure, it's what TensorFlow used... but the syntax for Armadillo is so much nicer
< rcurtin>
and the fact that it wraps any LAPACK/BLAS is, in my opinion, a better thing than hand-implemented BLAS like Eigen did
< rcurtin>
but... I realize that I have a biased perspective :)
< ShikharJ>
Hmm, I have to agree that Armadillo's source code has got to be the most beautiful piece of code I have seen in a long time.