rcurtin_irc changed the topic of #mlpack to: mlpack: a scalable machine learning library (https://www.mlpack.org/) -- channel logs: https://libera.irclog.whitequark.org/mlpack -- NOTE: messages sent here might not be seen by bridged users on matrix, gitter, or slack
<zoq[m]> Looks like I will open another PR, to fix some unstable tests.
<rcurtin[m]> thank you for putting time into that! it can be really frustrating to hunt them all down
<rcurtin[m]> those GMM EM tests have haunted me for years 😭
<zoq[m]> Yeah, but probably a good idea get that one more stable.
<zoq[m]> But before that trying to figure out the ensmallen issue.
<jonpsy[m]> Hey zoq
<jonpsy[m]> hi i see you're up
<jonpsy[m]> So I was looking through ```Backward``` function right?
<zoq[m]> right
<zoq[m]> Correct, unless you have a recurrent neural network or some network with multiple loss functions.
<zoq[m]> Inception net comes to mind.
<jonpsy[m]> I see
<jonpsy[m]> do you recall why we created ```ffn_eql.hpp``` instead of just adding another method to the `ffn` class?
<zoq[m]> No, I think the other way might be even simpler.
<jonpsy[m]> the latter?
<zoq[m]> Adding the method to the existing `FFN` class.
abernauer[m] has joined #mlpack
<jonpsy[m]> okay so
<jonpsy[m]> <jonpsy[m]> "do you recall why we created..." <- I think i realize why we did this
<jonpsy[m]> we calculate loss like this: `const double homotopyLoss = (1 - lambda) * lossA + lambda * lossB;`
<jonpsy[m]> but we need to aneal the `lambda` parameter, so we stored it as a state in `ffn_eql.hpp`, should i store `lambda` in `EQL` class and pass a `std::function` to anneal it?
<jonpsy[m]> * `std::function` to `FFN` to anneal it?
aryaman has joined #mlpack
aryaman has quit [Client Quit]
<jonpsy[m]> @me when you're back?
<zoq[m]> I see, so that means we have to duplicate quite a bit of the functionality of the FFN class.
CaCode has joined #mlpack
<jonpsy[m]> instead we can use this handy trick I learnt from shogun, create a std::function, capture `Lambda` by reference. Call the std::function in the `ffn` class, it will automatically update it in the `EQL` class.
<zoq[m]> Or just use inheritance, or `friend`.
fusta has joined #mlpack
CaCode has quit [Ping timeout: 268 seconds]
<jonpsy[m]> <zoq[m]> "Or just use inheritance, or `..." <- I think we ruled out inheritance because we could handle it inside ```ffn_impl.hpp``` directly.
<jonpsy[m]> created a new interface like [this](https://pastebin.com/TaC8N7rG)
<rcurtin[m]> I know our refactoring of the FFN class is going quite slowly, but the more you can "separate" the new functionality, the easier it will be to port it to the new inheritance-based `FFN` class :)
<zoq[m]> Yeah, I guess right now we only add new functions and don't adjust the interface.
<jonpsy[m]> hmm.. so now I should inherit from FFN class?
<jonpsy[m]> and implement the new interface there?
<zoq[m]> Probably the easiest to merge the feature with the ongoing refactoring.
<jonpsy[m]> jonpsy[m]: so this is greenlit right?
texasmusicinstru has quit [Ping timeout: 268 seconds]
texasmusicinstru has joined #mlpack