betanalpha
commented
9 years ago I think Extensions and Dependencies organization can be done concurrently, (C++ and Eigen being base dependencies, then additional “plug-ins” for Boost, ODE, etc) which leaves the question of the others.
I personally like having Purpose be the main categorization (with basic scalar functions/operators, special scalar functions/operators, matrix scalar/functions, and distributions being separate “Purposes”), with the different implementations all being in the same location in order to make it easier on developers (all exp implementations are in one place, for example).
But that’s just me.
Also recall that the plan is to pull all of this out into a separate autodiff repo, We can call is StanADE (the Stan Automatic Differentiation Engine ;-) ).
On Jan 19, 2015, at 10:05 PM, Bob Carpenter notifications@github.com wrote:
Current Code Features
I see five cross-cutting ways our math and autodiff code can be categorized:
Type
primitive reverse mode autodiff forward mode autodiff mixed mode autodiff Shape
scalar array (std::vector) vector/matrix (Eigen::Matrix) Purpose
functions and operators error handling meta Extension
built-in operators (e.g., operator+ and operator+=) standard library functions (e.g., exp) special functions (what is now in math) probability functions (what is now in prob) transforms distribution functions: prob function, (c)cdf, rng Dependencies
None C++ std lib Boost Eigen ODE solver? RNG? Reorganization Plan
Directory Structure
I think what would make most sense is to have the following directory structure:
stan/primitive/{scalar/, array/, matrix/} stan/agrad/rev/{scalar/, array/, matrix/} stan/agrad/fwd/{scalar/, array/, matrix/} stan/agrad/mixed/{scalar/, array/, matrix/} Then the meta and error-handling utilities can be included in the same directory as the function definitions.
Right now, we use math instead of primitive, but really all of Stan is math in some sense other than the language parser and I/O stuff. I'm open to alternatives to primitive, or even sticking with math if people think it's simpler or clearer.
Include Files
Every file should include only what it uses (there's another issue for just this).
We can cross-cut the file directory structure with the inlcude files. For example, there can be an include just agrad/rev/scalar and primitive/scalar for a kind of minimal autodiff. Or even more narrowly, something even more minimal with only the built-ins redefined.
Should agrad functions build-in primitive includes?
Namespaces
I'm a little less clear on what would be ideal here. At one extreme, everything can just go in stan, that is, just one top-level namespace. That'd probably be enough for all of our argument-dependent lookup to work.
At the other extreme, we could keep math, prob, and agrad namespaces separate, but that introduces issues with argument-dependent lookup for probability and math namespace functions that can take autodiff arguments.
ODE Solver and Dependencies
I'm also less clear on where the ODE solver should go. Or what to do about having include files with limited dependencies.
Do we need to have a version of agrad that works without Boost? We use Boost a lot, primarily for special functions and traits-based metaprogramming.
I think we'll have Eigen relatively well isolated.
— Reply to this email directly or view it on GitHub.
syclik
bgoodri
Current Code Features
I see five cross-cutting ways our math and autodiff code can be categorized:
Type
Shape
Purpose
Extension
Dependencies
Reorganization Plan
Directory Structure
I think what would make most sense is to have the following directory structure:
Include Files
We can start a new include directory parallel to
srcthat has cross-cutting includes that clients might want. For includes, we want the following properties:Namespaces
I'm a little less clear on what would be ideal here. At one extreme, everything can just go in
stan, that is, just one top-level namespace. That'd probably be enough for all of our argument-dependent lookup to work.At the other extreme, we could keep math, prob, and agrad namespaces separate, but that introduces issues with argument-dependent lookup for probability and math namespace functions that can take autodiff arguments.
ODE Solver and Dependencies
The ODE could go in with other functionals. The problem is that this leads to a requirement that we include the ODE dependent libs (e.g., Sundials or lsoda) in order to build whatever they're contained in.