My own feeling about these docs is that they’re way too scattered. We’ve probably said everything multiple times in various places but it’s hard to consolidate. At the same time, there’s only so much room at the top of our doc and other web pages. Any organizational hints as to how to fix these problems would be appreciated!
Nope. Not even close on either count. We have programmers who’ve only ever touched R. The matrix functions introduce tricky memory management issues for the operands.
If you really want to procrastinate, work on the web site! It’s just another GitHub repo.
The Wiki’s super easy to edit. The problem we run into is where to put all these things. We should at least have this one in the top-level directory.
These aren’t technically asserts.
assert() is something built into C/C++ that we don’t use. We (try to) throw exceptions with meaningful messages that get reported back to the user.
This gets particularly tricky to doc as the same thing goes for just about every source code file. Partly you just have to look at other files like the ones you’re using. Or we could write up some doc on all the tests. One thing that needs to be done is generalizing all the tests to vectors and matrices—the coverage is currently spotty.
The doxygen doc is written for users of the function, not coders. We explicitly don’t want the doxygen doc to contain implementation details (except about high-level algorithmic issues that users need to know).
Yes, it’s a macro. It’s from
googletest: https://github.com/google/googletest They have lots of doc on how it all works. It’s a pretty extensive package and we use a lot of it and we’re not going to just doc it all again. But feel free to include a link from one or more places you think would be helpful.
Just add these things where you think they should go. It’s a wiki.
Not sure what you mean here. Did you want a pointer to Giles’s papers on matrix autodiff?
Definitely something we should add. I thought the arXiv paper covered that, but maybe not. The no_chain stack is just a stack of variables whose
chain() methods are not called during autodiff. So you can build up variables to hold results and instead of calling their
chain() method, do the work in another
vari's chain method. The reason this is so useful is that it converts a ton of virtual function calls through the autodiff stack (basically interpreted code) into a single function (essentially compiled code).