I’m moving the discussion here to avoid hijacking the original thread:
I’m going to write down some guidelines later this week for standards for both reviewing and writing pull requests for the Math library this week. This should manifest as an updated PR template and wiki in the Math library.
I haven’t written it out yet, but welcome any / all feedback as it gets written. I know that the quality of review seems (or is) arbitrary (for example, see comments or a recent pull request ). Some things have to be open to interpretation, but hopefully we can settle on what…
@syclik decided that we can test the forward mode implementations an rely on the interactions, which should hugely simplify the testing going forward.
Pending a full audit, my understanding of where testing is at now:
everything is reasonably well tested in rev mode
all of the core functionality (built in arithmetic operators, +=, etc.) is tested in fwd and mix
all of the vectorized unary functions tested in rev, fwd, mix, which includes most of the C++ libraries
all of the univariate probability functions have been tested
That leaves:
multi-argument scalar functions
multivariate functions (i.e., matrix and array functions)
multivariate probabiltiy functions
I’m not 100% sure about the probability function test coverage and whether that includes cdfs, ccdfs, etc.
1 Like
great, thanks for showing explicitly what needs to have fwd tests done, this eliminates some random walk behavior on my part. There is still a lot of work I want to do for stan’s GP library, but I’m happy to start throwing in some tests for fwd once some of the gp kernels are added to the language and sepcialized for rev.
I’m going to learn type-parameterized unit tests and test fixures , and that should make this job go smoothly.
I’m not sure what you mean by
Do you mean, interactions of different vector datatypes, fvec and rvec? I’m not sure how this would simplify the testing.
1 Like
I meant interaction of fwd and rev rather than testing mix mode.