14:38 < marcus_zoq> "We require OpenMP now." ... interesting

14:42 < naywhayare> well, that's not quite true yet

14:42 < naywhayare> it's commented out for now :0

14:42 < naywhayare> * :)

14:42 < naywhayare> but I am experimenting with making the tree traversals use OpenMP

14:42 < naywhayare> so far I have some speedup

14:43 < naywhayare> I also have some OpenMP implementations of things like k-means that were done a few years ago for some class projects by other Georgia Tech students that I haven't worked in yet

14:43 < naywhayare> if you think there is a better alternative to OpenMP, then we could use that instead, but it seems like the easiest way to do shared-memory parallelism

14:46 < marcus_zoq> ah, nice, I haven't really thought about parallelism ...

14:46 < naywhayare> yeah, it's not something I often consider... thinking about serial tree algorithms is hard enough :)

14:46 < naywhayare> but I proposed to implement parallel tree traversals for my thesis, so I have to do it...

14:47 < naywhayare> I will be implementing a distributed (many-node) tree traversal, too, but I am not sure how or if that fits into mlpack

14:48 < conrad_s> hi ryan, it's been a long time since I used IRC

14:50 < naywhayare> conrad_s: hello! there are still some IRC users :)

14:51 < conrad_s> thought I'd check this out -- I've seen lots of svn activity on mlpack lately

14:51 < naywhayare> yeah, GSoC is coming to a close and there is a lot of activity

14:53 < conrad_s> just got your email about the differences between spop_min and spop_max. so it's no problem to use either version of the check? on first sight it seems to be bit of a difference between one check and the other.

14:54 < naywhayare> yeah, it should not be a difference, unless I am having a mental hiccup

14:55 < naywhayare> the termination condition '(stuff) <= index_of_min_val' and '(stuff) < index_of_min_val + 1' should operate identically

14:55 < naywhayare> since index_of_min_val is an integer type I can't see a situation where the two conditionals aren't equivalent (except an overflow situation, which shouldn't happen)

14:56 < naywhayare> but it is possible I have overlooked something trivial and am about to feel stupid... :)

14:59 < conrad_s> maybe my brain isn't working either -- it's a bit late here. I'll leave the code as is, and release arma 4.400 sometime tomorrow

15:00 < naywhayare> okay, sounds good. either way, it passes the 26 test cases I wrote, which cover both loops, so I think it's alright

15:00 < naywhayare> before tomorrow I will send you a minor documentation patch detailing the sentinel values for the sparse matrices which were confusing Dirk

15:01 < naywhayare> but I don't think I have anything else on my "high priority Armadillo" list. I looked through the code you committed for P.W. Dondl's batch sparse matrix constructor, and did not see any issues

15:01 < naywhayare> the memory allocation seems to be just fine

15:01 < conrad_s> ok, that'd be great. it may help other people interfacing with SpMat. Patrick Dondl is apparently writing a wrapper for CHOLMOD

15:01 < naywhayare> though I've not written tests for it

15:02 < naywhayare> ah, great! I have not been able to find any time to undertake something like that

15:02 < naywhayare> when he finishes it I will help take a look at it, though the lag time may be a few days to a few weeks :-\

15:03 < conrad_s> no problem. I'm not sure how it's going to work with certain parts being LGPL and other parts GPL.

15:03 < conrad_s> he mentioned that one possibility is to put the wrapper as a separate package on sourceforge

15:04 < naywhayare> only the "Supernodal", "Modify" and "GPU" modules are GPLed, so I don't know if he will be using those parts

15:04 < naywhayare> but if I know Tim Davis, those are the only useful parts of the code

15:05 < conrad_s> if GPL parts are being used, I'd prefer for it to be a separate package, so we don't confuse the armadillo message of "safe license". either way, having the wrapper will be useful.

15:05 < naywhayare> I agree

15:05 < conrad_s> you probably noticed that I added (diagonal) GMM code to armadillo

15:06 < naywhayare> yes, I noticed it a while ago, but didn't spend much time looking at it

15:06 < conrad_s> not meant to step on the feet of mlpack. the code has been laying around for quite a while, and a few folks at my work asked me to integrate it properly into armadillo.

15:08 < conrad_s> it was a very borderline case as to whether it should go into armadillo or not, as I don't want the library to start having its own urban sprawl

15:08 < naywhayare> yeah; I would see it as borderline too. we have a benchmarking system set up for mlpack that marcus_zoq put together, so at some point if I ever have time I may try to find a way to add Armadillo's GMM implementation to the mix of things that are tested

15:09 < naywhayare> the main issue is that that's diagonal GMMs, and we test full-covariance GMMs at the moment

15:10 < naywhayare> also the mlpack code for training diagonal GMMs involves the full-covariance EM algorithm and then a step that sets all non-diagonal entries to 0, so it's excruciatingly slow...

