08:54 < rcurtin> alsc: sure, if it's an easy fix maybe we can do it, but we do a lot of crazy CMake stuff so I don't know if it'll be easy

09:11 < scarecrow> Hello are there examples/documentation on how to build a custom layer (ann)?

13:04 < zoq> scarecrow: Unfortunately no, you could look at the existing layer and uses that as a basis.

13:04 < zoq> scarecrow: Also, we are here if you need any help.

14:48 < Shreya> Hello! I am new here. I want to contribute for GSOC 2018.

14:51 < zoq> Shreya: Hello there, have you seen www.mlpack.org/involved.html and mlpack.org/gsoc.html?

14:52 < zoq> Shreya: If you have any questions let us know.

14:58 < Shreya> Thanks zoq. Can you please tell me how shall I start? I went through the two links.

15:01 < zoq> One option is to go through the issues listed on github and maybe you find something interesting, another option is to go through the code and find something that could be improved or maybe you like to write a new interesting method.

15:06 < Shreya> Okay thank you!

17:27 < scarecrow> Thank you zoq for responding. I tried to emulate code in the Linear layer. I'm running into trouble while adding my layer to FFN.

17:28 < scarecrow> It fails to compile. Looks like I need to modify "layer_types.hpp" to include my type in the boost::variant

17:30 < scarecrow> The other workaround is to extend one of the layer already in the list. But since the methods like Forward Backward are template methods I cannot override them.

17:30 < scarecrow> suggestions?

17:34 < rcurtin> scarecrow: you're right, it would need to be added to LayerTypes

17:35 < rcurtin> I had previously thought that we had some infrastructure to do this, so e.g. you could do something like

17:35 < rcurtin> FFN<NegativeLogLikelihood<>, RandomInitialization, <set of extra custom layers>>

17:36 < rcurtin> but I am not seeing code that does that

17:36 < rcurtin> I do remember discussing it though, but maybe I remember the resolution incorrectly

17:36 < rcurtin> maybe zoq has a different way to do it that I have forgotten, let's see what he says

17:37 < scarecrow> Right, that is not possible with the current version. Thank you for your response. Lets wait for zoq.

17:39 < zoq> Yeah, I think we discussed the <set of extra custom layers> solution and agreed on it, but unfortunately it's not implemented yet.

17:40 < zoq> Another option that somehow works with clang is to inherit from e.g. the LinearLayer.

17:40 < cult-> rcurtin: when are you expecting bandicoot to be in alpha phase, and how much % of mlpack routines can be covered with it?

17:40 < rcurtin> do you want me to open an issue for it so we don't expect?

