05:46 < daivik> I think that the @file tag in the comments in mlpack/src/mlpack/core/optimizers/gradient_descent/gradient_descent.cpp is incorrectly set as "gradient_descent_impl.hpp" -- very minor issue, but I thought I'd point it out nevertheless.

08:13 < adl1995> The following is a re-post from the mailing list: "I'm following a potential idea for GSoC 2018 titled "Particle swarm optimization". I apologize if I misunderstood what constrained problems are, but can't we apply constraints to the methods already present in "src/mlpack/methods/*" directory? Or, are these unrelated? In the latter case, are there some specialized methods for constrained problems that need to be implemented for this

10:30 < dj> In the file mlpack/methods/ann/rnn_impl.hpp , line No. 174. There is a comment "Wrong ". No other information is there, why it is wrong or anything else.So, What is the problem there?

11:01 < daivik> @dj -- I'm also going through the codebase myself... Although, I cannot find the comment that you asked about. Are you sure its in mlpack/src/mlpack/methods/ann/rnn_impl.hpp?

11:08 < dj> @daivik i am sure it's there.

11:10 < daivik> https://github.com/mlpack/mlpack/blob/master/src/mlpack/methods/ann/rnn_impl.hpp --> not here

11:11 < daivik> i'm sorry .. i see it now

12:11 < rcurtin> daivik: dj: that's accidentally left in from a PR I just merged; let me remove that comment

12:12 < rcurtin> originally the implement was wrong in my code (and I commented it to make a note to myself) but I forgot to remove the comment when I finished

12:19 < ShikharJ> rcurtin: Are you there?

12:23 < ShikharJ> I wanted to know if there is minimal way of building and testing a change in mlpack? Currently, whenever I type `make`, my system starts building the bindings as well, which is very slow.

12:34 < adl1995> ShikharJ: You can build a specific module of mlpack using "make <module_name>".

12:35 < ShikharJ> And would testing it the same way be sufficient as well?

12:36 < rcurtin> ShikharJ: you can reconfigure CMake with -DBUILD_PYTHON_BINDINGS=OFF and that will avoid building those

12:37 < rcurtin> and like adl1995 pointed out, you could do 'make mlpack_test' and this will build the test only

12:39 < ShikharJ> Thanks.

12:46 < zoq> adl1995: Just replied to your questions via mail, hope it's helpful.

12:54 < adl1995> zoq: Thank you! I'm reading up on the different PSO variants listed in the paper you mentioned.

13:30 < rcurtin> I got a little news about masterblaster... many people are being laid off in Oregon so there are fewer people to look into this issue

13:30 < rcurtin> the person I managed to talk to yesterday suggested that it is a comcast networking issue (since that seems to be where 200+ms of extra latency is being added)

13:30 < rcurtin> I asked if he would then go talk to comcast to get the issue resolved, and he said "I will have to check with my manager" and I haven't heard back

13:30 < rcurtin> so I'll be escalating that today...

14:20 < zoq> rcurtin: Thanks for the update, hopefully the issues get's resolved in the near future.

16:09 < travis-ci> ShikharJ/mlpack#4 (Test - 64d7a89 : Shikhar Jaiswal): The build failed.

16:09 < travis-ci> Change view : https://github.com/ShikharJ/mlpack/commit/64d7a8961da3

16:09 < travis-ci> Build details : https://travis-ci.org/ShikharJ/mlpack/builds/329842325

17:01 < manish7294> Hello everyone, Is there any way in boost to catch fatal error exception thrown by BOOST_REQUIRE_EQUAL call. Or any idea to check that two matrices are not equal using boost.

17:06 < manish7294> Is there any way to disable Boost fatal error log

17:09 < rcurtin> manish7294: I'm not sure quite what you mean, maybe you are looking for the CheckMatrices() function in test_tools.hpp or BOOST_REQUIRE_THROW()

17:09 < rcurtin> ?

17:09 < rcurtin> but I think you are already aware of those, so maybe I misunderstood the question

17:09 < rcurtin> I have to step out for lunch, I'll be back in a little while

17:10 < manish7294> rcurtin: I am using that BOOST_REQUIRE_THROW() is doing it's work but logs are not being disabled using log::Fatal.ignoreinput

17:12 < manish7294> rcurtin: I just want to disable the logs from BOOST_REQUIRE_EQUAL(a,b) when a and b are not equal.

17:13 < manish7294> rcurtin: Sure, have your time.

18:23 < rcurtin> manish7294: I'm not sure about that one, I don't think I've done that before... maybe check the boost UTF documentation?

18:24 < rcurtin> if Log::Fatal.ignoreInput = true, then there should be no [FATAL] output... if that doesn't seem to be working, I would suggest that maybe the fatal message is coming from before when ignoreInput = true is being specified

20:17 < dj> In file /src/mlpack/methods/ann/layer/concat.hpp . I am trying to generalize the matrix data type. Issue #1062. I added additional template ElementType to the class itself. So that we can specify the type of layer. By specifying Element Type we can remove additional template eT for Forward, Backward and Gradient functions. This way, parameters and delta would be of type ElementType. Is this approach correct?

20:25 < zoq> dj: You can already use InputDataType and OutputDataType to spcifiy the type. So I'm not sure I see the difference in using ElementType. However, I see that sometimes we use arma::mat e.g. to return the InputParameter that should be changes.

20:25 < zoq> The main problem is https://github.com/mlpack/mlpack/blob/master/src/mlpack/methods/ann/layer/layer_types.hpp where each layer is defined to use arma::mat. But we like to change that so that someone could e.g. build a network using Linear<arma::Mat<float>, arma::Mat<float> > instead of Linear<arma::mat, arma::mat>.

20:26 < zoq> One option might be to add Linear<arma::Mat<float>, arma::Mat<float> > to the variant, another option is to use some clever template trick to achive the same.

20:29 < zoq> You can use:

20:29 < zoq> FFN<> model;

20:29 < zoq> model.Add<Linear<arma::Mat<float>, arma::Mat<float>>(10, 50);

20:29 < zoq> as a simple test, if this compiles the solution works.

20:38 < dj> zoq: Thanks for the insight. I will see what i can do.

20:38 < zoq> dj: Great, let us know if we should clarify anything.

20:38 < dj> zoq: Sure.