00:21 < zoq> I could use arma::cube to get arma::mat to avoid the 'issue', but at another point I use Random from the existing GaussianDistribution class wich returns arma::vec.

13:06 < rcurtin> zoq: you are right, we did the change so that we could standardize on using rowvecs as labels

13:07 < rcurtin> so that the columns of a data matrix are the same shape as the labels, i.e. data is d x n and labels are 1 x n (instead of n x 1)

13:08 < rcurtin> ah sorry change 'labels' to 'weights' in what I wrote

13:09 < rcurtin> I see a couple of possibilities---we can add a utility function to turn a vec into a rowvec without any copying by using an advanced constructor

13:09 < rcurtin> we can templatize Evaluate() to take an arbitrary input type and assume it is a vector type of some sort

13:10 < rcurtin> maybe the first possibility there is the best, let me know what you think

13:41 < zoq> rcurtin: I see, you are right I could use memptr and an advanced constructor to solve the 'issues', not sure it's pretty, but I will test it.

13:41 < zoq> I think if we go for rowvec we should make sure we do this over the entier codebase, right now e.g. the SGDTestFunction or the ann code do not follow the concept.

13:43 < zoq> same for the RosenbrockFunction I guess, haven't checked sparse_svm etc.

13:46 < rcurtin> yeah, I thought that kirill opened issues to change everything in the library, but maybe there are some things that were missed

13:46 < rcurtin> do you think I should open an issue for that?

13:47 < rcurtin> I'm not sure what you mean about the RosenbrockFunction though, the idea was that when we have data (of shape d x n), any corresponding information about each point should be a row vector

13:47 < rcurtin> but the RosenbrockFunction is just a test function and I don't think it has to do with data, so I am not sure where a rowvec would fit there

13:49 < zoq> Ah right, I was talking about initialPoint.

13:51 < zoq> I'll, test the advanced constructor idea and open an issue if necessary.

13:55 < rcurtin> hmm, I'm not sure I follow---in this case initialPoint is just a starting point for optimization, not labels or weights or anything, so I don't think there is any need to change it

14:07 < zoq> The problem is, I use the initial starting point to initalize the population size, so in case of SGDTestFunction or RosenbrockFunction I can do something like:

14:07 < zoq> parameter(iterate.n_elem, size);

14:07 < zoq> parameter.col(0) = iterate.col(0);

14:07 < zoq> in case of logistic regression I would have to write:

14:07 < zoq> parameter.col(0) = iterate.row(0).t();

14:10 < rcurtin> oh, I see, you mean in the context of CMAES

14:10 < rcurtin> I believe the optimizers are all built to accept a parameters matrix of any 2-dimensional shape (so, a row vector, a column vector, or a matrix)

14:11 < rcurtin> meaning that if you want to optimize some function with CMAES that has a matrix-shaped parameters, then you would have to hold these with an arma::cube and that would be the only option

14:15 < zoq> yeah, right, using col would just be easier since I could use the output of Random from the GaussianDistribution class for each function.

14:15 < rcurtin> maybe to be more generic it should be something like:

14:16 < rcurtin> arma::cube populationParameter(initialPoint.n_rows, initialPoint.n_cols, populationSize);

14:16 < rcurtin> then call Evaluate(populationParameter.slice(index), functionIndex)?

14:16 < rcurtin> I am not sure if I have understood everything correctly there

14:17 < zoq> yeah, in this case I don't have to change any other function/class.

14:17 < zoq> have to step out, back later

14:19 < rcurtin> ok, talk to you later

16:02 < wiking> zoq around?

16:42 < rcurtin> wiking: I am here but I am not who you are looking for :)

17:22 < wiking> :)

17:22 < wiking> do you have any preliminary results that involves shogun's random forest?

17:22 < wiking> rcurtin, ^

17:27 < rcurtin> wiking: not at the moment, those scripts have not been run yet

17:36 < wiking> kk

18:50 < zoq> rcurtin: You are absolutely right, somehow I thought I could assume that the data is a single col which isn't true. But I think I can just use the advanced constructor to solve all problems.

18:51 < zoq> wiking rcurtin: I think we can just start the benchmark?

18:58 < rcurtin> zoq: sure, I don't have a problem with that... I should disable slake since I am using that for other testing right now

18:59 < zoq> rcurtin: Okay, let me start the benchmark

18:59 < rcurtin> ok, slake is marked offline