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/
trapz has joined #mlpack
trapz has quit [Quit: trapz]
vinayakvivek has joined #mlpack
< kdkw> zoq: thank you
Alvis has quit [Ping timeout: 246 seconds]
vivekp has quit [Ping timeout: 258 seconds]
vivekp has joined #mlpack
kartik__ has quit [Ping timeout: 246 seconds]
< kdkw> zoq: I think currently KL divergence can only be accessed via Sparse AutoEncoders. I was thinking that it might be nice to separate out the probability divergences (like KL, Reverse KL, Squared hellinger, Pearson, Wasserstein) in a different module
< kdkw> They would serve the general purpose of defining the distance between prob distributions and also allow people to tinker with them in the discriminator part of GANs
< kdkw> What do you think?
sumedhghaisas has quit [Ping timeout: 268 seconds]
< kdkw> I am not sure if it's happening with me only, but the layout of the documentation on this page seems weird. http://www.mlpack.org/docs/mlpack-git/doxygen.php?doc=adam_8hpp_source.html
chenzhe has joined #mlpack
vivekp has quit [Ping timeout: 258 seconds]
kartik_ has joined #mlpack
< kartik_> <zoq> please go through my proposal and give ur feedback
vivekp has joined #mlpack
kartik_ has quit [Remote host closed the connection]
trapz has joined #mlpack
deepanshu_ has joined #mlpack
vivekp has quit [Ping timeout: 246 seconds]
vivekp has joined #mlpack
chenzhe has quit [Ping timeout: 256 seconds]
trapz has quit [Quit: trapz]
trapz has joined #mlpack
nish21 has joined #mlpack
nish21 has quit [Client Quit]
Alvis has joined #mlpack
Vz_ has joined #mlpack
govg has quit [Ping timeout: 264 seconds]
sagarbhathwar has joined #mlpack
deepanshu_ has quit [Quit: Connection closed for inactivity]
nu11p7r has joined #mlpack
< ironstark> zoq: There were some bugs in the lars algorithm implementation of scikit learn. I have made a PR(# 41) to correct it. Please Review
< ironstark> Also my PR(#33) for annoy implementation has passed the jenkins test. Please Review it too whenever you find time :)
Vz_ has quit [Quit: died]
govg has joined #mlpack
naxalpha has joined #mlpack
vss has joined #mlpack
Alvis has quit [Remote host closed the connection]
Alvis has joined #mlpack
trapz has quit [Quit: trapz]
nish21 has joined #mlpack
< kdkw> @rcurtin, @zoq are you there? need your help urgently
< rcurtin> kdkw: did you just send the email to us and gsoc-support?
< rcurtin> if so I just responded
< kdkw> Yes
< kdkw> Is there anything I can do?
< kdkw> I am really really feeling bad
< rcurtin> I thought the deadline was tonight, not just a little while ago, I must have been confused
< kdkw> I truly wanted to be a part of Gsoc and contribute to mlpack
< rcurtin> I am sorry, I think there is nothing that can be done
< rcurtin> I am at lunch now, I will be back later
< kdkw> Can you atleast take a look at my proposal?
trapz has joined #mlpack
nish21 has quit [Ping timeout: 260 seconds]
sagarbhathwar has quit [Quit: Page closed]
Guest95911 has quit [Ping timeout: 264 seconds]
naxalpha has quit [Ping timeout: 260 seconds]
vss has quit [Ping timeout: 260 seconds]
< rcurtin> kdkw: I can try and look when I have a chance
< rcurtin> I'm sorry that the submission did not work out, I know how frustrating that can be
Alvis has quit [Ping timeout: 246 seconds]
sahilc has joined #mlpack
< sahilc> hey guys, I have submitted my proposal for GsoC, could you tell me if there is anything I can do to improve or verify anything about it!
< rcurtin> hi Sahil, we'll take a look through the proposals in the next weeks
< rcurtin> this year we got 69; less than last year's 119, but still quite a lot to go through
< sahilc> Thanks Ryan! Does mlpack have a policy regarding mailing authors of papers for code?
< sahilc> To run benchmarks against, can I mention that I am thinking of including an author's code in the mlpack library?
< rcurtin> sure, I don't know why we as a library would have a policy against mailing completely separate authors of papers
< sahilc> I thought it'd be nice to let the authors know that we were thinking about adopting their algorithms (They can help smooth over any doubts that we have too)
< rcurtin> yeah, this is usually a nice thing to do
< rcurtin> as long as their algorithms do end up actually getting adopted in the end :)
Alvis has joined #mlpack
keonkim has joined #mlpack
Alvis has quit [Ping timeout: 246 seconds]
Alvis has joined #mlpack
govg has quit [Ping timeout: 260 seconds]
Alvis has quit [Ping timeout: 246 seconds]
< ironstark> rcurtin : I have made my comments and done some amends as suggested by you on PR(#41). Please take a look
< rcurtin> ironstark: I get an email every time you make an update, don't worry, I already saw it :)
< rcurtin> I will address it when I have a chance
< ironstark> okay :)
govg has joined #mlpack
Alvis has joined #mlpack
sahilc has quit [Ping timeout: 260 seconds]
diehumblex has quit [Quit: Connection closed for inactivity]
Alvis_ has joined #mlpack
Alvis has quit [Ping timeout: 246 seconds]
< rcurtin> zoq: looks like masterblaster will ship on Wednesday, and should be back up by midday Friday... hopefully
< rcurtin> those plans are tentative, I'll update if anything changes
Alvis_ has quit [Remote host closed the connection]
Alvis has joined #mlpack
< zoq> rcurtin: Sounds like a really short downtime. Respect to the guys who manage the new location.
< rcurtin> I'll believe it when it happens, but they will at least use next-day shipping and the team in Oregon says they can have it online within 24 hours
chenzhe has joined #mlpack
< rcurtin> zoq: I see that now the annoy benchmarking script is merged, what do we do to get Jenkins to build the job?
< rcurtin> I guess we need a new 'benchmark - annoy' job?
< zoq> rcurtin: Yeah, maybe there is another way to benchmark lib x? Maybe something like a parameterized build, not sure this is a good idea.
< rcurtin> hm, we could have a matrix build where one axis is the block to test
< rcurtin> but I don't think we can fire off just one build for that
< rcurtin> I think it would also be okay to run that matrix build in full every few weeks
< zoq> I guess what we could do is to build every two weeks and at the same time include some option that checks if we already benchmarked the version.
< rcurtin> what do you think? I can go ahead and set that job up, and then we can have the database push to mlpack.org after that is done
< zoq> Sounds good.
< rcurtin> hm, one other question, do we have a way to get from the database what version of each library was used?
< zoq> not now
< zoq> The config already specifies the version, so we already have the information but not in the database.
< rcurtin> right, ok
< rcurtin> I'll open an issue for it while I am thinking about it... if we are going to deploy benchmarking reports to the website every couple weeks then it should be possible for the user to find out what version of the library we used
< zoq> right, good idea
< rcurtin> I'll go ahead and start playing with the matrix build, since I feel like my knowledge of the benchmarking system is somewhat incomplete and I want to change that :)
< zoq> okay, btw. not sure if you need that the 'benchmark - checkout - all nodes' installs all libs maybe it would be a good idea to create a build script for each lib and host it somewhere instead of using Jenkins run cmd.
< rcurtin> yeah, I agree
< rcurtin> it seems like the build will have be in two steps, with the checkout job happening first
< rcurtin> but maybe we can keep the package build scripts also in the benchmark repository, or in a separate benchmark-support repository, what do you think?
travis-ci has joined #mlpack
< travis-ci> mlpack/mlpack#2244 (master - fcf165b : Marcus Edel): The build was broken.
travis-ci has left #mlpack []
< zoq> I guess, we could put them into the benchmarks repo, maybe they are useful for others.
< rcurtin> sure, I will do that
< zoq> Also I was thinking if transfering the repo into the mlpack org would make things easier.
< rcurtin> sure that sounds good to me
< rcurtin> do you want to go ahead and do that?
< zoq> should be easy, let's see
< zoq> there you go
< rcurtin> great, always good when it is a quick process :)
trapz has quit [Quit: trapz]
< cult-> dfefv
< cult-> sorry my keyboard lives on its own
< cult-> anyway it was super hard to store algorithm objects that doesn't have default constructor
< cult-> object*; doesn't simply work, it can come out of scope or produce strange things. i have had to store it inside a method and pass them by the arguments in that.
< cult-> took me 4 hours to figure out, and even more in the past. i think all algorithms should have default constructors for storing them in the memory across classes.
chenzhe has quit [Ping timeout: 246 seconds]
< rcurtin> cult-: are you talking about the HoeffdingTree<> class?
< rcurtin> I guess that the HoeffdingTree class does not have a default constructor, youa re right
< rcurtin> the main program serializes the HoeffdingTreeModel() class instead to get around that
< rcurtin> I guess, if you like, you can open an issue for it on github
vinayakvivek has quit [Quit: Connection closed for inactivity]
trapz has joined #mlpack
chenzhe has joined #mlpack
Alvis has quit [Ping timeout: 246 seconds]
Alvis has joined #mlpack
trapz_ has joined #mlpack
Alvis_ has joined #mlpack
trapz has quit [Ping timeout: 260 seconds]
trapz_ is now known as trapz
Alvis has quit [Ping timeout: 246 seconds]