00:22 < rcurtin> Yashwants19: yep, on my list... still digging myself out of the email hole though

00:23 < travis-ci> robertohueso/mlpack#53 (pca_tree - 36e7b92 : Roberto Hueso Gomez): The build was fixed.

00:23 < travis-ci> Change view : https://github.com/robertohueso/mlpack/compare/45eba1f822f2...36e7b926a36d

00:23 < travis-ci> Build details : https://travis-ci.org/robertohueso/mlpack/builds/566724017

01:09 < favre49> zoq Hey! I had a doubt from the NSGA-III paper

01:10 < favre49> It's on page 5 of the paper

01:10 < favre49> hereafter, the extreme point (zi,max) in each (ith) objectiveaxis is identified by finding the solution (x∈St) that makes thecorresponding achievement scalarizing function (formed withf′i(x) and a weight vector close toith objective axis) minimum.

01:11 < favre49> I'm not sure what the achievement scalarizing function really is

04:31 < jenkins-mlpack2> Project docker mlpack weekly build build #59: STILL UNSTABLE in 6 hr 44 min: http://ci.mlpack.org/job/docker%20mlpack%20weekly%20build/59/

04:31 < jenkins-mlpack2> Marcus Edel: Update to XML version 2 (cppcheck).

07:46 < jenkins-mlpack2> Project docker mlpack nightly build build #405: STILL UNSTABLE in 3 hr 32 min: http://ci.mlpack.org/job/docker%20mlpack%20nightly%20build/405/