17:40 < rcurtin> cult-: sorry, I saw your question; I was preparing a NIPS talk so I did not get to respond to it :(

17:40 < cult-> ok np

17:40 < rcurtin> I am not sure when it will be ready; Conrad and I are currently working on some sparse matrix improvements when we can

17:40 < rcurtin> and I assume after that we'll get back into Bandicoot development more

17:41 < rcurtin> I'm excited about it, because every algorithm that takes a MatType template parameter (which eventually should be every mlpack algorithm) will be able to use a bandicoot matrix instead

17:41 < rcurtin> so then all the operations can be done on the GPU, without needing to significantly change the code

17:41 < rcurtin> there may be some places where the bandicoot matrix class doesn't work quite right for mlpack, but we can adapt that code when we get there

17:42 < scarecrow> Inheriting did not work for me. I'm using g++ though.

17:42 < cult-> just a quick note on hmm implementation; maybe you recall there were some issues with it, and you fixed it from 2.1.x. the problem is that now if data is bad, i can still make it work with the old version by log(), but not with the new versions

17:42 < rcurtin> out of the box I expect things like linear and logistic regression and other typical algorithms to work fine, possibly neural networks too

17:42 < rcurtin> oh, hm, would you mind opening a github issue so that I can look into it?

17:43 < rcurtin> more complex things like nearest neighbor search might not get speedup immediately but may instead require some tuning and modification; not sure yet

17:43 < rcurtin> for timeline, I dunno, I think 6 months to 10 months is reasonable? neither of us are currently working on it full-time

17:44 < zoq> Yeah, if you open an issue, I'll take a look at it once I get a chance.

17:45 < rcurtin> zoq: right, let me do that now then

17:46 < zoq> rcurtin: How was your presentation?

17:47 < rcurtin> it's in about 5 or 6 hours, but I at least have the slides and talk ready finally

17:48 < rcurtin> actually Shangtong is here at the same workshop, he's presenting in about an hour on his implementations of reinforcement learning

17:48 < rcurtin> I'm looking forward to meeting and talking with him afterwards :)

17:48 < zoq> ah right, I guess distributed rl

17:56 < cult-> do you have a list of companies/projects who are using mlpack in production?

17:57 < rcurtin> cult-: no, typically people don't seem to tell me (or us) when they're using mlpack in production

17:57 < rcurtin> we use it internally at Symantec for some experiments here and there but none of those projects have made it into production yet

17:58 < rcurtin> I know that Sumedh's group was using it at eBay some time ago, but no idea if it made it into production or not

17:58 < rcurtin> usually I see who is using it by looking at who is citing the mlpack paper:

17:59 < rcurtin> https://scholar.google.com/scholar?cites=17794023163287158191&as_sdt=2005&sciodt=0,5&hl=en

17:59 < rcurtin> I read a cool paper sometime back where some lab was using mlpack to do real-time control of a spacecraft

17:59 < cult-> nice

18:08 < cult-> rcurtin: so, in hmm in 2.0.x, i still use the fix you gave a while ago to make the transition matrix random to avoid errors in training. now, above 2.1.x, you did the fix that works well.

18:09 < cult-> rcurtin: the problem is, when in 2.0.x the data isn't good, i just use replace the datapoints with logarthmic values and its good. in 2.1.0 if i do log(), the function runs without errors, but all states are the same with or without log()

18:09 < cult-> that means I can't fix the data in 2.1.x

18:10 < cult-> or 2.2.x

18:17 < rcurtin> I don't remember the fix very well, can you explain why the log() is needed? (or maybe you have a link to the right IRC log?)

18:19 < cult-> yes 1 min

18:21 < rcurtin> thanks

18:21 < cult-> so, when my data isn't proper for the number of states I given, I simply use log(data) instead of data, to make the series more noisy and hence allow the algorithm to distinguish between states

18:22 < cult-> thats my fix for my own data issue

18:22 < cult-> and

18:23 < cult-> when the data wasn't good enough in this case, without this fix https://github.com/mlpack/mlpack/commit/8e62052569b5be711d425dcd9f2a675911f5681d we had chol decomposition error

18:24 < cult-> after this fix, that has been solved. now if i want to fix my data with the log() again, i can't do that anymore

18:25 < cult-> probably its not clear what i am talking about. but with 2.0.x i used arma::mat c = arma::randu<arma::mat>(X, X);for (size_t i = 0; i < X; ++i) c.col(i) /= arma::accu(c.col(i));hmm.Transition() = c; to overcome the issue

18:25 < cult-> that few lines above works well with 2.0.x and i can also use log() on my datapoints so that i will get proper states

18:26 < cult-> but in >=2.1.x i a) don't need to use those few lines because it has been already implemented b) using log() on data doesn't help anymore

18:27 < cult-> basically, the fix solved the chol decomposition errors, but i can't modify my data anymore from 2.1.x if the states are too high and the dataset isn't appropriate for the number of states

18:30 < cult-> again, with 2.0.x and with the manual transition matrix hack, everything works. since 2.1.x without the transition matrix hack (because its already fixed in the commit above) things behave differently now and not in a good way

18:39 < cult-> it looks to me that the difference is that intial states part should be reverted back as it was before

18:40 < cult-> add back this initial(arma::ones<arma::vec>(states) / (double) states), and remove initial /= arma::accu(initial);

18:41 < cult-> because the transition matrix fix is the same what i do manually, the only difference is the initial variable, IF there were not other modifications since

18:43 < rcurtin> (sorry I am now in a talk---I will come back to this over lunch)

18:43 < cult-> thanks, i will dig into this and will let you know

19:47 < cult-> interesting i can't reproduce it with 2.2.x

19:51 < cult-> i don't have that data anymore, but that was what i was experiencing above.