Skip to content
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

Open
albop opened this issue Sep 9, 2017 · 3 comments
Open

Julia: Switch array orientation #42

albop opened this issue Sep 9, 2017 · 3 comments

Comments

@albop
Copy link
Member

albop commented Sep 9, 2017

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.

@albop
Copy link
Member Author

albop commented Sep 9, 2017

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).

@albop
Copy link
Member Author

albop commented Sep 12, 2017

@sglyon : any comment ?

@sglyon
Copy link
Member

sglyon commented Sep 12, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants