mlpack IRC logs, 2017-03-10

Logs for the day 2017-03-10 (starts at 0:00 UTC) are shown below.

March 2017
--- Log opened Fri Mar 10 00:00:36 2017
00:28 < zoq> okay, was worth a test ...
00:32 < rcurtin> looks like that time it took ~18 minutes
00:33 -!- kris2 [~kris@] has joined #mlpack
00:35 < kris2> zoq: i am getting a seg fault. examining the stack trace there is a issue with destructor of arma::col but i am not able to figure it out fully.
00:35 < kris2> can you help
00:35 < kris2> here is the code
00:35 < kris2> in function get action
00:37 < kris2> GetAction
00:38 < rcurtin> kris2: try compiling with debugging symbols and see if Armadillo throws an out-of-bounds exception or something
00:38 < rcurtin> and if that doesn't bring anything up, try running it with valgrind to see if there is an invalid memory access or something like this
00:38 < rcurtin> that would be my first guess for what's wrong there
00:38 < rcurtin> I know you weren't asking me but I thought maybe I could try to help anyway :)
00:41 < kris2> rcurting: ya i am tring that right now....... any help is appreciated.....:)
00:48 < rcurtin> I'm not seeing anything obvious just by looking at it
00:48 < rcurtin> either of the ideas I said should give you some good input towards what is actually happening
00:49 < kris2> debugging symbols which ones exactly do you mean
00:51 < rcurtin> compile with -g -DDEBUG
01:00 -!- sicko [~sicko@] has quit [Ping timeout: 260 seconds]
01:00 < kris2> valgrind says unconditional jump .... so partially initialized variable i think.....have to figure out which one
01:11 < zoq> kris2: That is a good tip, take a look at the return value of GetAction.
01:14 < kris2> yes it works now.I should have compiled with -Wall i think it would have given me a warning for that. Noted
02:24 < zoq> okay, I restarted the commit job and now the RecurrentNetworkTest takes 1 min 14 sec. Maybe that is a wild guess, but could this be an entropy problem?
02:39 < zoq> If we use /dev/random which I'm not sure we do, we could end up waiting for entropy.
02:41 < zoq> Let's restart the job again and see what happens "cat /proc/sys/kernel/random/entropy_avail" returns 27
02:56 < zoq> Looks like armadillo uses /dev/urandom which will never block.
03:00 < zoq> at least on Linux
03:25 < zoq> RecurrentNetworkTest 29 sec, I think I'll restart the job once again tomorrow, if the machine is still up.
03:44 < rcurtin> yeah it looks like the move will not happen tomorrow
03:45 < rcurtin> I I don't have much more input yet on when it will happen
03:45 < rcurtin> but I talked to some folks to help set the process in motion
03:52 -!- shoeb [0e8b7204@gateway/web/freenode/ip.] has joined #mlpack
03:54 < shoeb> Hello,
03:55 < shoeb> I subscribed to mailing list thrice but i never got confirmation email. PLease help !
03:58 < rcurtin> shoeb: make sure it didn't end up in your spam folder or something?
03:58 < rcurtin> let me check postfix logs to see that it went out... what email did you use?
03:59 < shoeb>
03:59 < rcurtin> Mar 9 11:59:43 knife postfix/qmgr[31331]: 2366F700035: from=<>, size=4064, nrcpt=1 (queue active)
04:00 < rcurtin> Mar 9 11:59:45 knife postfix/smtp[15829]: D4565700035: to=<>,[]:25, delay=0.86, delays=0.01/0/0.16/0.7, dsn=2.0.0, status=sent (250 2.0.0 OK 1489078785 h129si1217279vkd.253 - gsmtp)
04:00 < rcurtin> doesn't look like you did it three times, but I see that it sent you a message about 12 hours ago
04:01 < rcurtin> or actually I see now that was a posting attempt. what interface are you trying to use to subscribe? you should be able to just do it at
04:04 < shoeb> Thanks for the help. Hope it works . Before I used these interface only.
04:07 < rcurtin> sure, let me know if there are more problems
04:09 -!- shihao [407978c3@gateway/web/freenode/ip.] has joined #mlpack
04:09 < shoeb> How much time it will take to send confirmation email ?
04:11 < shihao> rcurtin: I try to add a new macro in 'param.hpp' : #define PARAM_ARMA_VECTOR_IN(ID, DESC, ALIAS) \ PARAM_VECTOR(ID, DESC, ALIAS, false, false, true)
04:11 < shihao> #define PARAM_VECTOR(ID, DESC, ALIAS, REQ, TRANS, IN) \ static mlpack::util::Option<arma::vec> \ JOIN(cli_option_dummy_vector_, __COUNTER__) \ (arma::vec(), ID, DESC, ALIAS, REQ, IN, !TRANS);
04:12 < shihao> I get a error:;
04:12 < shihao> Can you give me a clue about how to solve this problem?
04:15 < rcurtin> ah I think there is already a PARAM_VECTOR macro for a std::vector, maybe that is the issue; let me look at the gist
04:16 < rcurtin> ah sorry nevermind it seems that isn't the issue
04:16 < rcurtin> I should look at the gist first before guessing...
04:18 < rcurtin> take a look at param_data.hpp line 62
04:18 < rcurtin> there is a template struct here that says the passed type of an arma::Mat<eT> is a std::string
04:18 < shihao>
04:18 < shihao> This is the complete gist, sorry
04:18 < rcurtin> I think you will simply need to add one of those for arma::Col<eT>
04:18 < rcurtin> sorry that I did not point that out in the issue description
04:18 < rcurtin> I have to step out for a little while, I will be back later
04:19 < shihao> Sure, thanks!
04:19 < rcurtin> before I go though, to clarify
04:19 < rcurtin> the basic functionality of the code that's giving you a problem is that when we use boost::program_options,
04:20 < rcurtin> we have to tell it which type is used on the command-line for each option
04:20 < rcurtin> but these types can only be double, int, size_t, std::string, char, etc...
04:20 < rcurtin> there's no reasonable way to pass an entire data matrix on the command line
04:20 < rcurtin> therefore, there are these ParameterType template metaprogramming structs that are used to set the boost::program_options type of matrices (and serializable models) to std::string instead
04:21 < rcurtin> so the user passes the filename, not the actual data
04:21 < rcurtin> and then in HandleParameter() we take that filename the user passed and load the data
04:21 < rcurtin> I hope it all makes sense, I think this is some of the more convoluted code in mlpack
04:21 < rcurtin> a refactoring is coming with the automatic bindings but it will still be complicated
04:22 < shihao> Type is stored in tname in param_data, right?
04:23 < shihao> The command line system is way more complicated than I thought...
04:23 -!- kris2 [~kris@] has quit [Ping timeout: 256 seconds]
04:26 -!- shoeb [0e8b7204@gateway/web/freenode/ip.] has quit [Ping timeout: 260 seconds]
04:27 < shihao> It's like type conversion. convert mat type to a string type.
04:31 -!- Tash [71c187ab@gateway/web/freenode/ip.] has joined #mlpack
04:34 -!- vinayakvivek [uid121616@gateway/web/] has joined #mlpack
05:20 < rcurtin> shihao: kind of, yes, just the type conversion involves file I/O :)
05:21 < rcurtin> part of the reason it is so complex is because soon, the *_main.cpp files will be able to be built not only into command-line programs but also python bindings, and later, bindings for other languages also
05:32 < shihao> Got it!
05:35 < shihao> rcurtin: Currently I use PARAM_ARMA_COL_VECTOR_IN or PARAM_ARMA_ROW_VECTOR_IN since PARAM_VECTOR is already used, does it make sense?
05:48 < rcurtin> shihao: maybe simpler is just PARAM_COL_IN and PARAM_ROW_IN ?
05:51 < shihao> rcurtin: Looks better :)
05:52 < shihao> rcurtin: I noticed that some command line load lables as row vector and some load lables as col vector.
05:53 < shihao> rcurtin: I think it would be better if we can restrict lable file to be loaded as col vector.
06:10 -!- dhawalht [75dc78f2@gateway/web/freenode/ip.] has joined #mlpack
06:11 -!- dhawalht [75dc78f2@gateway/web/freenode/ip.] has quit [Client Quit]
06:11 -!- shihao [407978c3@gateway/web/freenode/ip.] has quit [Ping timeout: 260 seconds]
06:19 -!- deepanshu_ [uid212608@gateway/web/] has joined #mlpack
06:26 -!- Tash [71c187ab@gateway/web/freenode/ip.] has quit [Ping timeout: 260 seconds]
07:52 -!- thyrix [2d4c4a21@gateway/web/freenode/ip.] has joined #mlpack
08:44 -!- ironstark [~ironstark@] has quit [Quit: Leaving]
08:45 -!- thyrix [2d4c4a21@gateway/web/freenode/ip.] has quit [Ping timeout: 260 seconds]
09:07 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 260 seconds]
09:12 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
09:15 -!- vinayakvivek [uid121616@gateway/web/] has quit [Quit: Connection closed for inactivity]
09:52 -!- deepanshu_ [uid212608@gateway/web/] has quit [Quit: Connection closed for inactivity]
10:04 -!- adi_ [cb737672@gateway/web/freenode/ip.] has joined #mlpack
10:26 -!- adi_ [cb737672@gateway/web/freenode/ip.] has quit [Quit: Page closed]
11:07 -!- mikeling [uid89706@gateway/web/] has joined #mlpack
11:21 -!- govg [~govg@unaffiliated/govg] has quit [Ping timeout: 256 seconds]
11:28 -!- govg [~govg@unaffiliated/govg] has joined #mlpack
11:31 -!- vinayakvivek [uid121616@gateway/web/] has joined #mlpack
11:56 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 260 seconds]
12:01 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
12:21 -!- deepanshu_ [uid212608@gateway/web/] has joined #mlpack
12:28 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 240 seconds]
12:30 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
12:41 -!- sicko [~sicko@] has joined #mlpack
12:42 -!- ob_ [c585c56f@gateway/web/freenode/ip.] has joined #mlpack
12:42 -!- ob_ [c585c56f@gateway/web/freenode/ip.] has quit [Client Quit]
14:08 < sicko> rcurtin, Hello , I just wanted to clarify that when we talk about deterministic we mean programming every event that may occur and how to handle it right?
14:08 -!- clicksaswat [736306fe@gateway/web/freenode/ip.] has joined #mlpack
14:25 -!- clicksaswat [736306fe@gateway/web/freenode/ip.] has quit [Ping timeout: 260 seconds]
15:07 < zoq> mikeling: Have you seen my message and have you solved the issues?
15:11 -!- biswajitsc [uid216412@gateway/web/] has quit [Quit: Connection closed for inactivity]
15:13 -!- thyrix [2d4c4a21@gateway/web/freenode/ip.] has joined #mlpack
15:27 -!- mikeling [uid89706@gateway/web/] has quit [Quit: Connection closed for inactivity]
16:11 < rcurtin> sicko: I'm not sure what context you mean that in
16:11 < rcurtin> shihao: I think basically every method that needs labels uses them as a row vector, so I think that arma::Row<size_t> would be the right type to use
16:12 < sicko> rcurtin, ummm remember the critical sensors machine learning problem which i told you about a few days back?
16:17 -!- shihao [407978c3@gateway/web/freenode/ip.] has joined #mlpack
16:20 < rcurtin> sicko: hang on let me cache it back in
16:21 < rcurtin> if I remember right, the threshold approach was being referred to as "deterministic"
16:21 < rcurtin> I had thought, based on my understanding, that with the three sensors you had the approach would be something like
16:22 < rcurtin> if (sensor1 > threshold1 && sensor2 > threshold2 && sensor3 > threshold3) { detection! }
16:22 < rcurtin> (you could use || instead of && too)
16:35 -!- arunreddy [] has joined #mlpack
16:47 -!- thyrix [2d4c4a21@gateway/web/freenode/ip.] has quit [Quit: Page closed]
16:51 -!- arunreddy [] has quit [Quit: WeeChat 1.4]
16:52 -!- arunreddy [] has joined #mlpack
17:10 < arunreddy> rcurtin: Thanks for your comments. I will work on them and will get back to you.
17:24 -!- tejank10 [75cc9e18@gateway/web/freenode/ip.] has joined #mlpack
17:27 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 258 seconds]
17:28 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
17:34 -!- shihao [407978c3@gateway/web/freenode/ip.] has quit [Ping timeout: 260 seconds]
17:57 -!- tejank10 [75cc9e18@gateway/web/freenode/ip.] has quit [Ping timeout: 260 seconds]
19:28 -!- Krish [0e8b5206@gateway/web/freenode/ip.] has joined #mlpack
19:56 -!- Krish [0e8b5206@gateway/web/freenode/ip.] has quit [Quit: Page closed]
20:11 -!- kris1 [~kris@] has joined #mlpack
20:12 < kris1> hi, i wanted to add a new cpp file to gym_tcp_api cmake file
20:12 < kris1> zoq: i had seen your gist and followed it.
20:13 < kris1> do i have to create any folder gym_tcp_q_learning_source and then add q_learning.cpp to it
20:13 < kris1> or how ??
20:16 -!- aashay [uid212604@gateway/web/] has quit [Quit: Connection closed for inactivity]
20:17 -!- emcenrue [49988f88@gateway/web/freenode/ip.] has joined #mlpack
20:18 < zoq> kris1: Hey, just put the q_learning.cpp into the current cpp folder. If you like you can put the file into another folder in that case you have to use /path/to/file/q_learning.cpp in 'set(gym_tcp_q_learning_source ..'.
20:18 < kris1> zoq: thanks, i resolved the problem.
20:18 < emcenrue> ayy, hello everyone, just wanted to say thanks for the GSOC 17 opportunity!
20:19 < kris1> zoq: when you have time can review my pr on NAG(Nestrov Acc Gradient). So i would have sufficient time to make the changes.
20:20 < zoq> emcenrue: It's going to be an awesome summer :)
20:21 -!- shihao [a2df10f9@gateway/web/freenode/ip.] has joined #mlpack
20:21 < zoq> kris1: I'll check the PR, probably in the next two hours.
20:24 < kris1> zoq: Thanks.....
20:39 -!- shihao [a2df10f9@gateway/web/freenode/ip.] has quit [Quit: Page closed]
20:44 < emcenrue> rcurtin, do you know if parallelized sgd been discussed in prior archives from:
20:48 -!- kris1 [~kris@] has quit [Ping timeout: 258 seconds]
21:18 < arunreddy> zoq:, rcurtin: I have a question regarding writing a test case for MomentumSGD
21:19 < arunreddy> The advantage with momentum update is the speed up, converges faster.
21:20 < arunreddy> For the simple test case as in
21:21 < arunreddy> Momentum update converges in 3M iterations. Whereas SGD with vanilla update doesn't.. can speedup be considered as a valid test case?
21:22 -!- deepanshu_ [uid212608@gateway/web/] has quit [Quit: Connection closed for inactivity]
21:28 < rcurtin> arunreddy: I know that typically momentum may converge faster, but do we have any guarantee of that?
21:30 -!- kris1 [~kris@] has joined #mlpack
21:31 < arunreddy> rcurtin: Theoretical or Numerical guarantee?
21:31 < rcurtin> I guess, it is a bad question to ask; I am pretty certain there is no theoretical guarantee
21:32 < rcurtin> a test like this might be somewhat risky, because it may be possible that without momentum SGD could converge faster for some problems
21:32 < rcurtin> however, I think it *might* be true that you could come up with a very specific and easy problem to minimize where momentum could help
21:32 < rcurtin> like a parabola or something like this, where with momentum it will certainly take fewer steps to converge
21:33 < arunreddy> Thats true, thats happening with GeneralizedRosenbrockTest.
21:33 < arunreddy> In the simple case it does.. I see vanilla SGD always failing with 3M iterations, and momentum sgd passes the test
21:34 < rcurtin> right, that is what happens empirically with the implementations we have now, but remember we are not guaranteed that those implementations are correct :)
21:34 < rcurtin> now, maybe you can come up with some simple test case where you have SGD and momentum SGD both take *two* iterations maximum
21:35 < rcurtin> and if the function being optimized is sufficiently smooth (I think that would be the condition) then momentum SGD would be closer to the solution
21:35 -!- vinayakvivek [uid121616@gateway/web/] has quit [Quit: Connection closed for inactivity]
21:35 < kris1> undefinined refrence to mlpack::Log::Assert (....). I don't understand why this error crops up
21:36 < kris1> the gist is here
21:38 < rcurtin> emcenrue: sorry, I did not see your message, I know it has been talked about, probably last february or march
21:38 < arunreddy> rcurtin: I agree with sufficiently smooth function, but i doubt looking at just two iterations would make any difference.
21:41 < rcurtin> yeah, I guess, I had thought two because the momentum should provide an additive effect to allow the second iteration to take a larger step
21:44 < rcurtin> I guess, maybe the rosenbrock test is ok, but be sure to test it many times to make sure the failure rate is low
21:45 < rcurtin> the random element in the test will be the order of points encountered by SGD / momentum SGD, so we want to make sure that the test will not fail for some orderings of points
21:45 < arunreddy> That's true, but finding such a function is so tricky. :)
21:46 < rcurtin> yes, I agree, it is not easy
21:46 < rcurtin> but definitely we want to avoid including any tests that can fail sometimes... I am sure you have already seen the havoc it wreaks, because it takes a lot of time to debug them
21:46 < rcurtin> and they can confuse users a lot
21:46 < rcurtin> I guess, a thing to keep in mind, is that it's basically impossible in most cases to test if an algorithm is completely correct
21:47 < rcurtin> instead, it's more realistic to simply have some number of tests that test to see that it is not completely wrong :)
21:47 -!- shihao [407978c3@gateway/web/freenode/ip.] has joined #mlpack
21:47 < arunreddy> Yeah. And the test works with SimpleTestCase. Not for Rosenbrock test..
21:49 < arunreddy> For Rosenbrock i see that the max number of iterations is set to 0. Why is it so?
21:51 < arunreddy> rcurtin: Line #50 in
21:53 < rcurtin> that means no limit on the number of iterations
21:55 < arunreddy> sorry, my bad. it is documented.
22:10 -!- trapz [~jb^] has joined #mlpack
22:10 < emcenrue> rcurtin, did anything end up happening off of this:
22:10 < emcenrue> hogwild seems legit :)
22:11 < emcenrue> this is in reference to the parallelized sgd btw
22:11 < emcenrue> for GSOC that is
22:11 -!- trapz [~jb^] has quit [Client Quit]
22:13 < rcurtin> emcenrue: no, there was never any PR
22:13 < emcenrue> :(
22:13 < rcurtin> I have heard from other people who are interested in implementing hogwild too but I am not sure if or when I'll see a contribution there
22:13 < emcenrue> (but good for me lol)
22:13 < emcenrue> thank oyu
22:14 < zoq> kris1: You have to link against mlpack; You can modify the CMAKE_CXX_FLAGS in the CMake file or adapt the CMakeLists.txt file from the nes repo which provides a simple cmake file for mlpack. I can send you the modification once I get back.
22:16 -!- trapz [~jb^] has joined #mlpack
22:18 -!- trapz [~jb^] has quit [Client Quit]
22:18 < kris1> okay i looking online how to set up the CMAKE_CXX_FLAGS for linking an external library
22:21 < kris1> zoq: oh i got it now
22:31 < kris1> even thought i add the -lmlpack to the CMAKE_CXX_FLAGS with -L and -I options still the same error exists.....
22:32 < kris1> i don't know why but it still gets the mlpack from /usr/local/.....
22:35 -!- aashay [uid212604@gateway/web/] has joined #mlpack
22:51 < vivekp> I'm working on restructuring the implementation of SMORMS3 based on wrapper class idea but it looks like it will be fruitful only after PR #925 is merged
22:52 < vivekp> otherwise I'll just break travis build on SMORMS3 PR :)
22:52 < vivekp> Meanwhile, getting it into shape locally.
22:55 < arunreddy> vivekp: It is almost there. :)
22:56 < vivekp> great :)
23:12 -!- kris1 [~kris@] has quit [Quit: Leaving.]
23:47 -!- AndChat493044 [~AndChat49@2405:204:8009:9454:ba5e:b01c:502:e738] has joined #mlpack
23:48 < AndChat493044> Hi zoq
23:48 < AndChat493044> Cmaes is working
23:49 < AndChat493044> And now im writting code for supermario
23:49 < AndChat493044> Used the genome library of bang
23:50 < AndChat493044> I have 13*13+1 with 10 hidden and 5 outputs
23:50 < AndChat493044> So 1750 weight dimension covariance matrix
23:51 < AndChat493044> That the implementation would be fast enough ..
23:53 < AndChat493044> Coz fetching the values and then setting the weights in neural net with propagation calculation in floating point would be a problem
23:54 < AndChat493044> I think it requires some matrix multiplication soln..
23:58 < zoq> AndChat4930: Awesome, another reason to figure out what went wrong as I tested the NEAT code.
23:58 < zoq> AndChat4930: I see, I already did some performance improvements, but another idea is to use the ann code instead Bang's code for fixed network architectures, should be a faster since we don't have to figure out the innovation number after we changed some values. If you like you can open a PR and we can discuss over there?
23:59 < zoq> kris1: Probably because /usr/local/ comes before .. in your library search path.
--- Log closed Sat Mar 11 00:00:37 2017