10:44 < nilay> zoq: Hi, if the input is represented as RGB, RGB, here then it will also make a difference for when U, and V are calculated?

10:54 < nilay> and regarding the api, do i inherit the structured_forest ( we could rename this the feature_extraction class) class and write the discretize function and other functions, because the data calculated in feature_extraction will be used in all the other classes?

11:30 < zoq> nilay: U and V is independent from the data representation.

11:30 < zoq> Since the discretize function is only used in the structured tree class, I think it makes sense, to implemented the function inside the structured tree class. Also, do you think we need another class for the feature extraction, it would be fine for me to leave it inside the StrcuturedForest class.

11:30 < nilay> i think we can make separate class for feature extraction and inherit it in our main class

11:31 < nilay> otherwise in a single file there'll be too many functions

11:32 < zoq> We try to avoid inheritance: https://github.com/mlpack/mlpack/wiki/DesignGuidelines#inheritance, but what we could do here is to instantiate a feature extraction object or make the methods static.

11:34 < nilay> ok then i think we can instantiate an object and do this. writing everything in one class does not seem a good idea to me

11:35 < zoq> okay, sounds good

11:37 < nilay> zoq: what i was saying in reference to rgb2luv was that if in python codes xyz matrix data is represented as rgb, rgb, ... and in our matrix it is as rrrrr... ,gggggg, . bbb, then we cannot use how they have calculated U and V

11:47 < zoq> The difference here is that we multiply each element in channel 0 and 1 with a single scalar v(0) = xyz(0) * ... . In the coordinate transformation case, we use the dot product, which uses (r * a0 + g * a1 + b * a2) so the data representation is important.

12:02 < nilay> also i tried adapting the input so that rgb value at (0, 0) is (0.2, 0.2, 0.2) but it still didn't clear the test

12:03 < nilay> src = N.array([[[0.2, 0.2, 0.2], [0.1,0.1,0.1], [0.2,0.2,0.2]], [[0.1, 0.1, 0.1], [0.0,0.0,0.0], [0.1,0.1,0.1]], [[0.0, 0.0, 0.0], [0.1,0.1,0.1], [0.2,0.2,0.2]]], dtype = N.float64 )

12:03 < nilay> this is the adapted input

12:03 < zoq> Okay, do you get the same results for xyz as the reference code?

12:04 < nilay> no

12:04 < nilay> i compared xyz only

12:06 < zoq> is the first value correct?

12:08 < nilay> yes

12:10 < zoq> hm, okay, can you show the the updated code and the updated input?

12:11 < zoq> It might take a while for me to take a look at the code.

12:11 < nilay> i just changed the input to this and compare manually the xyz values

12:11 < nilay> haven't changed anything much

12:12 < zoq> you updated the xyz transformation xyz.slice(0)(i) = 0....?

12:12 < nilay> yes that i did

12:13 < zoq> okay

12:14 < zoq> I get back to you once I have time to look at it, sorry that I can't take a look at it right now.

12:14 < nilay> zoq: no problem, i will work on the next tasks meanwhile. :)

13:59 < zoq> nilay: Do you get the same output: https://gist.github.com/zoq/ba817112a6dffe787cd64466ad88f326

14:01 < nilay> zoq: yes

14:02 < zoq> okay, great, remember armadillo is column major: so [0.1900898 0.2 0.2177832] is the first column, [ 0.0950449 0.1 0.1088916] the second row from the python matrix is the second column of the armadillo matrix since python represents the matrix as RGBRGB, it's even harder to see that the matrix is the same.

14:02 < zoq> So, what you could to here is that you check visually that the matrix is the same, and use armadillo output as a reference.

14:06 < nilay> zoq: ok yeah, so the test was passing all this time :P