02:57 < travis-ci> robertohueso/mlpack#12 (mc_kde_error_bounds - bd964c6 : Roberto Hueso Gomez): The build is still failing.

02:57 < travis-ci> Change view : https://github.com/robertohueso/mlpack/compare/476da872ef67...bd964c637e53

02:57 < travis-ci> Build details : https://travis-ci.org/robertohueso/mlpack/builds/545537545

07:08 < jenkins-mlpack2> Project docker mlpack weekly build build #52: STILL UNSTABLE in 9 hr 21 min: http://ci.mlpack.org/job/docker%20mlpack%20weekly%20build/52/

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

11:01 < favre49> Some more compiler issues which I don't get https://pastebin.com/shrLLGZs

11:02 < favre49> The offending code: https://pastebin.com/zj6F6Ame

11:19 < zoq> Let's see

11:22 < favre49> Never mind, I was able to work around it by predefining the activation function for the XOR task instead of passing it as a template argument. Which way would be better, hough?

11:30 < zoq> Looks like the XORTask dosn't take a template argument: so <XORTask<LogisticFunction> isn't valid

11:31 < zoq> template<typename ActivationFunctionType> class XORTask { };

11:32 < zoq> but not sure you need the activation function inside the task?

12:42 < favre49> Ah i had modified the task to take activation function as a template argument. I did so because since Genome is templated, we have to define the activation function in the Evaluate() function now.

13:14 < zoq> I see, if you push the latest version, I can see if I can spot the issue.

13:14 < zoq> unless it#s already solved

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

13:32 < sakshamB> yes

13:33 < ShikharJ> sakshamB: Let's begin then? I have half an hour to spare right now.

13:33 < sakshamB> I’ll open a PR for Virtual Batch normalization by tomorrow. Just stuck on the numerical gradient test right now.

13:34 < sakshamB> Also I found a bug in the implementation of Backward() in BatchNorm Layer.

13:34 < sakshamB> will create an issue about that.

13:34 < ShikharJ> sakshamB: No worries there.

13:34 < ShikharJ> sakshamB: Yeah an issue should be better to point out a bug, and if we find it's viable, feel free to go ahead.

13:35 < ShikharJ> sakshamB: Though even I had found a bug in its implementation a while ago I think, not sure if it was Backward() or not.

13:36 < ShikharJ> Maybe I didn't check that thoroughly for further bugs.

13:37 < favre49> zoq: I just removed the template argument for now, so i could fix the other issues. Now i just have one last compile issue, which I can't really understand https://pastebin.com/NhdJLUXM

13:38 < ShikharJ> sakshamB: Do you think it makes sense to merge MiniBatchDiscrimination and Inception Score into a single PR? Or would you prefer that they were merged separately?

13:38 < favre49> I've pushed the current state of the code (it's a bit ugly at places though, I'll work on cleaning it now)

13:38 < ShikharJ> If I remember right, you had mentioned that one makes use of the other to form a valid test?

13:38 < favre49> When you get the time, please check out that compile issue

13:39 < sakshamB> ShikharJ: I don’t mind either way. Unless we need to test them together which would be easier if they were in a single PR.

13:39 < Toshal> ShikharJ: Hi, I am here.

13:41 < ShikharJ> sakshamB: Let's do that then, since these PRs aren't super big, it shouldn't be a lot difficult to review as well.

13:42 < sakshamB> ShikharJ: alright yes I think it would be easier to test and review by having them in a single PR.

13:42 < zoq> favre49: Can you add a default constructor to the ConnectionGene class?

13:43 < ShikharJ> sakshamB: Can you also elaborate n your Backward() in BatchNorm bug?

13:43 < sakshamB> yes I am in the process of creating an issue for it. will share the link.

13:44 < ShikharJ> sakshamB: Cool then.

13:44 < ShikharJ> sakshamB: Let's try and have those two in a single PR, I'll review and merge within the coming week.

13:46 < ShikharJ> Toshal: I have to apologize again, I couldn't find the time to review your comment on Generator Gradient routine.

13:47 < Toshal> ShikharJ: You don't need to apologize. It's fine I know you are quite busy.

13:47 < ShikharJ> Toshal: I'm pretty convinced of the GAN serialization though, I'm just trying to test that out by creating a dummy network, saving it and loading it back again on savannah. That would be the gold standard test for the PR.

13:48 < Toshal> Okay

13:48 < ShikharJ> Toshal: And what's the progress on getting savannah to work for you? Are you stuck somewhere there?

13:48 < Toshal> No it's working correctly.

13:48 < ShikharJ> Okay great.

13:49 < sakshamB> ShikharJ: https://github.com/mlpack/mlpack/issues/1923

13:49 < ShikharJ> sakshamB: Thanks, I'll take a look shortly.

13:49 < ShikharJ> Toshal: What's the progress on Weight Norm and Frechlet Distance?

13:50 < robertohueso> He :) I'm working on adding new features to an mlpack method, they require new parameters. Can I change the API of the method (change order of parameters and add new ones)? Am I supposed not to break any dependency users might have with mlpack?

13:50 < robertohueso> Hey*

13:50 < Toshal> ShikharJ: Weight Norm layer is completed.

13:51 < Toshal> I have added the gradient test.

13:51 < ShikharJ> Toshal: Okay, better to remove the [WIP] tag on the PR then :)

13:51 < Toshal> I will add the serialization test soon.

13:53 < Toshal> Okay I will remove it tommorow.

13:53 < Toshal> Regarding FID I will start working on it soon

13:54 < ShikharJ> Toshal: Okay cool, I'll approve the Serialization PR when I can get the networks running :)