15:10 < naywhayare> the reason it's like that is because the abstractions we used made that the easiest way to do it. it sounds like actually the thing to do is just specialize to Armadillo's implementation in that situation

15:11 < naywhayare> I think I'll open a ticket in Trac so I don't forget...

15:13 < conrad_s> ok, so there is no real clash here then. the gmm_diag code uses OpenMP for k-means and the EM algorithm. the k-means implementaiton also uses robust statistics for the means. the EM algorithm uses the "log_exp_add" trick to prevent underflows/overflows. I haven't looked too closely at the GMM implementation in mlpack, so perhaps these "tricks" are already being used there.

15:14 < naywhayare> I know some of the mlpack code uses logs to prevent underflows and overflows, but I'm not sure if the GMM code does

15:14 < naywhayare> even if there was a clash, I wouldn't see it as a problem. in my opinion, more (competently written) implementations of algorithms is usually a good thing

15:15 < naywhayare> one of the things we noticed in our benchmarking adventures (which, I guess, is a pretty obvious observation in hindsight) is that the runtime of different libraries can wildly vary depending on the input dataset

15:15 < naywhayare> or, more specifically, the relative runtime of different libraries, as compared with each other

15:16 < conrad_s> yes, and the initial starting points can make a big difference in iterative algorithms like k-means.

15:16 < naywhayare> yeah; for our comparisons we try to make sure that the random elements of algorithms are removed

15:17 < conrad_s> the openmp stuff was a little bit tricky to get right, so feel free to adapt it into mlpack.

15:17 < naywhayare> yeah; I have been playing with OpenMP recently for use in the mlpack tree traversals, using the #pragma omp task construct

15:18 < naywhayare> what I've found so far is that the overhead of instantiating tasks is pretty high (at least with the standard OpenMP implementation which comes with gcc)

15:19 < conrad_s> openmp is actually pretty nice. I initially converted the code to use c++11 threads, but it turns out that it becomes a bit of a mess at link time. sometimes I wonder if gcc developers like to inhale various herbs while writing code

15:19 < conrad_s> *nice in terms of API

15:20 < naywhayare> haha, maybe they are believers in the Ballmer peak

15:20 < naywhayare> just with THC instead of alcohol...

15:21 < conrad_s> looking at things from a "big picture" point of view, and after experiencing C++ for many years, I'm starting to think that the language is unnecessarily complicated

15:22 < naywhayare> I agree, and each successive revision of the standard isn't making things any better

15:22 < naywhayare> at the same time, I have yet to find a language that lets me produce code that is as clean (for users) and fast as C++

15:22 < naywhayare> but the tradeoff is that if a user does something wrong, they get thousands of lines of errors...

15:23 < naywhayare> I decided to count the number of lines of errors I got while working on something yesterday... the issue was a misspelled function, I think. 130,000 lines of errors

15:24 < conrad_s> insane. you'd think the C++ committee would have come up with a solution to this by now. C++ does generate fast code, but productivity goes out the window as soon as low-level template metaprogramming is involved. it's C with lots of bits stuck on, but it doesn't really gel.

15:25 < conrad_s> I'm starting to look at the Rust language http://www.rust-lang.org/ which is still under development. so far their generics (templates) are rather rudimentary, but they have done a lot of other things right. compared to C++ it feels positvely modern.

15:26 < naywhayare> hm, interesting. I will have to take a look sometime

15:27 < conrad_s> it's really late here -- I better head off to sleep :)

15:27 < naywhayare> :)

15:27 < naywhayare> 'night

15:27 < conrad_s> night

15:27 < naywhayare> I'll have sent you an email with a minor documentation patch by the time you wake up

15:37 < naywhayare> andrewmw94: I took a look through the Rectangle tree code and have a few high level comments

15:38 < naywhayare> I cleaned up a lot of stuff with typedefs, in the RTreeSplit and RStarTreeSplit classes... it makes it look a lot less ugly :)

15:39 < naywhayare> but I noticed that RTreeSplit and RTreeDescentHeuristic are, in general, always used together. are there compelling situations where one would use RTreeSplit with RStarTreeDescentHeuristic?

15:39 < naywhayare> or, really, I guess I mean, could you do that? if in general you can't, then maybe we should merge the two classes for simplicity

15:40 < naywhayare> I have vague memories of having this discussion a very long time ago, though, so I seem to have a vague feeling that the answer is that you could arbitrarily combine split types with descent types

15:41 < naywhayare> oldbeardo: sumedh committed his changes to cf_main.cpp, so it should be pretty straightforward to add your regularized SVD implementation as an option now

15:46 < oldbeardo> naywhayare: okay, I'll have a look, I will certainly need your help for this, I don't have an idea of how executables work

15:46 < naywhayare> okay; maybe we can do it through email? I am going to get lunch in 15 minutes, then I have a lecture to attend, so I would be back at 1800 UTC

