11:56 < s1998> I had a PR wrt token 817 on DTree.The destructor is deleting the left and right children (the data ). And copy constructor is copying only the pointers (not the data). Is that Okay ?

12:11 < s1998> The child node (data) needs to be copied or the pointer to the child node?

13:16 < rcurtin_> s1998: I haven't had a chance to look at your PR lately, I'll try and find time to do it today

13:33 < yashu-seth> I was exploring the mlpack_ann module, but I could not a find a documentation for it. Can someone please help me with some resources to understand the module?

13:39 < s1998> rcurtin: okay

17:33 < travis-ci> mlpack/mlpack#1728 (master - c5c0b5a : Ryan Curtin): The build was fixed.

17:33 < travis-ci> Change view : https://github.com/mlpack/mlpack/compare/d5148d9c6a9b...c5c0b5a9acab

17:33 < travis-ci> Build details : https://travis-ci.org/mlpack/mlpack/builds/190314686

17:45 < travis-ci> mlpack/mlpack#1729 (master - 2a2f234 : Ryan Curtin): The build is still failing.

17:45 < travis-ci> Change view : https://github.com/mlpack/mlpack/compare/c5c0b5a9acab...2a2f2343192d

17:45 < travis-ci> Build details : https://travis-ci.org/mlpack/mlpack/builds/190315599

19:11 < rcurtin> hmm, I wonder what happened there...

19:12 < zoq> I'll take a look later today

19:13 < rcurtin> I'm trying to see if I can reproduce it now on my local system, to see whether it's a code issue or a benchmark system issue

19:18 < rcurtin> ah, I see what the issue is

19:22 < rcurtin> the benchmark configuration used the option '--iteration' but that changed at some point to '--max_iterations'

19:37 < zoq> ah, I see

19:55 < travis-ci> mlpack/mlpack#1730 (master - c6154ae : Ryan Curtin): The build was fixed.

19:55 < travis-ci> Change view : https://github.com/mlpack/mlpack/compare/2a2f2343192d...c6154aef9b84

19:55 < travis-ci> Build details : https://travis-ci.org/mlpack/mlpack/builds/190362713

21:36 < rcurtin> zoq: I'd like to merge #825 (the automatic bindings PR), did you have any comments to make? I can wait for a bit longer if you like :)

21:40 < zoq> rcurtin: I'm almost done with the PR, maybe you can wait until tomorrow?

21:41 < rcurtin> sure, no hurry!

21:41 < rcurtin> I have the next part almost done... just today I did a short five-line refactoring of emst_main.cpp, added "add_python_binding(emst)" to emst/CMakeLists.txt, and got a working Python binding :)

21:41 < rcurtin> so things are definitely coming together

21:46 < zoq> Sounds great, I'm sure a lot of people are more than happy to use python instead of c++. So really excited to see this thing working.

21:48 < rcurtin> yeah

21:48 < rcurtin> the main missing piece, for now, is the serialization of models... I've done it with some handwritten bindings, but I'm not doing it automatically yet

21:48 < rcurtin> like I can easily write a binding that serializes the model to a binary blob or whatever using boost serialization, but that means if I do, e.g.,

21:49 < rcurtin> model = mlpack.hoeffding_tree(X, y, other_options=...)

21:49 < rcurtin> then when I use that model, like

21:49 < rcurtin> mlpack.hoeffding_tree(model, test_set=X_test)

21:49 < rcurtin> then it will have to deserialize that entire model string, which can take a while

21:49 < rcurtin> so in a handwritten binding I managed to have 'model' just be a memory pointer to an initialized model object and it seemed to work fine

21:50 < rcurtin> I just need to figure out how to do that automatically... but I definitely think it's possible :)

21:54 < zoq> hm, if you say the deserialize of the entire model takes some time, does that mean it's basically unusable?

21:54 < rcurtin> well, sort of unusable, but not entirely

21:54 < zoq> Would be super easy, that way

21:54 < rcurtin> in the example of Hoeffding trees, the overhead for serialization/deserialization for trees of any reasonable size is hundreds of ms to a few seconds

21:54 < rcurtin> so if I'm doing something like looping over points in a dataset and predicting the label of a single point, it takes forever

21:56 < rcurtin> for some models which are very small, like the regression models (LARS/linear regression/etc.), the serialization overhead would be virtually zero

21:57 < zoq> ah yeah, perhaps a RAMDisk is the solution :)

21:57 < rcurtin> yeah, especially with RAM being so cheap now

21:57 < rcurtin> I've considered mounting my home desktop's / on a ramdisk... there's more than enough RAM to do it