00:37 < rcurtin> MystikNinja: that is the correct paper, be sure to look through the references also

00:53 < sonudoo> Hello everyone!

04:44 < manthan> @daivik, i was going through the irc logs and saw today about your concern for working on ANN for CLI. Actually I didnt start working on it as there were many people who had claimed the issue. And so i shifted my focus on pruning algorithms for decision trees.

04:45 < manthan> however, i will take up that issue after the pruning algorithm is in place

07:47 < manthan> Is there any specific reason that attention layer is not implemented but recurrent attention is implemented?

08:25 < karan_> Hello Everyone, My name is karan and i am a 3rd year graduate from ggsipu. I have a good experience with c++ and python. I Had been working with neural networks from past 1 month. I would like to contribute to Essential Deep Learning Modules. Would someone tell me about about the next steps please or help me connect with potential mentors.

08:52 < manthan> karan : this is a good place to connect to mentors. Also these might help http://www.mlpack.org/involved.html and http://www.mlpack.org/gsoc.html

13:46 < daniel__> Hey guys , this is Daniel Li from the University of Edinburgh. I have gone through the idea list and found the project of reinforcement learning quite appealing to me. I have been participate in coding competition for years and write fluent c++ python code. I 've also learned relevant courses and skills in ML and NLP. Currently I am setting up mlpack on my PC, and would go over the code base after that.

13:47 < daniel__> Hopefully I will submit the first version of my proposal over the weekend and solve some easy bugs on Github over that. Cheers.

13:54 < zoq> daniel__: Weclome, glad you like the idea, and let us know if we should clarify anything.

15:31 < yashsharan> Hello. I was going through the gym_tcp_api example and I am having trouble understanding that how are we importing the gym environment.Specifically in which file has the gym namespace has been declared?

15:36 < yashsharan> Also I had i doubt that if i'm trying to make my own RL model, how can i call this gym_tcp_api in my code?

15:42 < yashsharan> Nevermind,I just saw that mlpack already has methods for reinfocement learning available.Thanks anyway

19:02 < daivik> manthan: Sorry for the late reply, I think akhandait has already picked up the issue (he replied on the issue) - so you can maybe talk to him about collaborating on it

19:37 < farabhi> Greetings, everyone. Farabhi is here. I'm completing my Master in Data Science, really interested in contributing to MLPack trhough GSOC 2018. I have good background in math, specifically in convex functions and hermitian matrices. Naturally, I loved SDP and MVU ideas from the list. But also recently I took a class in high performance computing and studied benchmark profiling and C optimization interfaces a lot (OpenMP and MPI). So 'Al

19:39 < farabhi> 'Profiling for Parallelization' seem also attractive to me. My question to mentors: based on all requests and suggestions you saw from potential candidates recently, what would you suggest as the most promising/available projects of four. In other words, since I cannot choose myself, what would you say is the most important for MLPack community from the four I listed? Thanks in advance.

19:46 < rcurtin> farabhi: hello there

19:47 < rcurtin> each project on the list is important to mlpack, otherwise it wouldn't be on the list

19:47 < rcurtin> but the projects that will be chosen will be the strongest proposals across the projects, so I think you should not worry so much about which one you want to choose

19:47 < rcurtin> and instead focus on writing a proposal that shows you have a clear plan and understand the project and have a realistic timeline

19:51 < farabhi> rcurtin: sorry, the way I asked the question was confusing. I see that the number of people already committed to different topics. For example, MystikNinja is already looking at MVU. So I was curious if you think that any of those four are 'underrepresented', i.e. don't have potential contributors or have a small number compared to other ideas

19:52 < farabhi> Since, I'm equally interested in these four, I would gladly focused on the one that received least attention from others.

19:56 < rcurtin> farabhi: so, the list was actually cut off because of IRC line length limits, so I am not sure what the four projects are

19:56 < rcurtin> but what I will say is, it's hard to know how much attention each project will get before the application period is actually over

19:56 < rcurtin> I know for sure the deep learning modules project will get lots of applications because it always does, since it is in a popular field

19:56 < rcurtin> but still, at the end of the day, the strongest proposals are most likely to get the spot, regardless of the project chosen

20:10 < davidinouye> Does anyone know when/if the libmlpack-dev will be updated on in the apt-get repositories? Currently, using apt-get the version seems to be 2.0.2 even though the current stable version is 2.2.5.

20:12 < rcurtin> davidinouye: I think I filed an ubuntu bug asking them to update both libarmadillo-dev and libmlpack-dev, but it has not been done yet

20:12 < rcurtin> I agree, 2.0.2 is far too out of date

20:12 < rcurtin> you could send the maintainer an email (I think it is Barak Pearlmutter? not sure)

20:12 < rcurtin> but we are also going to release 3.0.0 very soon, and at that point I will push on the debian repo admins to get a new version in

20:13 < farabhi> rcurtin: got it, I think I misunderstood the selection process and now it's a bit clearer. Thanks!

20:14 < rcurtin> farabhi: no problem, glad to clarify. every organization does it differently :)

20:15 < davidinouye> rcuritin: Thanks for the info! Do you know if mlpack_det changed significantly in terms of speed or interface since 2.0.2? If not, I might just try to rework my python wrapper so that it doesn't require making mlpack from source. Thanks!

20:16 < rcurtin> davidinouye: hmmm, so if you are willing to build from source, you could build the new python bindings which have a det() function that has the same functionality as the command line

20:16 < rcurtin> maybe that is good enough, maybe not

20:17 < rcurtin> but I seem to remember mentioning that before to you actually (but my memory is hazy)

20:17 < rcurtin> I think there has been at least a small change to the DET code since 2.0.2, but I don't believe that it is major

20:17 < rcurtin> certainly not an entire refactoring or anything; at most, maybe a template parameter was added between 2.0.2 and 2.2.5, and maybe some of the function signatures changed slightly

20:18 < davidinouye> rcurtin: Yeah, I needed to extract and manipulate the internal tree so the current bindings wouldn't work.

20:18 < rcurtin> right, now I remember a little better, yeah

20:18 < davidinouye> rcurtin: Yeah, I think the templating is the main thing. I'll try to remove that in my code and see what happens.

20:18 < rcurtin> sure, good luck, and I hope soon mlpack 3 will be in the apt repositories which should make your life easier

21:02 < daivik> rcurtin: I know you asked me to consider extensions/improvements to the existing codebase -- rather than trying to propose new implementations (as it would just mean more code to maintain). I still feel that I would end up with a stronger proposal going with the clustering algorithms - and it would really be something I would genuinely be intereste

21:02 < daivik> d in working on (as opposed to selecting something from the ideas page that I'm not 100% a-okay with). So here is my plan of action, let me know what you think. I'll draft a proposal for my clustering algorithms + ensemble methods, as best as I can. And if you think it looks completely horrible after that (hopefully you'll have a chance to review i

21:02 < daivik> t before the deadline), then I'll pick an idea from the ideas page to go with.

21:04 < rcurtin> daivik: that sounds reasonable to me, but I should point out it's not likely I'll have much of a chance to review proposals in too much detail before the deadline

21:12 < daivik> completely understandable. thanks for the heads-up, and sorry for not heeding your (arguably, good) advice

21:12 < rcurtin> no, it's fine, not all of my advice is the best :)