mlpack IRC logs, 2018-02-01

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

February 2018
--- Log opened Thu Feb 01 00:00:53 2018
01:06 -!- govg [~govg@unaffiliated/govg] has quit [Ping timeout: 268 seconds]
01:38 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 248 seconds]
03:47 -!- govg [~govg@unaffiliated/govg] has joined #mlpack
04:18 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
05:23 -!- vivekp [~vivek@unaffiliated/vivekp] has quit [Ping timeout: 240 seconds]
05:42 -!- vivekp [~vivek@unaffiliated/vivekp] has joined #mlpack
06:35 -!- pvskand [~skand@] has joined #mlpack
06:40 -!- pvskand [~skand@] has left #mlpack ["Ex-Chat"]
06:41 -!- pvskand [~skand@] has joined #mlpack
06:41 < pvskand> While running mlpack_knn --help I am getting the following error: mlpack_knn: symbol lookup error: /usr/local/lib/ undefined symbol: arma_H5T_NATIVE_LLONG
06:41 < pvskand> Is this a problem in armadillo?
06:55 -!- pvskand [~skand@] has quit [Ping timeout: 240 seconds]
07:00 -!- ImQ009 [~ImQ009@unaffiliated/imq009] has joined #mlpack
08:17 -!- pvskand [~skand@] has joined #mlpack
11:18 -!- pvskand [~skand@] has quit [Ping timeout: 240 seconds]
11:46 -!- rajiv_ [0e8ba202@gateway/web/freenode/ip.] has joined #mlpack
11:50 < rajiv_> Hello, I subscribed to the mlpack mailing list and recieved a mail "Welcome to MLPack(Digest Mode). But, when I tried mailing, I recieved a mail "Only list members can post to the list.". But, my email exists in the list. What should I do?
11:52 -!- pvskand [~skand@] has joined #mlpack
12:00 -!- hydro13 [~Thunderbi@] has joined #mlpack
12:00 -!- hydro13 [~Thunderbi@] has quit [Read error: Connection reset by peer]
12:18 < zoq> rajiv_: Hello, that's strange did you use the same mail as you subscribed?
12:20 -!- rajiv_ [0e8ba202@gateway/web/freenode/ip.] has quit [Ping timeout: 260 seconds]
12:28 < rcurtin> pvskand: that's an interesting one; did you happen to update (or remove) libhdf5 from your system in the time since you have built armadillo?
12:29 < rcurtin> those symbols are for the armadillo hdf5 wrapper, so I suspect either armadillo has been upgraded/replaced with a version that doesn't have HDF5 support enabled, or possibly the underlying hdf5 library and also the armadillo library have changed, or something...
12:30 < rcurtin> in any case a reconfigure/rebuild of mlpack is likely to fix it, but I am happy to help dig and figure out exactly what it was that happened
12:30 < pvskand> <rcurtin> : Let me check and get back to you.
12:32 < rcurtin> sure, no hurry, let me know what you find
12:42 -!- govg [~govg@unaffiliated/govg] has quit [Ping timeout: 248 seconds]
12:47 < zoq> rcurtin: seconds :)
12:58 < pvskand> <rcurtin> : which version of armadillo do you have?
13:00 < rcurtin> zoq: ha, I guess we were both thinking about it at the same time :)
13:01 < rcurtin> pvskand: not sure, it depends definitely on which system I am using that day :)
13:01 < rcurtin> typically I'll just install libarmadillo-dev from apt, but other times I want to test with a specific version so I'll build it in a specific directory then configure mlpack with -DARMADILLO_INCLUDE_DIR and -DARMADILLO_LIBRARY set to the location of the custom Armadillo
13:29 -!- rajiv_ [0e8ba202@gateway/web/freenode/ip.] has joined #mlpack
13:31 < rajiv_> Hi Marcus, as I recieved a welcome message, my email id has to be right
13:37 < zoq> rajiv_: Okay, I can't look into the settings, perhaps rcurtin could.
13:43 < rajiv_> Ohk... Thanks! It would be great if this issue is resolved. BTW, can I ask you about GSoC here?
13:43 < rcurtin> let me take a look in a minute, hang on
13:47 < rcurtin> rajiv_: I responded to your email, I hope it helps
13:51 < rcurtin> ok, I have more details on when masterblaster and all of the build systems will be moved; the schedule is currently that they will ship out the systems on 2/9 (next friday)
13:52 < rcurtin> the systems should be received in Tucson by the following Monday (2/12) and the team there is supposed to install them with high priority
13:53 < zoq> okay, so minimal downtime
13:53 < zoq> sounds good
13:53 -!- rajiv_ [0e8ba202@gateway/web/freenode/ip.] has quit [Quit: Page closed]
13:56 -!- rajiv_ [0e8ba202@gateway/web/freenode/ip.] has joined #mlpack
14:00 -!- rajiv_ [0e8ba202@gateway/web/freenode/ip.] has quit [Client Quit]
14:06 < rcurtin> yeah, hopefully they are actually to get it back online fast
14:07 < rcurtin> next week I will do a "reboot test" to make sure the systems come up cleanly
14:07 < rcurtin> $ uptime
14:07 < rcurtin> 06:07:17 up 162 days, 13:49, 2 users, load average: 0.00, 0.00, 0.00
14:07 < rcurtin> I guess I have a bad habit of letting systems go a long time without a reboot
14:07 < zoq> same here
14:13 < rcurtin> luckily with all the benchmarking systems I have iLO and iDRAC access so if they don't boot back up I have a console I can access
14:16 < zoq> Does iDRAC come as an extra card? Maybe they provide this as a standard on the board itself.
14:20 < rcurtin> I think it's on the board itself, but I'm not sure---iDRAC is the dell version, and I have actually never seen or touched the 5 dell servers (slake, savannah, scrooloos, gekko, skyfish)
14:21 < rcurtin> for the Sun systems (aunty, collector, ironbar) it's built into the motherboard (but Sun calls it something else, I think ILOM?); it's just an extra NIC you can put on the network
14:21 < rcurtin> so the way Symantec has these systems configured currently is that the 9 management ports (iLO/iDRAC/ILOM) are on the internal network and can only be accessed through the Symantec VPN
14:21 < rcurtin> which is fine, I can only imagine that there are tons of security flaws in the management software and putting them on the open internet would be a disaster...
14:22 < zoq> yeah, sounds absolutely reasonable
14:22 -!- govg [~govg@unaffiliated/govg] has joined #mlpack
14:32 < pvskand> <rcurtin>: I recompiled armadillo and mlpack and mlpack_knn -h has worked but bin/mlpack_test -t KNNTest isn't working
14:33 < pvskand> It says mlpack_test: command not found. This is strange!
14:38 -!- pvskand [~skand@] has quit [Ping timeout: 268 seconds]
14:39 < rcurtin> pvskand: did you just do 'make'?
14:39 < rcurtin> you have to specify to build the test (since it takes so long): 'make mlpack_test' (or 'make test' which builds then runs the test)
14:39 < rcurtin> if you have multiple cores definitely use 'make -jX' where X is the number of cores, that will speed things up
15:45 -!- Wrath_ [6acf952c@gateway/web/freenode/ip.] has joined #mlpack
15:57 -!- pvskand [~skand@] has joined #mlpack
15:57 -!- Wrath_ [6acf952c@gateway/web/freenode/ip.] has quit [Ping timeout: 260 seconds]
15:58 < rcurtin> pvskand: I left a few messages, you should check the logs if you haven't already :)
15:58 < pvskand> <rcurtin> : Yes I have checked them. I will let you know. :)
16:14 < pvskand> Yup working now :)
16:33 < ImQ009> Hmm, mlpack really doesn't like to be included along with Windows SDK
16:33 < ImQ009> I get flooded with macro redefinitions such as M_PI
16:42 < rcurtin> pvskand: great to hear
16:43 < rcurtin> ImQ009: the only thing I can think that would cause that issue is if including the following code after including the Windows SDK also causes the issue:
16:43 < rcurtin> #define _USE_MATH_DEFINES
16:43 < rcurtin> #include <cmath>
16:44 < ImQ009> Defining "_MATH_DEFINES_DEFINED" helps
16:45 < ImQ009> But still gotta use a pragma to suppress 'possible loss of data' warnings :P
16:45 -!- manish7294 [~androirc@2405:204:c185:d254:54bd:30bd:f922:e44] has joined #mlpack
16:46 < ImQ009> rcurtin, I have Windows SDK, Qt and mlpack. All of each I think are defining those macros. So yeah, kind of a pain
16:50 < rcurtin> ImQ009: the cmath behavior seems reasonable to me:
16:50 < rcurtin> so I am surprised that Windows (presumably) is defining M_PI and not _MATH_DEFINES_DEFINED
16:50 < rcurtin> if you like, we can patch prereqs.hpp to only define _USE_MATH_DEFINES when M_PI is not defined
16:50 < rcurtin> and that would fix the issue
16:51 -!- manish7294 [~androirc@2405:204:c185:d254:54bd:30bd:f922:e44] has quit [Ping timeout: 252 seconds]
16:51 < rcurtin> the 'possible loss of data' warnings are tricky; if I remember right these are all arma::uword -> size_t conversions, but arma::uword and size_t should actually be the same thing (unsigned 64 bit integer)
16:51 < rcurtin> so the warning is actually misleading I think
16:51 < ImQ009> Yeah, I've read the issue about it on github
16:51 < ImQ009> It is tricky indeed
16:51 < rcurtin> (assuming a reasonably recent version of Armadillo, which uses 64-bit indices by default)
18:51 < ImQ009> Hmm
18:51 < ImQ009> I'm having trouble extracting the last row (dimension) of a loaded dataset. I just get "requested size is not compatible with column vector layout"
18:52 < ImQ009> What I'm doing is: "arma::mat dataset; mlpack::data::Load("path.csv", dataset); arma::vec labels = dataset.row(dataset.n_rows - 1);'
18:53 < ImQ009> If I understand correcly the last dimension (in my case, labels) should be in the last row of the matrix
18:55 < ImQ009> I can transpose it and then get the columns
18:55 < ImQ009> Sorry if this is a simple question, I'm not familiar with this. :/
18:57 -!- pvskand [~skand@] has left #mlpack ["Ex-Chat"]
19:00 < ImQ009> Yeah, this is actually an Armadillo question. I'll find a better place to ask such questions, sorry
19:04 -!- witness [uid10044@gateway/web/] has quit [Quit: Connection closed for inactivity]
19:06 < ImQ009> I suppose it's because the returned row view is not contiguous in memory, so I can't make it to a vector. So I HAVE to transpose
19:45 < rcurtin> ImQ009: yeah, exactly
19:45 < rcurtin> Armadillo is column-major, so the points for a particular column are contiguous in memory
19:45 < rcurtin> however, you can do this:
19:45 < rcurtin> arma::rowvec labels = dataset.row(dataset.n_rows - 1);
19:46 < rcurtin> that will do an actual extraction of the row values from the non-contiguous 'dataset' matrix, but no transpose is needed
20:00 < ImQ009> rcurtin, oh, I see. I initially though it didn't work either at first, because I had tried it before and I was still getting the exception. But it turns out it was, because I was trying to do vec = rowvec
20:01 < ImQ009> Eitherway, thanks for assistance.
20:10 < rcurtin> sure, glad to help :)
22:14 -!- ImQ009 [~ImQ009@unaffiliated/imq009] has quit [Quit: Leaving]
23:25 -!- travis-ci [] has joined #mlpack
23:25 < travis-ci> mlpack/mlpack#3813 (master - a16363a : Marcus Edel): The build has errored.
23:25 < travis-ci> Change view :
23:25 < travis-ci> Build details :
23:25 -!- travis-ci [] has left #mlpack []
--- Log closed Fri Feb 02 00:00:54 2018