02:02 < favre49> zoq: I am implementing multiple pole cart balancing right now

02:04 < favre49> In all our RL environments, we return the State as a arma::colvec. I was wondering if we could instead return an arma::mat where each column is the state of the ith pole, and the 0th column is the state of the cart

02:05 < favre49> If we want to return only a colvec, we could of course just keep appending the states of the next pole at the end of the colvec. I just thought an arma::mat would be somewhat more intuitive. Let me know what you think.

02:22 < mlpackuser100> Hi. Does anybody have any idea why NMFPolicy with CFType might be giving systematically low values?

02:27 < mlpackuser100> I figured it out, potentially, if anybody's interested.

03:03 < rcurtin> mlpackuser100: what do you mean by low values? like in the recovered matrices?

04:07 < rcurtin> sreenik: I think maybe the numeric_limits<> solution would be fine here, so long as you comment sufficiently to indicate that max() or nan() or whatever you use indicates that it's uninitialized

04:07 < rcurtin> if you need multiple values per key, you could use map<string, vector<double>>, then the length of the vector could indicate if it's initialized

04:07 < rcurtin> but if you have only one value for key, probably that idea would be slower than necessary

04:07 < rcurtin> hope that helps, I don't fully know the context though :)

08:21 < sreenik> rcurtin: Thanks. The context was regarding the json parser, where, for each layer type there are some default parameters in a map and there are a few user-specified params in another map that would update the default ones.

08:22 < sreenik> Previously there was no provision for checking if the user's input is valid, but now I am implementing that. Anyway, the approach zoq and you suggested would be good enough for this

08:23 < mlpackuser100> rcurtin: Low values are concerning the predictions given for a cf application (with NoNormalization), both on actual data and generated. Normalization policy dramatically impact results too.

08:26 < mlpackuser100> Certain normalization policies give systematically not too biased seeming results, like OverallMeanNormalization - but still highly inaccurate.

11:27 < sumedhghaisas_> KimSangYeon-DGU: Hi Kim. Sorry for the delay. There is NeurIPS dealine tomorrow and I have a paper which is still unfinished. I will get to the plot as soon as I can. :)

12:38 < zoq> favre49: We can use arma::mat, don't see an issue here.

15:15 < rcurtin> sumedhghaisas_: still 28.75 hours left ;)

15:50 < KimSangYeon-DGU_> sumedhghaisas_: Hey Sumedh, no worries. Please take as much time as you need :)

15:53 < KimSangYeon-DGU_> Best wishes for your work :)

16:57 < rcurtin> mlpackuser100: the rank of the decomposition can make a huge difference, as can the actual algorithm that's used for the decomposition--try some different ones (I have had good success with RegSVD in the past)

16:57 < rcurtin> sreenik: ah, got it, that sounds good to me :)

18:32 < Suryo> zoq: I've created a PR for the test functions. For now, I have included the ackley function. It would be great if you could tell me if it looks okay; if it does, then I'll program the rest.

18:32 < zoq> Suryo: Will take a look later today.

18:33 < Suryo> Apologies for the delay in this: I had messed up the branches of my fork for the development of PSO -- had commited one change to master and things we're syncing for a while. I got that resolved and now things look good at my end.

18:33 < Suryo> zoq: thanks!!

18:34 < zoq> No worries, glad you could figure it out.

18:34 < Suryo> zoq: also, how are we going to test these functions? As a part of the test runs of other optimization methods?

18:34 < Suryo> Let me know whenever you get time.

18:35 < zoq> Ahh good point, yeah for now let's use SGD or Adam?

18:37 < zoq> We could adjust the initial solution if SGD isn't able to find a solution in a reasonable time.

18:38 < Suryo> Understood. I was considering CNE if that could work.

18:39 < rcurtin> CNE can be super slow because it's zeroth-order

18:39 < zoq> That should work as well.

18:39 < rcurtin> actually I need to adjust the ensmallen tests because the CNE tests can take orders of magnitude longer than others

18:39 < zoq> good point

18:39 < rcurtin> but perhaps the function you are optimizing is more amenable to CNE, I don't know :)

18:40 < Suryo> rcurtin: that's the point I was trying to make

18:40 < Suryo> The ackley function is interesting

18:40 < Suryo> It's unlikely that a gradient-based method will be able to optimize it

18:40 < Suryo> Very likely to get stuck in a local minima

18:40 < zoq> In any case let's run the optimizer on the test like a 1000 times and see what the fail rate is

18:41 < rcurtin> yeah, for the Ackley function, I think you're right

18:42 < Suryo> So what we can do for the time being is treat these new functions as stubs and try them with SGD or Adam with good initial points, and as we build up CNE or PSO, test them with initial points that are far away from the actual global solution.

18:43 < Suryo> Does that sound reasonable?

18:44 < zoq> Sounds good.

18:44 < Suryo> Great!

19:44 < sreenik> How can I use constant initialization, since FFN<MeanSquaredError<>, ConstInitialization> won't work as this particular initialization requires an init value parameter?

19:49 < zoq> sreenik: Not sure I get the issue, ConstInitialization does have a default value.

19:50 < sreenik> I mean, say I want to assign a value of 30 to it

19:53 < zoq> FFN<NegativeLogLikelihood<>, ConstInitialization> model(NegativeLogLikelihood<>, ConstInitialization(30.0));

19:53 < zoq> or

19:53 < zoq> ConstInitialization initRule(30.0);

19:53 < zoq> FFN<NegativeLogLikelihood<>, ConstInitialization> model(NegativeLogLikelihood<>, initRule);

19:53 < zoq> Does that help?

19:53 < sreenik> zoq: Got it. Thanks :)

20:05 < mlpackuser100> rcurtin: Thanks! I've had good results with RegSVD too. The thing that's troubling me is that I haven't been able to get a single result with NMF that appeared to be even correlated with the data. I must be doing something wrong, right?

20:10 < mlpackuser100> Unrelatedely, how can one use mlpack do to knn (for cf) with pearson correlation? Right now I'm using RegSVD with a high learning rate and a low regularization coefficient and then doing PearsonSearch for the neighborhood search. Are there any other approaches I should consider?

21:01 < Suryo> zoq: thanks for your comments on PR#117. I'll fix everything that you've pointed out and get on with the rest.