00:01 < Mina> Great! Thanks for your time and help. Will get back when I have some background of the codebase.

00:02 < zoq> Sounds good.

00:53 < ShikharJ> zoq: A little help regarding (https://github.com/mlpack/mlpack/pull/1204#issuecomment-371387490) please? Or if you could tell me what should be my approach to debugging these types of errors, it'd be great as well.

01:27 < zoq> ShikharJ: Ah sorry, I missed to answer to that one, let me know if what I said helps.

03:06 < ShikharJ> zoq: Thanks! That worked.

03:57 < travis-ci> ShikharJ/mlpack#101 (GAN - a33460b : Shikhar Jaiswal): The build has errored.

03:57 < travis-ci> Change view : https://github.com/ShikharJ/mlpack/compare/083723ea1d0c...a33460b06364

03:57 < travis-ci> Build details : https://travis-ci.org/ShikharJ/mlpack/builds/352158795

13:59 < zoq> rcurtin: Hey, can you checkout the latest version of mlpack.org, hopefully the last commit resolves the style issue.

14:18 < manish7294> zoq: rcurtin: Is it okay to have proposal in pdf format? It was problematic for me to use google docs as my proposal contains a bunch of mathematical equations, so I preferred using LATEX.

14:23 < zoq> manish7294: Sure, google docs is just an suggestion.

14:38 < rcurtin> zoq: sorry, I should have pulled that earlier

14:39 < zoq> rcurtin: No worries.

14:40 < rcurtin> I'll re-run the doxygen generator and we can see if it works right, hang on

15:17 < namratamukhija> hi, I'm working on writing tests for approx KFN method. I went through the tests written for the KFN method. I was considering moving forward in a similar manner, and wanted to be sure if I'm right. Since, mlpack doc says that approx kfn methods are just fast replacements of kfn method, a reasonable way to check for correct results would be to compare results of KFN method(naive) and approx KFN methods(ds and qdafn) on a synth

15:18 < rcurtin> namratamukhija: the goal of the bindings tests is not to test the correctness of the ApproxKFN program but instead to ensure that all of the options being passed are handled reasonably

15:18 < rcurtin> I'd suggest that you take a close look at the other bindings

15:19 < rcurtin> *er, sorry, I mean, I'd suggest that you take a close look at the other binding tests that have already been merged

15:27 < namratamukhija> rcurtin: Thanks for the response. I'll look at other binding tests.

16:42 < zoq> rcurtin: The style is correct, looks like the author annotation failed, will take a look into the issue.

16:50 < rcurtin> zoq: I don't see any output indicating any failures

16:51 < rcurtin> I can chmod so that you can run the script directly on mlpack.org too if you like; I just need to set the group to www-mlpack and make sure group can modify everything

16:51 < zoq> Sounds good, perhaps some path is wrong, but it worked before, so not sure.

16:54 < zoq> https://github.com/mlpack/mlpack.org/commit/347f19b841e4157772463891904d0b218650fc95 the commit messages "says something about fix path for annotator", but I can't see any changes in that direction, maybe that is an indicator.

16:58 < rcurtin> zoq: you're right, I am looking into it

16:59 < zoq> I can take a look, no problem.

17:00 < rcurtin> well, I can't see any change that I made

17:00 < rcurtin> but I can also see that the author annotator did work properly for mlpack-2.2.5 and other versions where I rebuilt the documentation

17:01 < rcurtin> it's possible that I did not check in the changed build-documentation.sh and the change got overwritten when I updated (but I would have expected git to ask me to merge...)

17:01 < rcurtin> since any 'git status' in that directory is usually very very large because the generated doxygen output is stored in the repo

17:03 < rcurtin> ok, I think I see what the change is; the tutorials directory to the annotator is wrong

17:03 < zoq> hm, strange, have only checked the nightly docs

17:03 < rcurtin> it was $docdir/*/tutorials/, it should be $srcdir/doc/tutorials/

17:03 < zoq> ah

17:03 < rcurtin> let me try rerunning the script and let's see if that works; if so I will check in the change

17:03 < rcurtin> I remember changing that before; not sure how I overlooked checking it in

17:04 < zoq> thanks for looking into the issue

17:06 < rcurtin> sure, sorry that I forgot to check it in

17:07 < rcurtin> I'm rerunning the build now; I'll let you know when it's done

17:07 < zoq> great, thanks

17:29 < Rahul_> Hi everyone. Am Rahul Vigneswaran, a mechanical engineering undergrad with a love for machine learning. I have made a project proposal for the robotic arm idea for GSOC'18. This is my first time in GSOC and community coding. Kidnly help me out.

17:31 < zoq> Rahul_: hello, the application phase is open, so please feel free to submit the application.

18:36 < ckeshavabs> Hello everyone! My name is Chenna Keshava. I am interested to contribute for the reinforcement learning algorithms part in the mlpack library

18:36 < ckeshavabs> And I have a few queries regarding the same

18:37 < ckeshavabs> The specified paper makes frequent references to this paper - Mnih, K. Kavukcuoglu, D. Silver, A. A. Rusu, J. Veness, M. G. Bellemare, A. Graves, M. Riedmiller, A. K. Fidjeland, G. Ostro- vski, S. Petersen, C. Beattie, A. Sadik, I. Antonoglou, H. King, D. Kumaran, D. Wierstra, S. Legg, and D. Hassabis. Human- level control through deep reinforcement learning. Nature, 518 (7540):529–533, 2015.

18:38 < ckeshavabs> But the implementation of DQN in the last GSoC summer by ShantongZhang seems to based on this paper - Lin, Long-Ji. Reinforcement learning for robots using neural networks. No. CMU-CS-93-103. Carnegie-Mellon Univ Pittsburgh PA School of Computer Science, 1993.

18:39 < ckeshavabs> I gathered this from one of the comments from zoq on a PR in github - https://github.com/mlpack/mlpack/pull/1001

18:40 < ckeshavabs> so for efficient illustration of the advantages of the new proposed paper, are we expected to change/add to the existing implementation of DQN?

18:42 < ckeshavabs> Also, The original DQN paper by Mnih, et al. (2015) tests the algorithm on a set of 49 atari games. But we have very few environments to test the RL algorithms as mentioned in future work here - http://mlpack.org/gsocblog/deep-reinforcement-learning-methods-summary.html

18:43 < ckeshavabs> so are there any wrappers for using openai's environments in order to test the new Double DQN paper on? Or are we just expected to test them using the benchmark scripts in the mlpack repository?

18:47 < zoq> ckeshavabs: Ideally, this can be integrated into the existing framework, we could change the existing code to achieve that if that is necessary.

18:47 < zoq> ckeshavabs: This is two-fold, for the unit tests we can't test every RL method each time on every environment, so we just implemented a minimal set for the unit tests. For benchmarks, we could use https://github.com/zoq/gym_tcp_api which is a wrapper around the Open AI gym framework.

18:49 < ckeshavabs> ok, thanks for the clarification

19:35 < ckeshavabs> one other query regarding the double dqn paper: can I provide the visualizations of the learnings of different layers in the double DQN using t-SNE?

19:36 < ckeshavabs> this isn't provided in the original paper, but I felt it would be interesting for research purposes

19:38 < zoq> Adding t-sne is a neat idea, and I think this would fit great into the codebase, since there is this great tree related codebase.

19:39 < ckeshavabs> ok, thank you for the info