00:46 < rcurtin> zoq: ironstark: it would probably be better to build R from source, but if that is too complex we can just install R via the package manager

00:46 < rcurtin> I think it would be nice to benchmark against MachineLearning.jl and Shark, but MLlib's target is distributed systems, so I am not sure that would be a good comparison

00:47 < rcurtin> if there is time for MLlib we can add it, but we have to be careful to point out that we're only using Spark on one machine, not multiple machines, so I think a lot of people would call that benchmark "unfair"

05:42 < rcurtin> partobs-mdp: is there an 'extended version' of the HAM paper you are using, or just the conference paper?

05:43 < rcurtin> the version I have is pretty light on some details and can be hard to follow in some places, probably because of space constraints...

09:12 < kris1> How can i check for BOOST_REQUIRE_EQUAL(decltype(function()), float);

09:40 < lozhnikov> kris1: I suggest static_assert instead of BOOST_REQUIRE since that is a compile-time check

09:41 < kris1> But i wnated to include this for test case of float ssRBM

09:41 < kris1> I don’t know how else to test it.

09:42 < lozhnikov> I can insert static_assert into the test

09:43 < lozhnikov> I don't*you

09:43 < lozhnikov> *you

09:43 < lozhnikov> *That was a typo. I mean: you can insert static_assert into the test.

09:44 < lozhnikov> I don't see any sense in dynamic tests for compile-time properties

10:02 < kris1> How do i add test case for checking float datatype works with ssRBM. The softmax regression accepts only arma::Mat<double>

10:06 < lozhnikov> you can convert results to double

10:23 < kris1> Okay just one more question can i use something like typedef typename RBMPolicy::ElemType eT;

10:23 < kris1> I need this in the rbm.hpp file.

10:25 < lozhnikov> sure

12:46 < partobs-mdp> rcurtin: I'm using the 'standard' arxiv paper: https://arxiv.org/abs/1602.03218

12:51 < partobs-mdp> By the way, how should I write a signature for the function that returns a reference to matrix slice?

12:52 < partobs-mdp> So that I would be able to write F(1) = Join(F(2), F(3)), where F(1) returns (say) reference to the first column of some arma::mat, F(2) - second, and so on

13:01 < partobs-mdp> (Update) I managed to hack around it by returning arma::subview_col<T> - at least it compiles ^_^

13:02 < partobs-mdp> Although I can't help thinking about it as a hack :) What do you think?

13:05 < zoq> Couldn't you use Join(F(2), F(3), F(1)) instead of using a subview?

13:06 < partobs-mdp> But shouldn't F(1) then also be arma::subview_col<T>?

13:06 < partobs-mdp> Like this: F(arma::Col, arma::Col, arma::subview_col)

13:07 < zoq> Ideally you would use a template, so that you could use a subview.

13:08 < partobs-mdp> Well, I do use templates in the code - I omitted them here for brevity

13:10 < zoq> The advantage is that someone could use the code with arma::mat or subview.

13:10 < partobs-mdp> zoq: Could you elaborate on that?

13:10 < partobs-mdp> I didn't quite understand :(

13:12 < zoq> If we write:

13:12 < zoq> template<typename Type3>

13:12 < zoq> void F(arma::Col f1, arma::Col f2, Type3 f3)

13:12 < zoq> someone could pass a subview or arma::mat or arma::Col, that's all, we are not restricted to subview.

13:14 < partobs-mdp> I see, a template for output type, right?

13:15 < zoq> Yeah, you could use a template for the input parameter as well, if you think that's necessary or a good idea.

13:17 < rcurtin> agreed, that is what I would suggest also

13:17 < rcurtin> it's really late here... sydney time is weird, so I think I will go to bed now

13:31 < zoq> partobs-mdp: Can you take a look at: https://github.com/mlpack/mlpack/pull/1005#pullrequestreview-54536684 once the issue is solved, we can merge the code :)

13:40 < rcurtin> don't worry about the style checks, they are part of a bad merge I did yesterday; I'll fix it tomorrow

13:40 < rcurtin> ah actually I'll just go ahead and fix it now, I already have the commits...

13:46 < zoq> Let me rerun #1044

13:48 < zoq> it's green again

13:57 < Erwan_r1d1> Hi

13:58 < zoq> Erwan_r1d1: Hello!