07:57 < zoq> favre49: Do you mean the extreme point decomposition (signal analysis) for the normalization step? (https://github.com/msu-coinlab/pymoo/blob/master/pymoo/algorithms/nsga3.py#L151)

12:02 < xiaohong> Is there anyone know why the CI failed. It seems that that I can build successfully in the local, but failed in CI test.

12:02 < xiaohong> https://travis-ci.org/mlpack/mlpack/jobs/566825747

12:03 < xiaohong> Not the test phase but in the build phase.

12:06 < zoq> xiaohong: Travis build against the minimal armadillo version mlpack supports (6.500.0), you use as_col which was introduced in 9.400

12:06 < zoq> xiaohong: Looks like you can do the same with arma::vectorise

12:08 < xiaohong> Oh, where I can find the armadillo doc of version 6.500.0?

12:10 < xiaohong> I find the old version change list in http://arma.sourceforge.net/docs.html#api_additions

12:10 < zoq> xiaohong: Right, that is what I use as a reference as well.

13:50 < ShikharJ> sakshamB: Toshal: Are you guys there?

13:51 < Toshal> ShikharJ: I am here.

13:55 < Toshal> Sorry I didn't responded earlier.

14:01 < ShikharJ> Toshal: Okay, I pretty much have no time to converse right now, so please leave your message. Can I get an update from where things were last time?

14:01 < ShikharJ> What all you did over the past week?

14:48 < sreenik[m]> zoq: I have a couple of things to point out regarding the FFN class. Firstly, as we had already discussed before, the 'network' variable is private and there is no getter method for obtaining all the layers (minor fix, should I open a PR?). Secondly, if I have a variable called 'layer' initialized as follows "LayerTypes<> layer = new Linear<>(20, 30)", is there any way to determine of what class type 'layer' is, like is it

14:48 < sreenik[m]> of type Linear<> or Convolutional<>, etc?

15:11 < zoq> sreenik[m]: If you can open a PR that would be great, about the type, maybe decltype helps? If not we could implement a trait class similair to: https://github.com/mlpack/mlpack/blob/master/src/mlpack/core/util/arma_traits.hpp

15:17 < sreenik[m]> Isn't decltype used in the function definition, I mean, my purpose is to identify the individual layers once I load an mlpack model so that I can translate them to torch layer by layer

15:18 < sreenik[m]> What I understood from the mlpack code is that it doesn't probably have provisions for it, but I was wondering if c++ provides a method to check that

15:20 < zoq> sreenik[m]: I see, what about std::is_same

15:21 < zoq> if (std::is_same<decltype(layer), Linear<> >::value) std::cout << "Linear\n";

15:23 < sreenik[m]> Okay let check that out

15:24 < sreenik[m]> *let me

15:35 < sreenik[m]> Thanks for that. It almost worked! However, what I have is equivalent to declaring **LayerTypes<> layer = new Linear(20, 30)**, which makes its type as LayerTypes<> instead of Linear<> and hence no inference is possible

16:10 < zoq> sreenik[m]: Only if you use new`?

16:26 < sreenik[m]> Yup, Linear<> layer(20, 30) works but that doesn't.Now the layers I obtain from the loaded FFN model are essentially of type LayerTypes<>, so that cannot be changed. I was reading something regarding pointers in stackoverflow, not sure if it can be of any help here https://stackoverflow.com/questions/17678913/know-the-class-of-a-subclass-in-c

16:33 < zoq> sreenik[m]: Let me test something.

17:19 < zoq> sreenik[m]: Looks like we would have to implement some function for each layer, that returns us the type ToString() comes to mind.

17:31 < sreenik[m]> zoq: Seems like it. Well, apart from each layer, are any changes necessary in any other file which is not a layer (eg: layer_types.hpp)?

17:32 < zoq> sreenik[m]: I don't think so, I guess in your case if a layer could return a string representation this would be enough?

17:33 < sreenik[m]> zoq: Yes.

17:34 < sreenik[m]> As a workaround is anyhing possible with boost's serializable methods (or whatever is used to store the layer representation in the file)?

17:36 < zoq> sreenik[m]: Maybe, let's take a look into that as well.

17:39 < sreenik[m]> Yup. Wouldn't be a robust fix but could save us a lot of time

18:02 < zoq> sreenik[m]: https://gist.github.com/zoq/595906a62690befce85e3935ccc84f9f works

18:10 < sreenik[m]> zoq: That's great! I'll quickly replicate it for the other layers I need...

18:26 < sreenik[m]> zoq: Another update. I'm so sorry I didn't notice this earlier, **cout << string(layer.type().name())** prints a string which has the layer stored in between. For example, printing this for the linear _no_bias layer I get this: "PN6mlpack3ann12LinearNoBiasIN4arma3MatIdEES4_EE", while printing the one for the linear layer gives me this: "PN6mlpack3ann6LinearIN4arma3MatIdEES4_EE". Amazingly enough, the digits tell us exactly

18:26 < sreenik[m]> how many characters the next word is, not sure what "PN" means though

19:10 < zoq> sreenik[m]: I think I read somewhere, that this doesn't work on windows.

19:10 < zoq> sreenik[m]: Not sure this is true.

19:17 < sreenik[m]> Oo. Just finished the extraction from the string. Someone using Windows might be able to confirm this. I'll just assume that the extraction works before someone confirms. If it doesn't work on Windows I guess I'll be doing what you mentioned earlier

19:18 < zoq> Wesreenik[m]: We can just open a PR and write a simple test for it.

22:31 < jenkins-mlpack2> Project mlpack - git commit test build #207: UNSTABLE in 47 min: http://ci.mlpack.org/job/mlpack%20-%20git%20commit%20test/207/

22:47 < rcurtin> sreenik[m]: unfortunately the name you have is a mangled name; different compilers may handle it differently so there is no guarantee it will look like what you showed

22:48 < rcurtin> maybe a better solution might be to add a member to each layer that has the name of the layer type... but I don't know how ugly that would be

22:48 < travis-ci> mlpack/mlpack#7673 (master - a8dd9f5 : Ryan Curtin): The build is still failing.

22:48 < travis-ci> Change view : https://github.com/mlpack/mlpack/compare/301c77d98432...a8dd9f530101

22:48 < travis-ci> Build details : https://travis-ci.org/mlpack/mlpack/builds/567139266