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/
picklerick has joined #mlpack
soonmok has joined #mlpack
picklerick has quit [Quit: WeeChat 2.3]
soonmok has quit [Remote host closed the connection]
soonmok has joined #mlpack
soonmok has quit [Remote host closed the connection]
soonmok has joined #mlpack
soonmok has quit [Remote host closed the connection]
soonmok has joined #mlpack
soonmok has quit [Remote host closed the connection]
soonmok has joined #mlpack
soonmok has quit [Remote host closed the connection]
soonmok has quit [Remote host closed the connection]
soonmok has joined #mlpack
prateek0001 has quit [Ping timeout: 246 seconds]
shardulparab97 has joined #mlpack
< shardulparab97>
Hi! @zoq @rcurtin I have added test cases and minor changes to #1704. Can you please let me know your thoughts about the same. Thanks! :)
< KimSangYeon-DGU>
In 'Static Code Analysis Checks', the recent checks were failed for the same reason "pvs-util/build/./how-to-use-pvs-studio-free: not found". Can anyone check this?
< zoq>
KimSangYeon: Yeah, noticed that as well, will check this later today.
< zoq>
shardulpara: Sure will take a look at the changes once I get a chance.
< KimSangYeon-DGU>
zoq: Thanks!
KimSangYeon-DGU has quit [Quit: Page closed]
witness has quit [Quit: Connection closed for inactivity]
KimSangYeon-DGU has joined #mlpack
prateek0001 has joined #mlpack
< shardulparab97>
Hi! I am interested in contributing towards GANs for GSoC 2019. Is there any specific current issue on which I can start working on related to the same? Thanks! :)
robertohueso has joined #mlpack
< ShikharJ>
shardulparab97: Hi, sorry for replying late, but if you're interested you may take a look at https://github.com/mlpack/mlpack/pull/1558. I've trying to find the time to finish up my pending PRs, but this particular semester is turning out to be too heavy to find the time. Take a look and see if you can make sense of the issue and the code, and maybe complete it then.
< shardulparab97>
Sure! Will look into the same and get back to you soon.
< ShikharJ>
rcurtin: Are you there?
Suryo has joined #mlpack
< Suryo>
zoq: here's an update. This is regarding implementing PSO.
< Suryo>
First update -- I spoke to a few other friends about the idea of implementing a separate class for particles. I gathered the pros and cons for this. Based on that I decided to not implement a separate class for particles.
< Suryo>
One reason is that we miss out on the advantages of using matrix operations for additions, subtractions, etc. Instead, as programmers we'll have to move every update inside a loop and that just gets cumbersome.
< Suryo>
I haven't dug deep into arma yet, but I am studying it and using it for a few other class projects now, so I don't know about the parallelization capabilities. However, that's the second consideration.
< Suryo>
Given that the linalg libraries have good parallelization methods included, we don't need to write our own threads.
< Suryo>
Which in themselves would be a lot more work.
< Suryo>
Along the same lines, it's just that if we partition the classes likewise, then using arma essentially serves no purpose. And you've asked me to use make sure that arma matrices are used.
< Suryo>
The second reason is that there would be more function calls involved. For a small number of particles, it's okay. But I think that in any practical scenario, I'd probably not go with a very small number of particles.
< Suryo>
So more function calls ~ larger execution time, depending on the complexity of the function.
< Suryo>
Having considered all this, I studied chintan's code in more detail and have been able to make it work within ensmallen. I've not pushed the changes to github yet as there are a couple of things I'd like to change.
< Suryo>
And these include (i) removing the gradient descent hybridization (ii) including a method that returns the position of the best particle, thus providing us information about the coordinates of the optimum
< Suryo>
(ii) is actually something I'd definitely look for while testing an optimization method.
< Suryo>
So these changes are probably not a very big deal. I'll get on with them.
< Suryo>
Let me know what you think, zoq.
< rcurtin>
ShikharJ: here now, sorry for the slow response
< prateek0001>
Hi everyone, I wanted to contribute to mlpack for GSOC 2019. I am interested in Bi-Directional RNNs and Restricted Boltzmann machines, where can I start with the same ?
< rcurtin>
I'm in California for a company convention so I am asleep later than usual :)
< Suryo>
zoq: so basically, I've been able to make the optimizer work but still have a few things to improve :)
soonmok has quit [Remote host closed the connection]
< rcurtin>
Suryo: I'm not familiar with PSO very much but I can at least say a few things about Armadillo and parallelization
< rcurtin>
internally Armadillo uses any LAPACK/BLAS library that's available, and OpenBLAS is a common choice
< rcurtin>
OpenBLAS is internally parallel (I believe via OpenMP) so many linear algebra operations will be parallelized
< rcurtin>
sometimes it may be better to use OpenMP in the ensmallen code where possible though, to parallelize from a higher level. I have no idea if that is applicable here though
< Suryo>
Okay thank you rcurtin
< ShikharJ>
rcurtin: Cool. I was wondering whether we're supposed to answer individual e-mails regarding GSoC, since I've been getting a ton of them lately. Can we make it a point in the template to direct all questions to the mailing list and the IRC?
< rcurtin>
ShikharJ: yeah, usually I'll give a boilerplate response pointing people to mlpack.org/gsoc.html and mlpack.org/involved.html and suggest they post any questions on the mailing list so that multiple people can response
< rcurtin>
*multiple people can respond
< ShikharJ>
Hmm, maybe we can make this explicit in the SummerofCodeIdeas page as well?
< rcurtin>
ah, that would be a good idea, want to add a bit about that on the page?
< ShikharJ>
Yeah, I'll do that now.
< rcurtin>
a justification is, it's better to ask the whole community since you're more likely to get a response from someone
< Suryo>
rcurtin: I'm aware of the internal parallelization that exists. However, that's one of the advantages that we would miss out on if I partitioned the PSO implementation across one class for the swarm and one for individual particles.
< Suryo>
So yeah, your point is applicable here.
< rcurtin>
Suryo: ok, glad the comments could help :)
soonmok has joined #mlpack
< ShikharJ>
rcurtin: Seems like it is already mentioned, but people overlook it nonetheless "Also, it is probably not a great idea to contact mentors directly (this is why their emails are not given here); a public discussion on the mailing list is preferred, if you need help or more information."
< ShikharJ>
I'll just change that to bold.
< rcurtin>
ShikharJ: yeah, I think a lot of people don't read the resources we give them
< rcurtin>
:)
Suryo has quit [Ping timeout: 256 seconds]
< ShikharJ>
All the more respect for you. I'm finding it hard to manage the time replying to the ones I get. I suspect your inbox would be through the roof :)
< rcurtin>
it hasn't been that bad this year yet
< rcurtin>
typically I set aside a specific block of time each day (maybe 30 minutes?) to handle emails and PRs related to GSoC
< rcurtin>
as we get closer to the GSoC application deadline that will probably need to be 60 minutes
< rcurtin>
but I try to be really careful to not get distracted from the things I am trying to work on for mlpack (it's difficult for sure!)
< ShikharJ>
Guess I'm not that good with my time management.
< rcurtin>
I guess, I should clarify, when I say "it hasn't been this bad" I just mean for me :) I am not getting *that* many personal emails, it sounds like you are getting more :)
< rcurtin>
it took me a _long_ time to get good with time management. GSoC was a big part of that, because it forced me to be very intentional with my time :)
< rcurtin>
the firs year in 2013, when I was basically the only mentor, I think I spent up to 4 hours a day handling GSoC requests... that was pretty awful
< rcurtin>
first*
< ShikharJ>
Ack, that sounds painful. Happy to share the load :)
< rcurtin>
:) glad to have you along
< rcurtin>
I think as a community we have definitely learned a lot over the years about GSoC
< rcurtin>
in the beginning we didn't have anything other than an ideas page, so people really had a hard time figuring out how to start contributing and there were _lots_ of questions
< ShikharJ>
I can understand if someone (who doesn't have a bit of open source development experience) has questions regarding how to get started, but really, the answer is quite obvious in itself. The key to anything is "Study and Practice". In mlpack's case, reading up the tutorials / issues, and building up the repo and tinkering up with the code.
< rcurtin>
yeah. most of the time that's what I end up telling people :)
< rcurtin>
having lots of open issues is helpful too, especially if they're detailed, since this gives an easy entry point to learn the code
< rcurtin>
I've been trying to do a better job with this this year than in previous years
< rcurtin>
I'm working on a new version of the mlpack website now, so I'm hoping this might also be helpful. still a lot of bits to do though (it's more complex than the ensmallen website...)
< ShikharJ>
That gave me some ideas regarding what to mention in the pull request template. Where can I access that?
< ShikharJ>
I was thinking of mentioning about test writing and other stuff.
< rcurtin>
do you mean accessing the new website or the PR templates?
< rcurtin>
I haven't written any PR templates or anything
< rcurtin>
I figured mlpack-bot served well enough as an issue template with its post to new contributors, but we can always update that message or maybe try PR templates
< rcurtin>
so long as it remains easy for people to quickly contribute 1 or 2 line fixes without needing to write a huge amount of info for the PR submission :)
< ShikharJ>
Hmm, I though just like the way we have a default template for issues, we might also have one for every time someone opens a PR. Wanted to mention about credible sources of tests and what to avoid when writing them.
< rcurtin>
yeah, definitely. maybe a Wiki page could be a good place to start for that? then we can either have mlpack-bot mention the page, or maybe make a really simple PR template that links to it?
< ShikharJ>
Yeah, not that I think of it, I could really use a wiki page to drive the point, and later mention it using mlpack-bot.
< ShikharJ>
I'll start putting together a piece now.
< rcurtin>
awesome---I can probably add some to it when you have it ready, so just let me know
< ShikharJ>
Cool :)
< rcurtin>
:)
bbc_ has joined #mlpack
bbc_ has quit [Client Quit]
< prateek0001>
@rcurtin , I have started working on the issue (https://github.com/mlpack/mlpack/issues/1489), I had some questions regarding the same(which I have posted on the issue thread) and wanted to know if you had any pointers as to how to go forward for solving it.
< prateek0001>
It is reagarding the Add operating in FFN which does not make copies
< rcurtin>
prateek0001: I saw your comment and I will answer when I have time
< prateek0001>
sure, whenever it is convinient for you :)
< rcurtin>
zoq: I'm going to try upgrading CMake on all the build systems to fix the CXX_STANDARD issue that is appearing in some of the builds
< rcurtin>
this means that I'll have to step masterblaster from 16.04 to 18.04
< rcurtin>
KimSangYeon-DGU: yeah, let's see if a CMake upgrade on masterblaster solves the issue. it will take a little while though until it's done :)
< KimSangYeon-DGU>
rcurtin: Thanks!
< rcurtin>
of course :)
< zoq>
right, they switch the C++ standard from 11 to 17
< zoq>
I think there is still some issue it hasn't detected anything in the past
< zoq>
even missed (size_t) k > 0
< zoq>
will open a PR for checks
< zoq>
#include <filesystem> dosn't work but #include <experimental/filesystem>
jenkins-mlpack has quit []
< zoq>
okay, now it's gone, did they pull the plug?
< KimSangYeon-DGU>
Can I rebuild the Static Code Analysis check?
< zoq>
Still needs a fix, once the build system is back I'll restart the check.
< rcurtin>
whew, that was scary. but masterblaster came back up successfuly
< KimSangYeon-DGU>
Hmm...
jenkins-mlpack has joined #mlpack
< rcurtin>
I imagine a few issues will still be there that need to be debugged as a result of the upgrade
< KimSangYeon-DGU>
scary..
< rcurtin>
I don't have physical access to the system so if it didn't come back up after the reboot, it wasn't clear how I would get it back online :)
< zoq>
right, we shouldn't mess up the configs :)
< KimSangYeon-DGU>
agreed
< rcurtin>
I see 'docker ps' is hanging, let's see if I can figure it out...
< zoq>
Fixed the pvs build, let
soonmok has quit [Remote host closed the connection]
< rcurtin>
ok, docker looks like it's behaving now
shardulparab97 has quit [Ping timeout: 256 seconds]
soonmok has joined #mlpack
soonmok has quit [Ping timeout: 268 seconds]
robertohueso has quit [Ping timeout: 245 seconds]
robertohueso has joined #mlpack
soonmok has joined #mlpack
soonmok has quit [Ping timeout: 272 seconds]
soonmok has joined #mlpack
< zoq>
Error on cppcheck analysis: java.io.IOException: Remote call on masterblaster failed ... great
< zoq>
I could update the script to the new format that cppcheck uses, not sure that solves the problem
< zoq>
perhaps a simple restart would solve the problem as well :)
< rcurtin>
restart of jenkins?
< zoq>
yeah
< rcurtin>
sure, hang on
jenkins-mlpack2 has quit []
jenkins-mlpack2 has joined #mlpack
< rcurtin>
ok, maybe that fixed it :)
< zoq>
let's see
soonmok has quit [Remote host closed the connection]