07:09 < mentekid> rcurtin: my results turned out to be similar to yours. In most cases some cutoff version or unique is faster

07:09 < mentekid> My data: http://pastebin.com/pPZ441PL My processing script (outputs matlab-ready input for visualisation): http://pastebin.com/jLRDr5D6

10:07 < zoq> nilay: Hello, if you have time take a look at: https://gist.github.com/zoq/6fdc43c959d71980ef8bf31088866da0

10:08 < zoq> nilay: I suggest we do the following basic steps:

10:09 < zoq> 1. Implement the-the functions to extract the features and the function to prepare the data e.g. to split the data we use to train the structured tree.

10:09 < zoq> 2. Implement the mapping function we need to train a single structured tree.

10:09 < zoq> 3. Go over to the actual training of the structured tree by using one of the existing mlpack implementations.

10:09 < zoq> After each step we write tests, to ensure the implementation does what we expect.

10:10 < zoq> nilay: Does this sound reasonable?

10:20 < nilay> zoq: Hi, I looked at the interface.. I still have doubts in the details, the details that paper doesn't tell so explicitly.. Do you look fully at the python implementation for this?

10:23 < zoq> nilay: yes, I definitely left out some functions, participial in the StructuredTree class.

10:23 < zoq> nilay: There is no problem to add function on the way.

10:25 < nilay> zoq: ok. but for example what do SelfSimilarityFeatures() and RegularFeatures do. .