15:46 < naywhayare> which is probably a little late for you

15:47 < naywhayare> you can take a look at the program, though, it's pretty simple... just look at int main():

15:47 < naywhayare> it takes in the parameters, which includes the algorithm

15:47 < naywhayare> then runs CF with the given factorizer, and saves the output

15:48 < naywhayare> so I think all you will need to do is add another 'else if' statement and add the name of your factorizer, then call ComputeRecommendations appropriately

15:48 < naywhayare> or use Sumedh's "CR" convenience macro

15:48 < naywhayare> if you can also add a short blurb to the PROGRAM_INFO macro about what your regularized SVD implementation is, that would also be great

15:49 < naywhayare> the PROGRAM_INFO macro contains the text that the user sees when they type 'cf -h'

15:49 < naywhayare> I need to get Sumedh to add short descriptions of his algorithms there, too, so that a user knows what choices they have for the --algorithm parameter

15:50 < naywhayare> once you've made the changes, you can build it and test it with some dataset... something like 'cf -a "regularized_svd" -o recommendations.csv -i dataset.csv'

15:50 < oldbeardo> okay, by the way I just finished writing a code example for Reg SVD, I will commit the changes right now

15:50 < naywhayare> where "regularized_svd" is whatever name you used for the algorithm

15:50 < naywhayare> great, thanks!

15:51 < oldbeardo> naywhayare: I have a question about svn

15:51 < naywhayare> sure, go ahead

15:52 < oldbeardo> right now I have three modified files, two of which belong to QUIC-SVD containing the changes I sent to you yesterday

15:52 < oldbeardo> what if I want to commit the changes only from the third file?

15:52 < naywhayare> 'svn ci name_of_file_to_commit'

15:52 < naywhayare> you can specify multiple files like that too... 'svn ci file1 file2 file3 directory1/', etc.

15:52 < oldbeardo> okay, thanks

15:53 < naywhayare> sure, no problem

15:53 < oldbeardo> can I mention a message along with the commit?

15:55 < naywhayare> I don't know what you mean

15:56 < oldbeardo> no problem, I made the commit

15:56 < naywhayare> ah, ok

16:00 < oldbeardo> naywhayare: just curious, which class will you be attending?

16:00 < naywhayare> http://www.iith.ac.in/~subruk/4510.html

16:01 < naywhayare> I have a friend who moved to california instead of finishing his degree

16:01 < naywhayare> but now he wants to finish his degree, but he lives in california

16:01 < naywhayare> so he asked me to attend the lectures for him and record them

16:02 < naywhayare> most of it should be review (I read the Sipser book last year, so I think I'm familiar with the content), but I'm hoping maybe the instructor will talk about some interesting things I don't know :)

16:02 < oldbeardo> heh, how come this link is of an Indian institute?

16:02 < naywhayare> if not, I'm bringing interesting papers Google Scholar recommended to me to read while he lectures...

16:02 < naywhayare> I'm not sure. I think the instructor taught at Tech but has since left to IIT Hyderbad, it looks like

16:03 < naywhayare> I just found the first course website I could for that class

16:03 < oldbeardo> right

16:03 < naywhayare> anyway, I have to grab some lunch now...

16:04 < naywhayare> I will talk to you later. if you have problems with the CF modifications, feel free to send me an email and I'll respond to it once I get it, or leave messages in IRC or whatever works best for you

16:04 < oldbeardo> sure, see you tomorrow

19:57 < marcus_zoq> naywhayare: you were faster :)

19:59 < naywhayare> marcus_zoq: :) I was waiting on some runs to finish so I figured I might as well do something useful

20:03 < marcus_zoq> Hopefully the build is fine, It looks like he builds mlpack on windows ...

20:03 < naywhayare> uh-oh, I guess I should spend some time working with the Windows build slaves or something

20:04 < naywhayare> although Gilles Barges says he has it compiling fine under MinGW, though with a few changes and it's apparently a bit difficult to configure

20:08 < naywhayare> if you want to work with the Windows boxes I'll happily give you an account on the systems, but I would think remote desktop from Germany to Atlanta would be nightmarishly slow

20:11 < marcus_zoq> yeah I think so, also I'm not really a windows user, but maybe It it worth a try

20:12 < naywhayare> ok; I'd need an IP to add an IP exemption from, though

20:12 < naywhayare> leaving a windows box open to rdesktop from any IP is a bad idea...

20:14 < marcus_zoq> Okay, in this case I need to tunnel the connection through another server :) maybe you can add two ip's so I can test which one has the better route?

20:15 < naywhayare> yeah, that's just fine

20:28 < marcus_zoq> I guess you need a ipv4 addresse, at home I don't have a static ipv4 addresse :(

20:29 < naywhayare> I can do ipv6 too

20:29 < naywhayare> ...I think

20:29 < naywhayare> I know Windows supports it, at least...