00:16 < Roshan[m]> <zoq "Roshan: I guess the dicussion - "> zoq Yes, the discussion was certainly interesting but it ended with the initiator not making a final call on whether he is working or not on the project idea as he mentioned working on published research in the final thread.

00:28 < Roshan[m]> Ryan Curtin Hello Ryan. I found you about from the past archive thread on mlpack Xgboost. As you and Marcus were the ones on thread discussing it, I wanted to ask if we can go in a direction of implementing Xgboost. As an advance boosting algorithm with many pros over cons, I think it deserves a spot in the library. So, If possible I would like to work on implementing it for this summer GSoC. Please look into it.

00:30 < Roshan[m]> (edited) Ryan Curtin Hello Ryan. I found you about from the past archive thread on mlpack Xgboost. As you and Marcus were ... => zoq were ...

00:30 < zoq> Roshan[m]: What I don't like about the idea is that we can implement something over the sommer that is as feature complete as e.g. XGBoost. Also I'm wondering what mlpack could bring to the table, that XGBoost hasn't?

01:33 < Roshan[m]> <zoq "Roshan: What I don't like about "> . zoq Sorry, I didn't completely understood what u r trying to say from the first line. But, if I try to summarise, I guess you mean to say there is no need for Xgboost in mlpack as the official already provides c++ support.

01:45 < Roshan[m]> > <undefined>

01:45 < Roshan[m]> (edited) ... c++ support. => ... c++ support. I can definitely understand your point. Sorry, for overlooking this. We can definitely have few ideas like providing categorical support for Xgboost but it will still be experimental with no assurance to finish it in current GSoC timeline.

02:06 < zoq> Roshan[m]: But wouldn't it be better to have that support in XGBoost itself? Maybe I miss something here, what you propose is to integrate XGBoost in mlpack right?

02:26 < Roshan[m]> <zoq "Roshan: But wouldn't it be bette"> Yes...currently we do not have any implementation of Xgboost in our models. Having it will be convenient for the user as he/she will have a ready to use algorithm. Currently, I guess user need to install Xgboost seperately from source and then import it to use. Instead, since we are a scalable ml library, we can have a implementation of its in our model.

02:27 < Roshan[m]> > <undefined>

02:27 < Roshan[m]> (edited) Yes...currently we ... => zoq Yes...currently we ...

07:41 < jonpsy[m]> rcurtin: reg our float v double precision discussion, to confirm things, we agree that the type of objectives should be ```ElemType``` to maintain consistency. thanks

07:42 < jonpsy[m]> * rcurtin: reg our float v double precision discussion, to confirm things, we agree that the type of objectives should be `ElemType` to maintain consistency? thanks

11:44 < rcurtin[m]1> jonpsy: yes, optimizers should be general enough to handle any Armadillo (or Bandicoot) type for coordinates (and `ElemType` should be `MatType::elem_type`, where `MatType` is the type of the coordinates)

13:28 < zoq> Roshan[m]: Just so we are on the same side, when we talk about XGBoost we talk about the framework, so it's not a specific method. Personally I would rather write a tutorial or notebook on how mlpack and XGBoost can be combined than having a framework intergated into the mlpack codebase.

14:09 < Roshan[m]> <zoq "Roshan: Just so we are on the sa"> zoq okay, I understand. I was actually talking about models rather than framework, because we lack boosting models in our library.😅

14:16 < zoq> Roshan[m]: If you have a specific model in mind that could be added, I think it could be interesting to add, but we have to make sure the amount of work needed is reasonable for such a short timeframe.

14:32 < Roshan[m]> <zoq "Roshan: If you have a specific m"> zoq Definitely!! I was thinking about adding Gradient boosting algorithm or it's advance model Xgboost Algorithm. I think adding one algorithm is possible given time frame. Most probably we can also do halfway work on second and complete it even after GSoC. What do you think about it, is it possible to make a proposal on this?

14:46 < zoq> Roshan[m]: I would focus on one only, keep in mind testing and documentation can take a lot of time. Also make sure to add some notes about how this integrates into the current codebase, what can we reuse what has to be extended.

14:49 < Roshan[m]> <zoq "Roshan: I would focus on one onl"> @Okay Sure..So should I start making a proposal on this and get your feedback on this?

