fast, flexible C++ machine learning library

mlpack IRC logs, 2019-02-06

Logs for the day 2019-02-06 (starts at 0:00 UTC) are shown below.

February 2019
--- Log opened Wed Feb 06 00:00:50 2019
01:41 -!- picklerick [~whoopityd@2405:204:c286:2e17:35b9:ce93:8f9:9710] has joined #mlpack
01:54 -!- soonmok [~soonmok@] has joined #mlpack
03:22 -!- picklerick [~whoopityd@2405:204:c286:2e17:35b9:ce93:8f9:9710] has quit [Quit: WeeChat 2.3]
04:43 -!- soonmok [~soonmok@] has quit [Remote host closed the connection]
04:46 -!- soonmok [~soonmok@] has joined #mlpack
04:48 -!- soonmok [~soonmok@] has quit [Remote host closed the connection]
05:05 -!- soonmok [~soonmok@] has joined #mlpack
05:33 -!- soonmok [~soonmok@] has quit [Remote host closed the connection]
05:33 -!- soonmok [~soonmok@] has joined #mlpack
05:37 -!- soonmok [~soonmok@] has quit [Remote host closed the connection]
05:58 -!- soonmok [~soonmok@] has joined #mlpack
05:59 -!- soonmok [~soonmok@] has quit [Remote host closed the connection]
06:07 -!- favre49 [75dcafe2@gateway/web/freenode/ip.] has joined #mlpack
06:08 -!- favre49 [75dcafe2@gateway/web/freenode/ip.] has quit [Client Quit]
08:19 -!- witness [uid10044@gateway/web/irccloud.com/x-niuakhblmacuwpdn] has joined #mlpack
08:31 -!- prateek0001 [~prateek@] has joined #mlpack
08:32 -!- niteya [~niteya@2402:3a80:47b:50fd:e059:bfa:96e5:cc5b] has joined #mlpack
08:45 < jenkins-mlpack2> Project docker mlpack nightly build build #210: STILL UNSTABLE in 3 hr 31 min: http://ci.mlpack.org/job/docker%20mlpack%20nightly%20build/210/
08:48 -!- niteya [~niteya@2402:3a80:47b:50fd:e059:bfa:96e5:cc5b] has quit [Quit: Leaving]
10:46 -!- KimSangYeon-DGU [dc48328a@gateway/web/freenode/ip.] has joined #mlpack
11:06 -!- aniket [6725c92d@gateway/web/freenode/ip.] has joined #mlpack
11:07 < aniket> Hi everyone!
11:38 -!- soonmok [~soonmok@] has joined #mlpack
11:42 -!- aniket [6725c92d@gateway/web/freenode/ip.] has quit [Ping timeout: 256 seconds]
12:25 -!- aniket [6725c92d@gateway/web/freenode/ip.] has joined #mlpack
12:27 -!- aniket [6725c92d@gateway/web/freenode/ip.] has quit [Client Quit]
12:28 -!- aniket [6725c92d@gateway/web/freenode/ip.] has joined #mlpack
12:28 -!- aniket [6725c92d@gateway/web/freenode/ip.] has quit [Client Quit]
12:32 -!- soonmok [~soonmok@] has quit [Remote host closed the connection]
12:34 < zoq> aniket: Hello there!
12:36 -!- soonmok [~soonmok@] has joined #mlpack
12:37 -!- travis-ci [~travis-ci@ec2-54-163-166-160.compute-1.amazonaws.com] has joined #mlpack
12:37 < travis-ci> saksham189/mlpack#44 (br - 1ffdc1b : Saksham Bansal): The build has errored.
12:37 < travis-ci> Change view : https://github.com/saksham189/mlpack/compare/00e3100a3b4b...1ffdc1b02dc2
12:37 < travis-ci> Build details : https://travis-ci.org/saksham189/mlpack/builds/489509072
12:37 -!- travis-ci [~travis-ci@ec2-54-163-166-160.compute-1.amazonaws.com] has left #mlpack []
13:03 -!- soonmok [~soonmok@] has quit [Remote host closed the connection]
13:12 -!- soonmok [~soonmok@] has joined #mlpack
13:51 -!- prateek0001 [~prateek@] has quit [Ping timeout: 246 seconds]
14:18 -!- shardulparab97 [ab4c55b4@gateway/web/freenode/ip.] has joined #mlpack
14:19 < 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! :)
14:36 < 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?
14:38 < zoq> KimSangYeon: Yeah, noticed that as well, will check this later today.
14:38 < zoq> shardulpara: Sure will take a look at the changes once I get a chance.
14:39 < KimSangYeon-DGU> zoq: Thanks!
14:40 -!- KimSangYeon-DGU [dc48328a@gateway/web/freenode/ip.] has quit [Quit: Page closed]
14:59 -!- witness [uid10044@gateway/web/irccloud.com/x-niuakhblmacuwpdn] has quit [Quit: Connection closed for inactivity]
15:17 -!- KimSangYeon-DGU [7a2890dd@gateway/web/freenode/ip.] has joined #mlpack
15:26 -!- prateek0001 [~prateek@] has joined #mlpack
15:46 < 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! :)
16:06 -!- robertohueso [~robertohu@] has joined #mlpack
16:18 < 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.
16:21 < shardulparab97> Sure! Will look into the same and get back to you soon.
16:26 < ShikharJ> rcurtin: Are you there?
16:37 -!- Suryo [4cb94ed9@gateway/web/freenode/ip.] has joined #mlpack
16:39 < Suryo> zoq: here's an update. This is regarding implementing PSO.
16:40 < 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.
16:42 < 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.
16:43 < 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.
16:43 < Suryo> Given that the linalg libraries have good parallelization methods included, we don't need to write our own threads.
16:44 < Suryo> Which in themselves would be a lot more work.
16:45 < 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.
16:46 < 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.
16:46 < Suryo> So more function calls ~ larger execution time, depending on the complexity of the function.
16:47 < 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.
16:48 < 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
16:49 < Suryo> (ii) is actually something I'd definitely look for while testing an optimization method.
16:50 < Suryo> So these changes are probably not a very big deal. I'll get on with them.
16:51 < Suryo> Let me know what you think, zoq.
16:54 < rcurtin> ShikharJ: here now, sorry for the slow response
16:54 < 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 ?
16:54 < rcurtin> I'm in California for a company convention so I am asleep later than usual :)
16:56 < Suryo> zoq: so basically, I've been able to make the optimizer work but still have a few things to improve :)
16:58 -!- soonmok [~soonmok@] has quit [Remote host closed the connection]
17:01 < rcurtin> Suryo: I'm not familiar with PSO very much but I can at least say a few things about Armadillo and parallelization
17:01 < rcurtin> internally Armadillo uses any LAPACK/BLAS library that's available, and OpenBLAS is a common choice
17:01 < rcurtin> OpenBLAS is internally parallel (I believe via OpenMP) so many linear algebra operations will be parallelized
17:02 < 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
17:02 < Suryo> Okay thank you rcurtin
17:02 < 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?
17:02 < 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
17:03 < rcurtin> *multiple people can respond
17:04 < ShikharJ> Hmm, maybe we can make this explicit in the SummerofCodeIdeas page as well?
17:08 < rcurtin> ah, that would be a good idea, want to add a bit about that on the page?
17:09 < ShikharJ> Yeah, I'll do that now.
17:09 < rcurtin> a justification is, it's better to ask the whole community since you're more likely to get a response from someone
17:16 < 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.
17:17 < Suryo> So yeah, your point is applicable here.
17:21 < rcurtin> Suryo: ok, glad the comments could help :)
17:23 -!- soonmok [~soonmok@] has joined #mlpack
17:25 < 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."
17:25 < ShikharJ> I'll just change that to bold.
17:34 < rcurtin> ShikharJ: yeah, I think a lot of people don't read the resources we give them
17:34 < rcurtin> :)
17:35 -!- Suryo [4cb94ed9@gateway/web/freenode/ip.] has quit [Ping timeout: 256 seconds]
17:36 < 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 :)
17:40 < rcurtin> it hasn't been that bad this year yet
17:40 < rcurtin> typically I set aside a specific block of time each day (maybe 30 minutes?) to handle emails and PRs related to GSoC
17:41 < rcurtin> as we get closer to the GSoC application deadline that will probably need to be 60 minutes
17:41 < 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!)
17:41 < ShikharJ> Guess I'm not that good with my time management.
17:41 < 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 :)
17:42 < 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 :)
17:43 < 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
17:44 < rcurtin> first*
17:45 < ShikharJ> Ack, that sounds painful. Happy to share the load :)
17:45 < rcurtin> :) glad to have you along
17:46 < rcurtin> I think as a community we have definitely learned a lot over the years about GSoC
17:46 < 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
17:55 < 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.
17:56 < rcurtin> yeah. most of the time that's what I end up telling people :)
17:56 < 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
17:56 < rcurtin> I've been trying to do a better job with this this year than in previous years
17:59 < 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...)
18:00 < ShikharJ> That gave me some ideas regarding what to mention in the pull request template. Where can I access that?
18:00 < ShikharJ> I was thinking of mentioning about test writing and other stuff.
18:00 < rcurtin> do you mean accessing the new website or the PR templates?
18:00 < rcurtin> I haven't written any PR templates or anything
18:01 < 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
18:01 < 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 :)
18:02 < 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.
18:03 < 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?
18:04 < 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.
18:04 < ShikharJ> I'll start putting together a piece now.
18:04 < rcurtin> awesome---I can probably add some to it when you have it ready, so just let me know
18:05 < ShikharJ> Cool :)
18:05 < rcurtin> :)
18:06 -!- bbc_ [67f98750@gateway/web/freenode/ip.] has joined #mlpack
18:09 -!- bbc_ [67f98750@gateway/web/freenode/ip.] has quit [Client Quit]
18:09 < 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.
18:10 < prateek0001> It is reagarding the Add operating in FFN which does not make copies
18:15 < rcurtin> prateek0001: I saw your comment and I will answer when I have time
18:17 < prateek0001> sure, whenever it is convinient for you :)
18:53 < 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
18:54 < rcurtin> this means that I'll have to step masterblaster from 16.04 to 18.04
18:56 -!- prateek0001 [~prateek@] has quit [Ping timeout: 245 seconds]
19:00 < KimSangYeon-DGU> zoq: I checked briefly, https://github.com/viva64/how-to-use-pvs-studio-free has changed their `CMakeLists.txt` so that I think the version is not compatibie with us.
19:05 < 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 :)
19:06 < KimSangYeon-DGU> rcurtin: Thanks!
19:08 < rcurtin> of course :)
19:22 < zoq> right, they switch the C++ standard from 11 to 17
19:24 < zoq> I think there is still some issue it hasn't detected anything in the past
19:24 < zoq> even missed (size_t) k > 0
19:25 < zoq> will open a PR for checks
19:33 < zoq> #include <filesystem> dosn't work but #include <experimental/filesystem>
19:35 -!- jenkins-mlpack [~PircBotx@] has quit []
19:37 < zoq> okay, now it's gone, did they pull the plug?
19:39 < KimSangYeon-DGU> Can I rebuild the Static Code Analysis check?
19:40 < zoq> Still needs a fix, once the build system is back I'll restart the check.
19:40 < rcurtin> whew, that was scary. but masterblaster came back up successfuly
19:40 < KimSangYeon-DGU> Hmm...
19:41 -!- jenkins-mlpack [~PircBotx@] has joined #mlpack
19:41 < rcurtin> I imagine a few issues will still be there that need to be debugged as a result of the upgrade
19:42 < KimSangYeon-DGU> scary..
19:44 < 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 :)
19:45 < zoq> right, we shouldn't mess up the configs :)
19:46 < KimSangYeon-DGU> agreed
19:46 < rcurtin> I see 'docker ps' is hanging, let's see if I can figure it out...
19:47 < zoq> Fixed the pvs build, let
19:57 -!- soonmok [~soonmok@] has quit [Remote host closed the connection]
19:58 < rcurtin> ok, docker looks like it's behaving now
20:02 -!- shardulparab97 [ab4c55b4@gateway/web/freenode/ip.] has quit [Ping timeout: 256 seconds]
20:51 -!- soonmok [~soonmok@] has joined #mlpack
20:56 -!- soonmok [~soonmok@] has quit [Ping timeout: 268 seconds]
21:33 -!- robertohueso [~robertohu@] has quit [Ping timeout: 245 seconds]
21:33 -!- robertohueso [~robertohu@] has joined #mlpack
21:51 -!- soonmok [~soonmok@] has joined #mlpack
21:56 -!- soonmok [~soonmok@] has quit [Ping timeout: 272 seconds]
22:16 -!- soonmok [~soonmok@] has joined #mlpack
22:19 < zoq> Error on cppcheck analysis: java.io.IOException: Remote call on masterblaster failed ... great
22:20 < zoq> I could update the script to the new format that cppcheck uses, not sure that solves the problem
22:20 < zoq> perhaps a simple restart would solve the problem as well :)
22:22 < rcurtin> restart of jenkins?
22:22 < zoq> yeah
22:22 < rcurtin> sure, hang on
22:23 -!- jenkins-mlpack2 [~PircBotx@knife.lugatgt.org] has quit []
22:24 -!- jenkins-mlpack2 [~PircBotx@knife.lugatgt.org] has joined #mlpack
22:24 < rcurtin> ok, maybe that fixed it :)
22:24 < zoq> let's see
23:10 -!- soonmok [~soonmok@] has quit [Remote host closed the connection]
23:10 -!- soonmok [~soonmok@] has joined #mlpack
--- Log closed Thu Feb 07 00:00:52 2019