ChanServ changed the topic of #mlpack to: "mlpack: a fast, flexible machine learning library :: We don't always respond instantly, but we will respond; please be patient :: Logs at http://www.mlpack.org/irc/
< Roshan[m]>
So, the JacobianBernoulliDistributionTest is failing. I don't know why, it is giving output false. It looks for both "absolute difference" OR "relative difference". Here, none of them are actually passing the case.
< Roshan[m]>
how can I know on what values it failed the test cases?
siddhant_jain[m] has quit [Quit: Idle for 30+ days]
< jonpsy[m]>
any specific reason we have ```template<FunctionType, MatType>``` instead of ```template<MatType, FunctionType>``` ?\
< jonpsy[m]>
in ```function_tools.hpp```
< zoq>
jonpsy[m]: In this case the order defines what is changed more often.
< jonpsy[m]>
is this limited to function_tools.hpp only?
< jonpsy[m]>
or is the order spread through ensmallen, or worse, throughout mlpack?
< zoq>
We try to use this across ensmallen and mlpack, is there any problem you encounter whith the order?
< jonpsy[m]>
yep
< jonpsy[m]>
very very big problem actually
< jonpsy[m]>
remember our discussion of variadic. template recursion for MOO trait check? I would need ```FunctionType``` to be in the end for it to work :(
< zoq[m]1>
Not sure that is true if you iterate over it you should be able to reuse what is there. Maybe I miss something
< rcurtin[m]1>
jonpsy: if the arguments are in the wrong order and you need them in the other order for some template metaprogramming, it should be trivial to work around---or to simply write the code assuming that an extra parameter comes last
< rcurtin[m]1>
I did not look at the specific code, but based on what I read here there should be no issue
< jonpsy[m]>
Basically, since I'm using multiple functional types. Im utilizing parameter pack
< jonpsy[m]>
Problem is, we can't have typename after parameter pack (only fully defined types allowed).
< rcurtin[m]1>
okay, then write a shim to reverse the order
< rcurtin[m]1>
all this happens at compile time. I am certain you can work around the issue
< jonpsy[m]>
Yeah I got a solution
< jonpsy[m]>
I thought I could define MatType for each type
< jonpsy[m]>
I could use template specialization for each and every MatType. Annoying, but doesn't break the API. What's your thoughts? ryan
< rcurtin[m]1>
my thoughts are that we should not change the API. past that, do what you need. I suspect that this really should not be impossible at all, and perhaps not even that tedious (at least as far as template metaprogramming goes)
< jonpsy[m]>
Yep, I'll find something
< jonpsy[m]>
<jonpsy[m] "I could use template specializat"> This would work just fine without breaking pattern. But I'll try and find more neater :)