14:49 < Roshan[m]> > <undefined>

14:49 < Roshan[m]> (edited) @Okay Sure..So ... => zoq Okay Sure..So ...

14:50 < zoq> Roshan[m]: I think that is a good idea, looking forward to read some more details.

18:19 < jonpsy[m]> Hi, it's been some time since I've uploaded my draft. Would be helpful if I could know by when I can expect a feedback

19:14 < juliank14> Hi @rcurtin, my name's Julian and I'm interested in applying through the google summer of code to attempt the "Fixes to MVU and low-rank semidefinite programs" project, which was discarded due to concerns regarding its difficulty. However, I feel that I have a sufficient background to attempt the problem - I am a 4th year electrical engineering student (returning) at Queen's University, Canada,

19:14 < juliank14> with a 3.7 gpa. This semseter I have been lectured in Convex Optimization, and I'd like to take a shot at fixing/implenting this programming problem in mlpack. Would this idea be acceptable for a GSOC submission? Otherwise, I'd like to still aply for another project with your organization.

19:29 < shrit[m]> I am not sure there is mlpack_hmm

19:30 < shrit[m]> There are mlpack_hmm_train, hmm_loglik, hmm_viterbi, hmm_generate

19:33 < shrit[m]> * I am not sure there is mlpack_hmm jonathan platkiewicz

19:34 < shrit[m]> So you will have to do `make mlpack_hmm_*` and replace * by the one you need

19:37 < rcurtin[m]1> by the way jonathan platkiewicz , I am not sure if this is relevant to your case, but if you run each of the commands individually like that, the generated docker image will end up having /vendors/mlpack-3.4.2/ in some of its dependent layers (imagine it getting added to the layer after the tar -xzf, then being removed later in the rm -Rf). so, this can mean that the effective size of the docker image is larger than it

19:37 < rcurtin[m]1> should otherwise be

19:38 < rcurtin[m]1> I think maybe there are some other tools that can be used later to clean that up, but the way I've always done it is to just combine all the build/compilation commands into one `RUN` block

19:39 < rcurtin[m]1> @juliank14: cool that you found that project... but honestly, in addition to it being difficult, I'm not sure how relevant it is; even if MVU was accelerated, I'm not sure how many people would use it---honestly, I think a lot of more recent focus on embeddings via deep neural networks has stolen the thunder of nonlinear dimensionality reduction

19:40 < rcurtin[m]1> (I'm also not all that convinced that LRSDP+MVU could really accelerate things for most use cases; LRSDP is already finicky and hard to tune, and if it has to be tuned for each dataset, I'm not sure that's effectively any more useful than SDP-based MVU)

20:17 < rcurtin[m]1> sure! hope it helps :)

21:47 < shrit[m]> Can you do `make mlpack VERBOSE=1`?

21:48 < rcurtin[m]1> also did you configure CMake with `-DBUILD_CLI_EXECUTABLES=ON`?

21:50 < rcurtin[m]1> to get distributions, if you're working in C++, all you need is the headers; if you're meaning that you want to use an HMM with a `DiscreteDistribution`, that will be compiled into the command-line executables automatically 👍️

22:18 < shrit[m]> Good,

22:19 < shrit[m]> You should be able to build each of these targets independently without any issue,

22:19 < rcurtin[m]1> hang on, when you type `make mlpack_hmm_loglik`, are you in the root of the build directory? not in, e.g., `build/src/mlpack/methods/hmm/` or something?

22:38 < rcurtin[m]1> ah, well, at least there is no more problem 😃 I'm happy you got it worked out!

22:40 < rcurtin[m]1> glad the HMM toolkit is useful; I think it's one of the more unique things that we have in mlpack

23:12 < zoq> jonpsy[m]: Just commented on the application.

23:21 < GopiManoharTatir> Heyy, I was going through the potential new parser to replace boost::spirits...

23:23 < GopiManoharTatir> Using `rapidcsv` I am storing a raw in a vector at a time and then I am parsing this vector to store each element in an arm::mat, is this the right way? Is it okay to use a vector to store rows like this, will this consume more memory?

23:55 < GopiManoharTatir> row*

23:55 < GopiManoharTatir> (edited) ... storing a raw in ... => ... storing one row in ...