13:54 < Toshal> ShikharJ: Great.

13:55 < ShikharJ> sakshamB: Toshal: You guys have got a lot of quality work done, and I wish to see that merged that in as soon as possible. Let's designate the coming week for that.

13:56 < Toshal> ShikharJ: Okay thanks.

13:57 < ShikharJ> sakshamB: Hmm, are you sure that BatchNorm is the only layer that fails that way?

13:57 < ShikharJ> By adding a Linear layer before the intended layer to be tested in the Gradient test?

13:58 < sakshamB> some of the layers already have a layer before them in the numerical gradient test.. while I have not looked at other tests so far

13:58 < sakshamB> ShikharJ: yes

13:58 < ShikharJ> Toshal: Feel free to log off for now. I'll review the label smoothing as soon as I get a chance.

14:00 < ShikharJ> sakshamB: Sorry? Is BatchNorm the only layer to fail? I didn't catch what you said yes to.

14:01 < sakshamB> ShikharJ: I haven’t tried other tests yet.

14:01 < sakshamB> I was working on VirtualBatchNorm and looking at implementation of BatchNorm layer

14:03 < ShikharJ> sakshamB: It might be in our interests to do that. If other gradient tests already have a layer before them, leave them be. But I guess a lot of them don't. If only a small bunch of those tests fail that would strengthen our hypothesis regarding BatchNorm, else there's a flaw in our logic.

14:06 < sakshamB> ShikharJ: hmm.. I am not sure what the flaw could be though

14:06 < ShikharJ> robertohueso: I think we have done that in the past, though not very frequently.

14:07 < sakshamB> maybe zoq might be able to tell https://github.com/mlpack/mlpack/issues/1923

14:08 < ShikharJ> sakshamB: Yeah, better to run the tests and report what you find.

14:09 < sakshamB> ShikharJ: anyways I think that for BatchNorm layer I was able to exactly find the bug in the implementation of Backward (because the paper has the equations for the derivative) and fix it.

14:09 < ShikharJ> robertohueso: What method are we talking about though?

14:09 < robertohueso> KDE

14:10 < ShikharJ> robertohueso: I don't see an issue with adding new parameters, though I'm not sure about re-arranging, probably better to ask Ryan about that :)

14:11 < ShikharJ> sakshamB: Please mention about that on the issue as well.

14:12 < sakshamB> ShikharJ: also I am having a doubt when finding the derivating of standard deviation wrt to the mean

14:13 < robertohueso> Maybe the best idea is to keep the old constructor and add a new one with all the new parameters :)

14:13 < robertohueso> Thanks ShikharJ! :D

14:13 < ShikharJ> robertohueso: Will all of the new parameters have default values for them?

14:15 < ShikharJ> sakshamB: Please mention your doubts on the issue? I'll have to leave and catch a bus to my workplace, and since it's gonna be a 40 minute ride, I think I can answer your questions from the phone.

14:15 < sakshamB> no its not regarding the batchnorm layer

14:16 < sakshamB> but for the virtualBatchNorm

14:16 < ShikharJ> sakshamB: Okay, maybe push your local code and then we can have a chat?

14:16 < sakshamB> ShikharJ: alright sounds good

14:18 < ShikharJ> robertohueso: If some of the parameters cannot have default values, the adding any new parameters will eventually break API. So better to do both adding and re-arranging if that's the case, else you could wait for Ryan to reply :)

14:22 < ShikharJ> sakshamB: Okay I'll be off for now. Please leave me a message and if you have further doubts :)

14:22 < sakshamB> ShikharJ: alright will do so

15:18 < favre49> zoq: Thanks, that was it. I fixed the compile and linking errors, I'll start testing and debugging now.

16:39 < jeffin143> lozhnikov : any suggestion for naming of CharSplit class ..?? I don't seem to find one :)

17:42 < rcurtin> robertohueso: re-arranging is fine, but let's keep the old constructor around with an mlpack_deprecated annotation and a note that it'll be removed in mlpack 4.0.0

17:42 < rcurtin> but yeah, I am agreed with Shikhar on this one; if you can manage to just add new parameters to the end, then we can avoid breaking the API :) if not, though, the idea above works

17:57 < travis-ci> robertohueso/mlpack#13 (mc_kde_error_bounds - 27a53c7 : Roberto Hueso Gomez): The build is still failing.

17:57 < travis-ci> Change view : https://github.com/robertohueso/mlpack/compare/bd964c637e53...27a53c735c11

17:57 < travis-ci> Build details : https://travis-ci.org/robertohueso/mlpack/builds/545842510

18:14 < favre49> Sorry to bother you guys again, but I have a runtime error from kmeans clustering I don't know how to debug : unknown location(0): fatal error in "NEATXORTest": memory access violation at address: 0x00000008: no mapping at fault address

18:14 < jeffin> Did u use..?? Map.at()

18:14 < jeffin> Method..??

18:14 < favre49> The function https://pastebin.com/cCpMgf0n

18:15 < favre49> jeffin: nope

18:16 < jeffin> The error is due to accessing of index which is out of bound or element which is not present

18:19 < rcurtin> favre49: you can try compiling with debug symbols (so with cmake this is the option -DDEBUG=ON) and then using gdb to trace where the error is

18:20 < favre49> rcurtin: jeffin: Thanks, I'll try that.

18:22 < jeffin> Did anyone here used cgal library..??

22:24 < gmanlan> rcurtin: hi, you there?

23:52 < gmanlan> rcurtin: let me know if have the chance to take a look at the python bindings - I left some comments, thanks!