08:57 < kaushik_> Hello, so I have gone through some of the tutorials, design guidelines.

08:57 < kaushik_> Can someone direct me to something i can work on, new feature / bug fix?

08:58 < kaushik_> I saw issues on github page but seems like there is already someone working on almost all of easy issues.

12:56 < rcurtin> kaushik_: there are a lot of issues open, I am sure that you should be able to find one in there; alternately, you can try implementing a new machine learning algorithm or trying to accelerate an existing implementation

15:17 < kaushik_> rcurtun: ok. I will work on https://github.com/mlpack/mlpack/issues/1120 .

15:18 < rcurtin> ok, I was going to work on this one also today, but there is definitely room for two people to work on it

15:19 < rcurtin> why don't you focus on things in src/mlpack/methods/r* and s* and I'll start from the beginning of the alphabet?

15:19 < rcurtin> do you think that would work for you?

15:20 < kaushik_> sure.

15:21 < kaushik_> bbl

15:23 < kaushik_> rcurtin: this is more of a manual work right?

15:40 < rcurtin> I am not sure what you mean

17:12 < kaushik_> rcurtin: does this data::CreateNVP(rf, "random_forest") aslo change to BOOST_SERIALIZATION_NVP (rf);

17:13 < rcurtin> kaushik_: yes, go ahead and do that

17:14 < rcurtin> technically that is not reverse compatible with older saved random forests, but the next release is a major version bump so I think it is ok

17:15 < rcurtin> zoq: lots of PRs today, a productive day I guess :)

17:17 < rcurtin> also, mlpack stickers arrived: http://www.ratml.org/misc_img/mlpack_stickers.jpg

17:17 < rcurtin> if anyone wants one, let me know, I guess I can toss it in the mail :) (I dunno how expensive international shipping for a single sticker is though...)

17:20 < kaushik_> can I also get one sticker 😅

17:23 < rcurtin> kaushik_: I can ship you one if you like, but shipping to india from the US is a little expensive for a single sticker

17:32 < zoq> Looks great to me ... I'll grab one once I get a chance :)

17:32 < kaushik_> rcurtin: yeah, I understand. I wasn't serious when I said that.

17:32 < kaushik_> https://www.irccloud.com/pastebin/Twr2As97/

17:34 < kaushik_> btw, will this be replaced similarly or as issue says " can also change places where we serialize std::vectors or std::maps to serialize those directly instead of first serializing the number of elements and then serializing each element." it is somewhat different?

17:37 < rcurtin> kaushik_: no worries :)

17:38 < rcurtin> for the serialization, previously the way it worked is that because of the serialization shim's weirdness, you could not directly do 'data::CreateNVP(someStdVector, "name")'

17:38 < rcurtin> instead, you have to first serialize someStdVector.size() and then serialize each thing individually

17:38 < rcurtin> if everything is changed to use serialize() instead of Serialize(), then the serialization shim isn't needed and we can use boost::serialization directly to just do 'BOOST_SERIALIZATION_NVP(someStdVector)', which is much shorter and cleaner

17:39 < rcurtin> so the snippet you sent, you could remove that and also the serialization of 'numTrees' and just do

17:39 < rcurtin> ar & BOOST_SERIALIZATION_NVP(trees)

17:41 < kaushik_> right, I thought the same.

17:42 < rcurtin> there are tests built in for the serialization, so once you make the changes you can build and run mlpack_test to make sure nothing is broken

17:42 < kaushik_> and there are places where using namespace data; and then CreateNVP (x,"x") is used so i have removed the using namespace part.

17:42 < rcurtin> yep, no need for the namespace specification once we use only BOOST_SERIALIZATION_NVP

17:42 < kaushik_> ah ok cool :)

17:47 < zoq> rcurtin: I'm curious is the gray box the PC-tower?

17:47 < rcurtin> the one the stickers are sitting on?

17:48 < zoq> yes

17:48 < rcurtin> that's an old mac G4 cube

17:48 < rcurtin> which is sitting on top of an SGI octane

17:48 < rcurtin> last time I played with those I couldn't get anything to install on them correctly... the G4 cube wouldn't boot from USB correctly (a problem with debian-installer I think)

17:48 < rcurtin> and the octane appears to have a bad network card... it is sending invalid packets

17:51 < zoq> ah, had to lookup SGI octane :)

17:52 < zoq> I guess, now you can put at sticker on each :)

17:52 < rcurtin> yeah, I have 200, so there is no shortage :)

18:39 < rcurtin> zoq: I am trying to debug the speed of LSTMs for an internal Symantec project (which hopefully will turn into a deployment), and it seems like there are lots of copies in Forward() and Backward()

18:39 < rcurtin> like 'output.submat(...)' in the boost::apply_visitor() calls

18:40 < rcurtin> these seem like they are necessary for batch support, since the input format is currently set up so that each sequence is unrolled into a single column of a matrix

18:41 < rcurtin> I think the input format for RNNs has been discussed before, but it seems like it would be best for the actual speed of the code if we took input as a cube, with each slice corresponding to a time step and each column corresponding to a data point

18:41 < rcurtin> what do you think? I can start some refactoring to try and avoid those copies and open it as a PR if you like

18:42 < rcurtin> the only thing I am not sure of is how we can support variable-length sequences like that

19:12 < zoq> Are we talking about LSTM with #1107 merged? But I think using cube would make sense, but right now I don't have a good solution for variable length sequences.

19:16 < rcurtin> ah I meant in master, let me look at #1107 to see if the issue is fixed

19:37 < rcurtin> the code looks definitely better but I am having trouble making it work, I think there was some problem in my network setup...

19:39 < zoq> or there is some isue with the LSTM code, I can take dig into the problem if you send me the network

19:39 < zoq> might be tomorrow :)

19:43 < rcurtin> nah, I can debug it, it's ok :)

20:13 < rcurtin> I got it to work; with a two-layer network of LSTMs where each layer has 250 elements, it takes 11 seconds (!) for 50 iterations of SGD (iterations not epochs)

20:13 < rcurtin> so I think there is still some slowness somewhere

21:18 < zoq> I think running over batches would accelerate the training process, but I agree there is still something we have to dig up.