-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Julia: Switch array orientation #42
Comments
An additional advantage is that arrays n_x.N can be reinterpreted as 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). |
@sglyon : any comment ? |
Sorry for the delay. I think your proposal is very sound and flexible. I like it. I will try to find time to implement this soon, but I can't promise exactly when... things are extra busy right now |
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: