03:42 < pruvi007> Hi Sir/Ma'an

03:42 < pruvi007> *m

03:43 < pruvi007> I have implemented many classical ML Algorithms in Python

03:43 < pruvi007> An i am willing to implement those in C++

03:43 < pruvi007> What all algorithms are needed to be implemented?

06:48 < huanyz0918> hi, can anyone tell me how to get start with this project? I'm very interested in GSoC this year, thanks!

09:15 < shubhangi> Hello

09:15 < shubhangi> Everyone

09:20 < shubhangi> I got stuck in building mlpack on CPU at command 'make ' it built till 77% where it is building neural networks. My laptop's configurations are 4GB RAM, 64 bit processor. What should I do now should I shift to GPU or RAM is not enough for building?

10:24 < Suryo> zoq, rcurtin: I would like to discuss the API for constrained optimization problems in PSO with yoi

10:24 < Suryo> *you

11:17 < roy_> hello

11:30 < Viserion> I am using python3.5 and I am able to import mlpack but when I run :output = mlpack.preprocess_split(input=dataset, input_labels=labels,test_ratio=0.3) it gives error: Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: module 'mlpack' has no attribute 'preprocess_split'

13:08 < Viserion> I am using python3.5 and I am able to import mlpack but when I run :output = mlpack.preprocess_split(input=dataset, input_labels=labels,test_ratio=0.3) it gives error: Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: module 'mlpack' has no attribute 'preprocess_split

13:15 < rcurtin> Viserion: how did you install mlpack?

13:15 < rcurtin> Suryo: sure, I can do my best

13:15 < Viserion> builded from source as in the documentation

13:15 < rcurtin> huanyz0918: hi there, take a look at http://www.mlpack.org/involved.html and http://www.mlpack.org/gsoc.html; those should be good places to get started

13:16 < rcurtin> shubhangi: I'm really not sure what the issue there is. There's no way to use the GPU for building, and I've never seen the build get "stuck" like you say, so unfortunately I'm not sure I can help too much here

13:17 < rcurtin> Viserion: ok, sounds good. did you do 'sudo make install' also?

13:17 < rcurtin> Viserion: also, in your build directory, take a look in src/mlpack/bindings/python/mlpack/; there should be lots of .so files, including 'preprocess_split.so'; are those there?

13:20 < Viserion> I can see many .hpp, .pxd, .pyx files none .so

13:27 < rcurtin> Viserion: ok, I see. what happens if you type 'make python'? it'll be a lot of output, but if you can put it on pastebin it could help

13:34 < Viserion> Writing make python gives : make: Nothing to be done for 'python'.

13:35 < rcurtin> I see... try 'make clean && make python' (that will take a while)

13:35 < rcurtin> and if you can capture the output it could be really helpful

13:42 < Viserion> It shows , make: *** No rule to make target 'clean'. Stop.

13:44 < rcurtin> what directory are you in?

13:44 < rcurtin> this should be done from the main build directory

13:44 < rcurtin> (sorry if I was unclear)

13:44 < rcurtin> if you're not in the main build directory, just try 'make python' there and see what it does

13:44 < rcurtin> no need to try 'make clean' yet

13:44 < rcurtin> basically, to give a few more details, each of those .so files are what actually contain each mlpack Python method

13:45 < rcurtin> so when you see 'module 'mlpack' has no attribute 'preprocess_split'', to me the first thing I wanted to check was whether those .so files were actually there

13:45 < rcurtin> or if there was some build issue that caused them to not be generated

13:45 < rcurtin> and so now that we know they don't exist we can try and figure out why :)

13:46 < Viserion> Yes I get that. I have mlpack-

13:46 < Viserion> i have mlpack 3.0.4 dir and build dir inside it

13:46 < Viserion> when I write make python in there I get make: *** No rule to make target 'python'. Stop.

13:50 < rcurtin> okay, so the Python bindings were never built then?

13:50 < rcurtin> let's try reconfiguring with CMake and seeing what the output is

13:50 < rcurtin> can you 'rm -f CMakeLists.txt' and then redo the same cmake configuration command you used when you originally built the library?

13:50 < rcurtin> and paste the output onto pastebin or something so I can look at it

14:22 < Puranjay> Hi,

14:24 < Puranjay> I want to work on the Mlpack-Tensorflow translator, please help me get started with the initial steps

14:25 < favre49> rcurtin:Assuming you guys have the time for it, where would I submit a proposal for review?

14:35 < Yashwants19> Hi rcurtin can you please with some unknown style issues and some conflicting file in PR #1717

14:40 < Yashwants19> *please help me with

15:08 < rcurtin> Yashwants19: yeah, there is a bit of a bug right now, the style checker only shows the most recent build... so if you push a commit then check the style checks page quickly it should show the results

15:14 < Yashwants19> I have check the result.There is no style issue related to my commit

16:42 < atulim> Sir, I early proposed of designing java binding for mlpack. I came to know that Yasmine was designing first java binding but she switched to go binding because of verbose issues. I am going to use jna without swig. Can you suggest me anything? @ryan @zoq

16:46 < rcurtin> atulim: that sounds great, and Yasmine did indeed switch to the Go bindings, but I don't have any particular suggestions

16:47 < rcurtin> if you're looking for somewhere to contribute, perhaps picking up the Go bindings PR and addressing some of the issues in it would be a way?

16:47 < rcurtin> Yashwants19: ok, I'll take a look when I have a chance

16:50 < atulim> okay. i already improved some whitespace bugs but i thought i could design java bindings. While designing java bindings I would look at the PR of Go bindings .It was great hearing from you again @rcurtin.

16:50 < rcurtin> sure, sounds good. :) you could also look at the mailing list archives where I had discussions with Yasmine; that could be helpful too

16:55 < sreenik> Hello, I am not being able to transfer compute over to the GPU for some reason, although nvblas is configured properly. My compile statement is g++ DigitRecognizerCNN.cpp -std=c++11 -lboost_serialization -lboost_program_options -usr/local/cuda/lib64/lnvblas.so -usr/local/lib/libmkl_rt.so -fopenmp -larmadillo -lmlpack. Am I doing this correctly? I have tried linking libnvblas.so instead of lnvblas.so, but to no avail

16:56 < rcurtin> sreenik: I think you need to make sure libarmadillo.so is linked against nvblas when it's built

16:56 < rcurtin> you can check what libarmadillo.so is linked against with `ldd /path/to/libarmadillo.so`

16:57 < sreenik> Okay

16:57 < rcurtin> alternately, you can comment out "ARMA_USE_WRAPPER" in armadillo_bits/config.hpp, and then in your call to compile DigitRecognizerCNN.cpp, you can link directly with nvblas

16:57 < rcurtin> I think either of those things can work

16:57 < sreenik> Okay I am checking. Will be a big relief, the CNN is really taking a lot of time on CPU

17:12 < sreenik> You are right, armadillo is not linked with nvblas. Which cmake variable do I modify to rebuild?

17:38 < atulim> @rcurtin If I may ask where can I find mailing list archives?

17:41 < rcurtin> http://knife.lugatgt.org/pipermail/mlpack/

17:41 < rcurtin> although actually Google does a decent job of searching:

17:41 < rcurtin> https://www.google.com/search?safe=off&source=hp&ei=PZKKXKrQBcvJ5gKAobPgCg&q=yasmine+dumouchel+java+bindings&btnK=Google+Search&oq=yasmine+dumouchel+java+bindings&gs_l=psy-ab.3...116.3555..3849...3.0..0.319.3471.23j7j2j1....2..0....1..gws-wiz.....0..0i131j0j0i10j0i22i30j33i160.k1OdzgWdWw8

17:41 < rcurtin> oh, that link ended up a lot longer than I expected

17:42 < atulim> @rcurtin thank you.

19:04 < sreenik> Thank you @rcurtin for your time. I am sorry I am bothering you so many times but commenting out ARMA_USE_WRAPPER and linking directly didn't give a better result. I guess building armadillo with nvblas is the remaining option. Running cmake -LA gives a long variable list but I can't find anything obvious related to nvblas. Or maybe I am wrong somewhere else, I have spent a lot of time on this but I can't really understand where :(

19:15 < rcurtin> you can check what is linked against what with `ldd`, and that should be able to tell you if you're linked against nvblas or not

19:15 < rcurtin> but the thing is, depending on the computation (and the GPU), nvblas may choose to *not* do it on the GPU, meaning that there will be no speedup

19:15 < rcurtin> nvblas has to estimate that the performance of the operation on the GPU would be better, *including* the time it takes to move the data to the GPU

19:20 < sreenik> Oh I get it. Thanks :)

20:04 < picklerick> any changes we made in PROGRAM_INFO would be reflected in the mlpack_algo --h ??

20:10 < rcurtin> picklerick: yep, exactly

20:12 < picklerick> @picklerick but they weren't even after make mlpack_test

20:12 < picklerick> everything is fine but considering we are changing options it's important to be there right ??

20:13 < picklerick> okay they are oops my bad :|

21:29 < rcurtin> no problem :)

21:33 < Suryo> zoq, rcurtin: reference -- constrained PSO

21:33 < Suryo> The api for constrained functions is documented here

21:33 < Suryo> https://ensmallen.org/docs.html#constrained-functions

21:34 < Suryo> What I understand based on this is that the user would have to decide how each constraint is being handled.

21:35 < Suryo> And on this page, the two methods that are described basically correspond to having only 'feasible solutions' and using 'penalty function' (although, at some level, these are equivalent)

21:36 < Suryo> Now, in the ideas page, one of the tasks in focus is to program variants of PSO for constrained optimization

21:36 < Suryo> However, if I am to preserve the current API style, then the way each constraint is handled would not totally depend on the algorithm, but on the user.

21:38 < Suryo> What I've done to handle constrained problems in PSO is basically introduce the constraints into the objective and follow the usual approach for feasible solutions. For this, I did not actually have to write a different PSO algorithm altogether - just had to make sure that the initial particles are feasible (as per the paper by Eberhardt)

21:40 < Suryo> I would like some inputs regarding the API that would be suited. Would we like to program methods that can handle constraints in standard ways, or do we leave the constraint penalization to the users altogether, the way it is documented in the link that I just shared?

21:41 < Suryo> Kindly let me know what you think. Thanks!

21:43 < Suryo> If the constraint handling is left to the users, then the amount of work at our end from a programming pov is a lot less.

21:44 < Suryo> And if that's what you would want, then in my opinion, it would be wise to include other variants of PSO as a part of the GSoC end goal.

21:46 < Suryo> There are other problems that I haven't taken care of. These are minor issues but would require testing. For example, constrained PSO relies on an initial set of feasible solutions. Now if the initial set is being sampled from an infeasible range itself, then the optimization will not be done. Though it sounds trivial, I believe that it's important to program timeouts for such things.

21:47 < Suryo> And then, parallelization within ensmallen

21:47 < Suryo> And things like that.

21:53 < travis-ci> mlpack/ensmallen#208 (ensmallen-1.14.2 - 8d9682c : Ryan Curtin): The build passed.

21:53 < travis-ci> Change view : https://github.com/mlpack/ensmallen/compare/e62d6c76b40a^...8d9682ca5448

21:53 < travis-ci> Build details : https://travis-ci.org/mlpack/ensmallen/builds/506503066