05:48 < ShikharJ_> zoq: I was looking at the implementation for Deconvolutional layers from this paper (https://arxiv.org/abs/1603.07285).

05:49 < ShikharJ_> It seems that for every transpose convolutional operation, there exists a corresponding convolutional operation, which can be computed from the mentioned equations.

05:50 < ShikharJ_> Do you think, we should try and just compute the corresponding convolutional operation first and directly pass over the work to the existing convolutional layer implementation?

05:51 < ShikharJ_> That way, we could prevent a lot of code duplication in my opinion, but under the skin, it would essentially be the existing code that does the work.

05:54 < ShikharJ_> Otherwise, we could also try and implement Deconv layers as a standalone feature (I'm guessing this would be a faster thing to do, as we don't have to create a Conv layer instance). What would you prefer?

06:53 < travis-ci> ShikharJ/mlpack#117 (RBM - 93e3154 : Shikhar Jaiswal): The build has errored.

06:53 < travis-ci> Change view : https://github.com/ShikharJ/mlpack/compare/fe8ecee28bf4...93e3154e6752

06:53 < travis-ci> Build details : https://travis-ci.org/ShikharJ/mlpack/builds/373359719

07:23 < travis-ci> ShikharJ/mlpack#118 (GAN - 110ebf4 : Shikhar Jaiswal): The build has errored.

07:23 < travis-ci> Change view : https://github.com/ShikharJ/mlpack/compare/ecd920b38889...110ebf413944

07:23 < travis-ci> Build details : https://travis-ci.org/ShikharJ/mlpack/builds/373360640

10:08 < travis-ci> ShikharJ/mlpack#119 (Deconv - 00d7cd5 : Shikhar Jaiswal): The build has errored.

10:08 < travis-ci> Change view : https://github.com/ShikharJ/mlpack/commit/00d7cd5b20c4

10:08 < travis-ci> Build details : https://travis-ci.org/ShikharJ/mlpack/builds/373389112

10:17 < zoq> ShikharJ_: I would implement it as an independent layer, we might be able to internally use the conv method (not the conv layer).

10:23 < ShikharJ> zoq: Do you think that the Deconv class should inherit from Conv class in that case? I am thinking along the lines of instantiating the Conv class from the constructor of Deconv class (and subsequently using its Forward and other routines).

10:26 < zoq> Idally we could avoid Inheritance, see https://github.com/mlpack/mlpack/wiki/DesignGuidelines#inheritance which might be unnecessary here since the muliplication is the main part, but at least we could try.

10:26 < zoq> What do you think if we just use the conv rule.

10:28 < zoq> We still have to reimplement some code, but I think we can't get away with it without inheritance.

10:30 < ShikharJ> Yeah that should work fine as well, implementation-wise it should be the fastest way to go. I'll give it some thought and let you know on the PR.

10:32 < zoq> Sounds perfect.

12:28 < travis-ci> ShikharJ/mlpack#120 (Deconv - 9e5d20a : Shikhar Jaiswal): The build has errored.

12:28 < travis-ci> Change view : https://github.com/ShikharJ/mlpack/compare/00d7cd5b20c4...9e5d20a54d79

12:28 < travis-ci> Build details : https://travis-ci.org/ShikharJ/mlpack/builds/373429447

16:09 < manish7294> rcurtin: The det "Pathcatcher class multiple definition" error, is because of inclusion of det_utils in both det_test and det_main.cpp. Though det_test doesn't uses det_utils..

16:10 < rcurtin> that's strange though, is there some non-templated function that isn't marked 'inline' in dt_utils.hpp?

16:17 < manish7294> rcurtin: Yup, there are several!

16:20 < rcurtin> manish7294: ah, that is our problem, I see now

16:20 < rcurtin> either we should mark those functions 'inline', or move the implementations from dt_utils_impl.hpp to dt_utils.cpp (and update the CMake configuration to also compile dt_utils.cpp)

16:21 < rcurtin> (I have no preference for which way is better)

16:22 < manish7294> rcurtin: Right! Those are the same functions for which error is occuring. I think inline will suffice.