13:59 < Erwan_r1d1> I'd like to ask some help about serialization but I'm just parsing the logs first

14:00 < zoq> Erwan_r1d1: Sounds good.

14:51 < Erwan_r1d1> Ok, logs partly answered my question, but not totally

14:51 < Erwan_r1d1> I think the issue comes because of the interaction of boost and mlpack

14:52 < Erwan_r1d1> Let me provide some context :

14:52 < Erwan_r1d1> I have the following setup :

14:52 < Erwan_r1d1> - an abstract class "Serializable" that provides a pure virtual "serialize" method and declare as friend the boost::serialization::access class. - a class "Sequence" that contains both a map of (std::string, mlpack::gmm::GMM) and a vector of pointers to class "Motion". Both Motion and Sequence inherit from Serializable, and Motion is an abstract class too. - a class "DMP" that inherits from Motion, is thus also "Serializable".

14:53 < Erwan_r1d1> My issue is the following : to serialize all my classes, I need to use the macro BOOST_SERIALIZATION_ASSUME_ABSTRACT( Motion ) to declare this class as abstract, and BOOST_CLASS_EXPORT_GUID( DMP, "DMP") so that boost knows this class.

14:53 < Erwan_r1d1> However, if I do that, my compilation fails because of the lower/uppercase difference between mlpack and boost :

14:54 < Erwan_r1d1> 12 In file included from /usr/include/boost/serialization/serialization.hpp:44: 13 /usr/include/boost/serialization/access.hpp:118:11: error: no matching member function for call to 'serialize' 14 t.serialize(ar, file_version); 15 ~~^~~~~~~~~

14:54 < Erwan_r1d1> What is strange is that in my Sequence class, I'm not yet serializing the map of GMM. So I can't call the CreateNVP macro that is intented to solve the problem.

14:55 < Erwan_r1d1> I guess the macro is somehow parsing the whole class and setting the serialize function ?

14:55 < Erwan_r1d1> Anyway

14:55 < Erwan_r1d1> If I don't use the "BOOST_CLASS_EXPORT...", everything compiles fine but I get a runtime error on unregistered class. If I add the "oa.template register_type<DMP>();" in Sequence serialize function, I get a segfault when the Motion classes are serialized (it loops till segfault).

14:55 < Erwan_r1d1> To put things in order : I apparently need to use the EXPORT macro to avoid the runtime issues when serializing ; If I use this macro, I encounter the case-issue. Is there a way I can use the macro and avoid the issue ?

14:56 < Erwan_r1d1> (thanks for reading, any help appreciated :) )

15:33 < zoq> Erwan_r1d1: rcurtin has written the serialization code and I think once he gets back he will respond, unfortunately that might be tomorrow. So make sure to check the log: http://www.mlpack.org/irc/

15:44 < Erwan_r1d1> Yes, I checked :)

15:44 < Erwan_r1d1> No problem, I can wait

15:46 < partobs-mdp> zoq: Added the include you mentioned - I think we can merge the PR one the CI checks are over :)

23:36 < rcurtin> Erwan_r1d1: hmm, I had not considered more complex uses of serialization when I wrote that code

23:36 < rcurtin> can you tell me if the following kind-of-ugly idea works...

23:37 < rcurtin> instead of holding a std::map<std::string, gmm::GMM>, create a 'wrapper class' SerializableGMM that either inherits from GMM or holds a GMM object internally

23:37 < rcurtin> and also has a serialize() function that just calls GMM::Serialize() (i.e. 'ar & data::CreateNVP(gmm)')

23:42 < sumedhghaisas> rcurtin: Hey Ryan... I have fixed the comments and the batch size issue.

23:42 < sumedhghaisas> although for that serialization comment. I don't know what to do.

23:42 < rcurtin> yeah, the only problem is, I am about to go to the sydney aquarium, so it might be a little while until I respond :)

23:42 < rcurtin> thanks for taking care of the batch size though

23:43 < rcurtin> I'll make sure I respond to the serialization comment later today

23:43 < sumedhghaisas> I think that the network is serialized solely in FFN and RNN

23:43 < sumedhghaisas> ohh okay ... no problem :)

23:43 < sumedhghaisas> till then I have to complete some tests for NTM

23:44 < rcurtin> I think you might be right, I will have to check closely