00:01 < rcurtin> shrit[m]1: I found the error, but I don't understand it

00:01 < rcurtin> you have written in parse_command_line.hpp `for (auto it : parameters) { ... }`

00:02 < rcurtin> I found, by adding a destructor to ParamData and printing the memory address being destructed, that the `util::ParamData& d = it.second` being created in the loop was being *destructed* at the end of each loop iteration

00:02 < rcurtin> therefore, the CLI::App object still has a lambda that uses this now-invalid reference, hence the segfault

00:03 < rcurtin> now what I don't understand is *why* `auto` is inferring the wrong type here (and I have no idea what type it *is* inferring)

00:03 < rcurtin> however, this is why I like to avoid `auto` wherever I can, because of strange and unexpected behavior like this :)

00:03 < rcurtin> (auto is especially bad with armadillo, because armadillo uses the type system pretty rigorously and auto often infers the wrong types)

05:16 < kartikdutt18[m]> Hi, Run ./bin/mlpack_test -t TestName

05:22 < jonpsy[m]> Thanks!

11:00 < shrit[m]1> rcurtin Thanks, I never thought that auto might point to a wrong type. I will bring the old type defined here

12:22 < rcurtin> no worries, hope that that helps :)

13:31 < jeffin143[m]> How do we link a program against armadillo ?

13:32 < zoq> jeffin143[m]: clang++ test.cpp -std=c++11 -larmadillo

13:33 < jeffin143[m]> Thanks that works

14:12 < shrit[m]1> rcurtin: it is working when using the normal iterator

14:12 < rcurtin> awesome!

14:13 < shrit[m]1> Just to keep in mind I had already cahnged some iterator to use auto in the PrintHelp function I think, but it is working

14:13 < shrit[m]1> *changed

14:13 < shrit[m]1> I hope this will not rise an issue

14:15 < rcurtin> it might be good to change it to the "long form" instead of auto just in case some other compiler has a problem with it, but if it's working for your experiments, maybe not something to spend too much time on now

14:15 < rcurtin> (we could come back to it later)

14:17 < shrit[m]1> Ok, the only loop to get inside is the check for duplication, I do not know if CLI11 handle duplicates, But I will adapte this loop for CLI11

15:22 < shrit[m]1> rcurtin considering the duplicate in command line, why it is written, boost did not handle the duplicates at the time of writing?

15:22 < rcurtin> I think so, yeah---if it isn't needed for CLI11, feel free to nuke it :)

15:23 < shrit[m]1> I have tested the old boost program option, and it seems to detect the duplicated when commenting this part

15:23 < rcurtin> that code was originally written in 2010, so maybe many things have changed :)

15:24 < rcurtin> when the automatic binding system was built, I mostly just adapted what the boost::po code already did instead of investigating it or changing it

15:24 < shrit[m]1> Ok, I will show you the output of CLI11, I am afraid of special cases, but we can added later

15:25 < shrit[m]1> So it detects that -c added two times, and should only be added once

15:26 < rcurtin> yeah, that seems fine to me

15:47 < shrit[m]1> Perfect, I will move by effort on raw pointer on CEREAL

15:50 < rcurtin> sounds good---I suspect that the right way there is going to be managing to avoid serializing pointers where possible

15:51 < rcurtin> luckily most of our pointer-based structures are trees (which are acyclic), so the answer to "has this child been serialized yet" is easy to answer :)

15:51 < rcurtin> maybe we can make a shim that takes a raw pointer, wraps it in a weak_ptr<> or some C++ smart pointer (I'm not very familiar with those), and then serializes that

18:31 < KhizirSiddiquiGi> Hey @saksham189 . I was trying to complete the PR #1983 . In comments, you said the gradient part and numerical tests are left. I had few doubts about the gradient part already there. I was reading the paper Miyato et al, 2016, I couldn't understand the part you are using the `error` argument in `Gradient()`. How were you approaching the gradients? I would like to complete it that way preferably.

18:31 < KhizirSiddiquiGi> Thanks for helppp!! :)

19:20 < jeffin143[m]> @walragatver:matrix.org :

19:20 < jeffin143[m]> You still up ?

20:05 < KhizirSiddiquiGi> @saksham189 I will be a little more precise, the lines where you assign gradient as : ` gradient.submat(weight.n_elem, 0, gradient.n_elem - 1, 0) =

20:05 < KhizirSiddiquiGi> arma::sum(error, 1);`

20:05 < KhizirSiddiquiGi> Sorry for texting multiple times. :nervous:

20:09 < HimanshuPathakGi> @khizirsiddiqui in #1983 you need to implement a GradientfunctionTest like here https://github.com/mlpack/mlpack/blob/22e7c8e7d24c38c6837a0486fd0a45b5e2d7900c/src/mlpack/tests/ann_layer_test.cpp#L699 to complete that :)

20:11 < HimanshuPathakGi> I think also not sure about the gradient function is working fine or not you can pull that code and check whether it is working fine or not.

20:14 < KhizirSiddiquiGi> Yeah, I have pulled the code. Makes sense, I should just implement the numerical gradient test and see if it works.

20:14 < KhizirSiddiquiGi> But if it works I will still be left with gradient code part xD I didn't understand it properly. xD

20:14 < KhizirSiddiquiGi> Thanks for quick help!!

20:17 < HimanshuPathakGi> We can also give a review on that :

20:17 < HimanshuPathakGi> :)

20:17 < KhizirSiddiquiGi> Sure, I will put up a PR soon. :thumbsup:

20:18 < HimanshuPathakGi> :thumbsup:

20:19 < KhizirSiddiquiGi> btw, the `ann_layer_test.cpp` is around 3800 lines. won't it be nicer to create another folder and put individual layer tests there?

20:20 < KhizirSiddiquiGi> just a thought, my VS Code with intellisense crashed yesterday xD I have switched to vim now.

20:26 < HimanshuPathakGi> > btw, the `ann_layer_test.cpp` is around 3800 lines. won't it be nicer to create another folder and put individual layer tests there?

20:26 < HimanshuPathakGi> Ahh, can't say because adding another folder will be too overwhelming because right we already have many layers and maintaining that many files will be more troublesome this is my point of view but you should discuss it with others also.