So I run rev/fwd tests for scal/fun/gamma_p and they pass.
Then the mixed test fails. I added prints to the point that I can tell bvi->adj_
is zero when the gamma_p_vv_vari
is constructed but by the time the chain()
method is called it has turned into -nan
.
I can see that gamma_p(fvar<var>, fvar<var>)
gets called in between but everything I have access to and everything calculated in it is fine.
I’m not sure what else would get called in between those two points.
Any suggestions what I could look into? This is my first time digging into the mixed mode stuff so it’s a steep learning curve. I made quite a few changes in getting the rev/fwd tests to pass but when I instrument those with prints everything comes out fine and scanning the changes I don’t do anything exotic but I’m clearly missing something.
Also, this is the test:
TEST(AgradFwdGammaP, FvarVar_FvarVar_1stDeriv) {
using stan::math::fvar;
using stan::math::var;
fvar<var> x(0.5001,1.0);
fvar<var> z(1.0001,1.0);
fvar<var> a = stan::math::gamma_p(x,z);
EXPECT_FLOAT_EQ(boost::math::gamma_p(0.5001,1.0001), a.val_.val());
EXPECT_FLOAT_EQ(boost::math::gamma_p_derivative(0.5001,1.0001) - 0.3898178624664172, a.d_.val());
AVEC y = createAVEC(x.val_,z.val_);
VEC g;
std::cout << "a.val_: " << a.val_ << std::endl;
std::cout << "a.val_.val(): " << a.val_.val() << std::endl;
std::cout << "a.d_.val(): " << a.d_.val() << std::endl;
a.val_.grad(y,g);
std::cout << "Just called." << std::endl;
EXPECT_FLOAT_EQ(-0.3898178624664172,g[0]);
EXPECT_FLOAT_EQ(boost::math::gamma_p_derivative(0.5001,1.0001),g[1]);
}
I’m going through and instrumenting everything with a general autodiff test framework.
Until then, I’d suggest testing with the autodiff functionals (like gradient()
and hessian()
, each of which has a matching finite diff version). Then you don’t need to mess around with any of the internals.
These are existing tests and there are a lot of them so rewriting them
doesn’t seem like a great plan. What’s worrying me is that it wasn’t
returning nan before but I can’t track the change down because none of the
things I instrumented are causing the problem. I’m missing whatever call
is screwing stuff up. I’ll just redo the PR piece by piece and track the
problem down that way sometime next week.
@sakrejda Didn’t you find a problem in the math library a couple weeks ago that appeared cause you were using a super up to date compiler? Is it possible this test was working on a previous compiler but not the new one?
Good suggestion, I’ll have time later this week to check, not sure at the
moment.
I’m going to rewrite all the tests within the new framework I’m developing. It reduces to a class wrapping the function and all the input/output pairs you want to test for values and all the inputs that cause errors. So it makes the code much much shorter.
But that’s not going to help with the immediate pull request unless these are simple binary functions with univariate output.
We already have the unary functions tested with the vectorization framework and I’m going to knock off all the functions with univariate output, then go on to the multivariate outputs, then the probability functions.