11:33 < Atharva> sumedhghaisas: Hi Sumedh, how do you think I should proceed in order to get ready for the VAE project proposal?

11:33 < Atharva> I have already solved some issues and have started to get comfortable with the codebase.

11:35 < Atharva> Do you think it will help if I implement a convnet using mlpack or should I experiment with generative models?

11:45 < sumedhghaisas> Atharva: Hi Atharva.

11:46 < sumedhghaisas> I think the project should focus first on working implementation of VAE

11:46 < sumedhghaisas> for this using feedforward network is enough as far as MNIST is concerned

11:49 < sumedhghaisas> training of VAEs is not difficult, the architecture must support sampling

11:50 < Atharva> I understand, so for now I guess I should get as familiar with the ANN codebase as possible.

11:50 < sumedhghaisas> best thing I would suggest is coming up with tentative API of the module

11:51 < sumedhghaisas> the API should support the basic necessities, like sampling from the latent posterior or prior

11:53 < Atharva> Okay, I will do all the research required and come up with a tentative API.

11:58 < Atharva> Also, will it help if I implement a neural network with mlpack and include the link in the proposal, or should I just focus on researching about VAE and working on the API?

12:09 < sumedhghaisas> Atharva: working ANN code will show that you are familiar with the ANN module and how to use it. That would be helpful. But also designing a robust API will also involve knowledge of how the current architecture works and how to use it efficiently...

12:10 < sumedhghaisas> a robust API will show your familiarity with whole MLPack

12:13 < Atharva> Thanks Sumedh! I will get back with updates about my progress.

12:13 < Atharva> Can you tell me when are you generally active on irc?

12:15 < Atharva> Can you share your email or should I just contact you on irc if I need to?

13:12 < sumedhghaisas> Atharva: Sorry for the late response. Stuck in the meeting.

13:13 < sumedhghaisas> my email is sumedhghaisas@gmail.com

13:13 < sumedhghaisas> please free free to msg me on IRC also... I will try to respond as quickly as I can

13:15 < Atharva> Thanks for the help, I will keep all this in mind. :)

14:44 < zoq> Atharva: We like to keep project discussions public, that way more people can jump in and provide feedback.

15:04 < robertohueso> Is it defined anywhere what methods,etc. a "RuleType" has to have?

15:12 < rcurtin> robertohueso: I thought that it was documented in one of the tutorials, but it should basically be BaseCase() and Score()

15:12 < rcurtin> you can take a look at one of the other existing RuleTypes to get an idea, or you can see the DualTreeTraverser classes and SingleTreeTraverser classes in src/mlpack/core/tree/ to see what methods they are expecting the RuleTypes to have

15:12 < Atharva> zoq: Okay, I understand. I will try to keep all the discussions public.

15:18 < robertohueso> rcurtin: Thanks :)

15:23 < rcurtin> sure, hope it helps---and if you find the documentation lacking, please feel free to make a note of it or improve it

15:23 < rcurtin> it's hard to predict what information is useful or needed for a new user or contributor sometimes :)

15:24 < dk97[m]> zoq: I have made a loss_functions folder inside the ann folder

15:25 < dk97[m]> It contains KL Divergence loss as of now.

15:25 < dk97[m]> I saw that the MSE and cross entropy loss are already implemented in the ann_layers folder...

15:25 < dk97[m]> Should I shift them to loss_functions folder?

15:26 < dk97[m]> Also, I think there are mistakes in the MSE function implemented in mlpack.

15:31 < zoq> dk97[m] Yes, let's move them, will take a look at the PR.

15:31 < zoq> dk97[m]: Abotu the issue, are you talking about the backward function?

15:32 < dk97[m]> yeah...

15:32 < dk97[m]> it should be the mean

15:33 < zoq> dk97[m]: I see, will have a look and fix it.

15:33 < dk97[m]> okay!

16:12 < moksh> @zoq sorry, I did not see that SARSA has been implemented in the documentation and might've missed it in the code. Really sorry about that. Could you suggest a RL algorithm that would be a good addition to the library?

16:28 < zoq> moksh: One idea is to take a look at the Simple Nearest Neighbor Policy; perhaps that is an option?

16:29 < moksh> @zoq Thanks a lot, I'll take a look and get back to you :)

16:30 < dk97[m]> zoq: did you have a read of the quantized fully connected layers?

16:30 < dk97[m]> If it is okay, I can implement the layer.

16:30 < dk97[m]> Here is the paper - https://arxiv.org/pdf/1512.06473.pdf

16:33 < moksh> @zoq are you talking about this https://openreview.net/forum?id=ByL48G-AW ?

17:47 < zoq> dk97[m]: Sounds like an interesting idea, so if you like to give this a shot please feel free.

17:48 < zoq> moksh: Yes, it's not as straightforward as e.g. policy gradients.

17:52 < zoq> moksh: So don't feel obligated, I think another great way to get familiar with the codebase is to do something similar as Eugene has done here: https://github.com/mlpack/models/pull/5

18:01 < moksh> @zoq: Okay. So you suggest I make a model using mlpack?

18:04 < moksh> Also, I recently came across this paper https://openreview.net/forum?id=SJJySbbAZ, which describes optimistic mirror descent for adam optimizer. Having tried it I can say it really improves the GAN training quite a lot. Would it be a good idea to implement this?

18:14 < dk97[m]> zoq: okay, thanks!

18:25 < ShikharJ> zoq: Can I please have a review of the Bilinear Interpolation PR? I'd like to get that merged as soon as possible.

19:02 < zoq> moksh: Regarding the model yes, regarding mirror descent, agree the paper is really interesting, so if you like to work on that instead, please feel free.

20:42 < travis-ci> ShikharJ/mlpack#92 (ResizeLayer - 2ad123d : Shikhar Jaiswal): The build has errored.

20:42 < travis-ci> Change view : https://github.com/ShikharJ/mlpack/compare/a946d183e829...2ad123dc0ffc

20:42 < travis-ci> Build details : https://travis-ci.org/ShikharJ/mlpack/builds/349474967

22:47 < ShikharJ> zoq: Thanks for the review. I wanted to talk a bit more on my GAN proposal. Do you have some time?

22:48 < zoq> ShikharJ: Can we do that tomorrow? Or if you like post the questions here and we will responde as soon as possible.

22:52 < ShikharJ> Cool. In my proposal I was planning on implementing StackGAN (provided enough time was left). But I am not sure which version of the paper would be of interest. The original publication just mentions about two GANs stacked upon one another, whereas the updated paper talks of setting up a tree-like network of GANs for high-resolution imagery generation. Do you think one should go for the latest technique, or otherwise?

23:10 < zoq> ShikharJ: StackGAN-v1 and StackGAN-v2 share the same main building blocks, however for me, it looks like StackGAN-v1 is somewhat easier to implement, and it might be helpful to start with StackGAN-v1; in case there is time left we could build StackGAN-v2 based on that experience. On the other side, I guess nobody is going to use StackGAN-v1 if StackGAN-v2 is implemented, but in my opinion, that's not an issue.

23:17 < ShikharJ> Hmm, thanks for your thoughts.

23:18 < zoq> At the end it's your decision, if you like v2, please feel free to go for it straightaway.

23:19 < zoq> I guess since it's a side project ("if there is time left") it's not super important if we miss the goal here.

23:21 < ShikharJ> Actually,it is one of those goals than I thought could be extended beyong the GSoC period, and that's why think StackGAN-v2 should be something we invest time in altogether.

23:35 < zoq> I think we shouldn't include something that is too ambitious, let's focus on the main goals; At the end, we have to pass/fail someone based on the work done during the summer.

23:35 < zoq> If you like the StackGAN-v2 idea, shift the focus on that part.

23:41 < ShikharJ> Sure, my main goals include implementing DCGAN and WGAN, but I'm also keeping a considerable amount of time as buffer because I'm not sure how long would the tuning and testing would take. Hence the additional goals, should the need for buffer time not arise in the first place.