10:27 < zoq> nilay: Extract the features given an image and a set of locations ("Inspired by the edge detection results of Lim et al.,

10:28 < zoq> we use a similar set of color and gradient channels [...] resulting in 7228 total candidate features per patch").

10:30 < nilay> zoq: also i have doubt in the following: once we have a 16x16 structured label. do we generate binary vector z for each tree by randomly taking entries from it.? and how do we store edge map information at the leaves. then we would have to map back from Z to Y?

10:30 < zoq> nilay: Lim et al. divides the features into self-similarity and regular features.

10:35 < zoq> nilay: hm, let me take a look

10:38 < zoq> nilay: So, as I see it we don't have to map back from Z to Y, we can just use Z as edge map, and that is basically all we need.

10:38 < zoq> nilay: and yes, we we train each tree with random samples

10:39 < nilay> zoq: so from 16x16 patch i take randomly 16 pixels. and find z in between them. and this i do for each tree separately for this patch only.

10:40 < nilay> zoq: and then similarly for the next 16x16 structured label..

10:42 < zoq> nilay: Almost, you take x random locations (x,y) from the image and extract a 16x16 patch at that location and for that patch you extract the features.

10:43 < zoq> nilay: ah, you are talking about the labels right?

10:43 < nilay> zoq: yes the labels.

10:44 < zoq> nilay: you are right

10:45 < nilay> zoq: so now we have this intermediate mapping z, which are now are input data points. and the features, we find from some other method (lim et. al.).. how can this be possible?

10:45 < nilay> because normally i have a n dimensional data point. and i have n features (corresponding to each dimension) for that data

10:49 < nilay> zoq: the whole point of converting structured labels Y to intermediate mapping Z is, so that we can use points in Z as the input data points to our random forest.

10:50 < zoq> nilay: yes, right, I'm not sure I get your point.

10:50 < zoq> At the end, you are going to train a single tree with some input features and the coressponding labels.

10:52 < nilay> zoq: i am saying, take a point z from Z. now dimension of z should be the number of features we have.

10:52 < nilay> is this wrong?

10:53 < zoq> nilay: you are right

10:55 < nilay> zoq: so, i have my data points in a 5 dimensional space Z. and my features are calculated by lim.. as some 7228 total candidate features per patch.. how is this possible

10:56 < nilay> zoq: because we calculate z as a binary vector separately. and we calculate our features separately. this does not make sense.

11:01 < zoq> nilay: You always have to use the same location for the feature extraction as for the binary edge map. You can't just take a random sample of the feature space and a random edge map as label.

11:01 < zoq> nilay: Thats what the prepare_data function does.

11:02 < zoq> nilay: ftrs and lbls are samples from the same location

11:05 < zoq> nilay: I'm not sure we have to replicate this pos_loc and neg_loc block, It should be sufficient to use a uniform distribution.

11:32 < nilay> zoq: i think i understand now.

11:39 < zoq> nilay: So I think it would be a good idea to start with the feature computation. So extract 7228 features given an image and a set of locations.

11:53 < nilay> zoq: ok

15:23 < mentekid> What would be the process for compiling mlpack with a different compiler? For example I have g++ but now I'm installing the Intel g++ compiler student edition - how can I specify which compiler make should use (is there such an option?)

15:23 < mentekid> Intel c++ sorry

15:26 < rcurtin> cmake -DCMAKE_CXX_COMPILER=/path/to/icc

15:26 < rcurtin> I think that's all that's necessary

15:26 < rcurtin> the CMake output will tell you if it's been specified correctly, since it prints the compiler that is being used

15:30 < rcurtin> mentekid: I was looking through your simulation results, one of the things that is confusing to me is that there doesn't often appear to be a big difference between the unique and find strategies

15:30 < rcurtin> like for miniboone tuned, find takes 6.63s whereas unique takes 6.58s

15:31 < rcurtin> but on my system with openblas find takes 16.86s and unique takes 3.89s

15:31 < rcurtin> is it possible that we are using different versions of armadillo or openblas or something, and this is responsible for the discrepancy?

15:32 < rcurtin> I am using Armadillo 5.200.1 with openblas 0.2.14-1

17:24 < mentekid> rcurtin: sorry for the late reply, just saw this

17:24 < mentekid> let me see what versions I am using

17:26 < mentekid> I have version 6 of armadillo, not sure how I can find the smaller indices

17:27 < mentekid> and blas 3

17:29 < mentekid> ah, armadillo 6.500.5

17:32 < mentekid> I don't understand how it could show such big differences though, this is significantly different in our systems

17:32 < mentekid> is it possible we're running different datasets?

17:32 < mentekid> I get all of mine from http://archive.ics.uci.edu/ml/index.html

17:33 < rcurtin> miniboone is about 130k points in 50 dimensions, right?

17:33 < rcurtin> that's the set I have

17:34 < mentekid> I have 49 dimensions, maybe I erased one thinking it was an index

17:34 < rcurtin> on the other system I ran benchmarks on, I used Armadillo 6, but no big runtime difference

17:35 < mentekid> but yeah 130k points

17:35 < rcurtin> one dimension different shouldn't make such a huge difference

17:36 < rcurtin> so I guess, I'm pretty confused why there is so little difference between the find and unique strategies on your system

17:36 < mentekid> yeah I found that weird too

17:37 < mentekid> I'm not sure how to find out which blas version I am using

17:37 < mentekid> i am looking for openblas but can only find cblas

17:42 < mentekid> I have to go for a while, I'll log back in later

17:49 < rcurtin> okay; you can find out what you are using with ldd /usr/lib/libarmadillo.so (or wherever libarmadillo.so is) and then figure out what the blas and lapack links are

17:51 < mentekid> Ah I can connect from my phone, so no problem :)

17:52 < mentekid> So yeah I don't understand why there's such a big difference

17:53 < mentekid> to be honest I didn't see it till you mentioned it though

18:07 < mentekid> Is your binary compiled with debugging/profiling on? I think mine had debugging off (I'll make sure). Could that be the difference?

18:15 < rcurtin> yeah, I compiled with -DDEBUG=OFF -DPROFILE=OFF

18:37 < mentekid_> hmm, let me recompile with that and run it, but I doubt that is it

18:37 < mentekid_> ah stupid phone stole my nickname