Is there any reason we are not mandating it be ordered type?
ordered type is a constrained type for block-level variables, but you can pass local variables to this function as well.
Also, the times in the integrate_ode functions are real arrays (real[]). The ordered type maps to vector.
In C++, the current implementation takes std::vector and not Eigen::Matrix.
I see. Thanks.
Since we are checking ts to be ordered anyway, I’d think using ordered type is more straightforward.
It’s not something that can be enforced. Bob’s written it up in Section 3.1, “Overview of Data Types.” (in the v2.17.0 version of the manual). Here’s the relevant sentence:
Arguments for built-in and user-defined functions and local variables are required to be basic data types, meaning an unconstrained primitive, vector, or matrix type or an array of such.
In this context, constrained vectors are things like ordered or simplex, and unconstrained vector is vector. There’s a little more information in Chapter 3 that might be useful to understand. The manual wasn’t designed to describe how the Stan types map to C++ types, but hopefully understanding how it maps makes this section a little clearer.
1 Like
Yes. Your quote really makes it clear. Thanks.
The reason it’s like this is because that’s all the type checking that’s available in the language. So you couldn’t write a function that applies to an ordered vector and one that applies to a simplex and does different things—they’re both just vectors underlyingly.
The built-in functions and the user-defined functions work the same way here. You can pass any-old matrix in as the covariance matrix in a multivariate normal. But the function will check that it’s positive definite along the way and throw an exception if it isn’t.
Now what we could do is allow constrained function arguments with the understanding that they’re just proxies for doing tests on arguments. They wouldn’t determine which function to call statically, they’d just be used for error checking.