You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For vectorized functions, the way we represent data (N.n_x ) with each line corresponding to an observation is not well suited to the computation we made given that arrays are F-ordered.
It would be good, if we could have the option of using the opposite convention and use input/output as (n_x . N) matrices (with the jacobian J: n_x.n_x.N without switching the two first dimensions).
Given the way the library is structured, this option could be provided at low cost, by introducing an option to the generated functions so that g(s,x,p,Forder) (resp g(s,x,p,Corder)) would assume the arguments are in the new (resp the old). It seems to me all that would be required would be to add this option to _unpack_var (and the generated functions). We could keep Corder as default, so as to not break everything (even better raise a warning if no order is given) and later change the convention.
The text was updated successfully, but these errors were encountered:
An additional advantage is that arrays n_x.N can be reinterpreted as Vector{SArray{n_x,Float64}} and n_x.n_x.N as Vector{SMatrix{d,d,Float64,d*d}} which makes many things we do easier and more efficient. We could also provide an API accepting this types of arguments. Then we could also potentially use static arrays within Dolang. I suspect though we would quickly get into more complicated questions, like what we do with higher order derivatives, with high dimension jacobians, etc... If the goal were to speed up performances, we shouldn't do that unless we know for sure it will bring some and there aren't better solutions (like just using @devec).
So, as for me, the option to change orientation seems the better option for now and I'm not sure we need to care about accepting StaticArrays as inputs (appart maybe from a basic wrapper that would perhaps even check sizes).
For vectorized functions, the way we represent data (
N.n_x
) with each line corresponding to an observation is not well suited to the computation we made given that arrays are F-ordered.It would be good, if we could have the option of using the opposite convention and use input/output as (n_x . N) matrices (with the jacobian J: n_x.n_x.N without switching the two first dimensions).
Given the way the library is structured, this option could be provided at low cost, by introducing an option to the generated functions so that
g(s,x,p,Forder)
(respg(s,x,p,Corder)
) would assume the arguments are in the new (resp the old). It seems to me all that would be required would be to add this option to_unpack_var
(and the generated functions). We could keep Corder as default, so as to not break everything (even better raise a warning if no order is given) and later change the convention.The text was updated successfully, but these errors were encountered: