is a Functor better than repeated closures? about dynamicalsystems.jl

[ChrisRackauckas]

I pretty much always use callable types for this, except in cases where I know I want to change the enclosed types due to dual numbers. One thing I have to note is that supporting it as .F makes it less generic, which can be rough to deal with with optimizers (requiring code looping over or generating over getfield). These days I like everything being uniform via ParameterizedFunction(f,params), which is a callable type that encloses a function, and sticks all of the parameters into one thing. If the user wants names for parameters, they can use something like a NamedTuple to hold the parameters, or you can do that behind the scenes here.

[Datseris]

I haven't perfectly understood you, which makes me think I probably was not clear enough.

First things first: DynamicalSystems will not care about the parameters or change them internally. Why are you saying that .F makes it less generic? This will only ever be done from the users, e.g.:

using DynamicalSystems
ds = Systems.lorenz() # this is a line from the package
for β in 2:0.1:10
ds.eom!.β = β # this is NOT from the package
λ = lyapunov(ds, 10) # this a line from the package
end

Secondly, to use ParameterizedFunction I would have to do an explicit interfaces that allows for one extra argument (params) for any function call. Or not? Because if I use pf.p = ... (as in the documentation for ParameterizedFunctions`, then is this any different than the above case?

Thirdly, how will ParameterizedFunction avoid this optimization obstacles that you mentioned (if it does). Is it worth it here for my case? I read through the README, but it is not so obvious to me as to which are the advantages of using pf in the current case. Of course it is obvious for DiffEq since parameter estimation is a big deal etc.

Thanks for the comments by the way! Appreciate it!

[ChrisRackauckas]

No, I wasn't saying you should used ParameterizedFunctions for this. I was saying a similar strategy (which is not the macro btw).

First things first: DynamicalSystems will not care about the parameters or change them internally.

Then .F and all of that is fine. Callable types is the right way to go then.

[Datseris]

Great thanks for the feedback. I was also thinking about it for months and I was always displeased with the current approach (the fact that change of parameter requires a direct re-construction of a type).

I will implement this now, and change all the example system and the docs. let's see how long it will take...

[Datseris]

On another note, do you still stand that for e.g. a Jacobian having something like pf(Type{Val{:jac}}, args...) is the way to go?

Since jacobians are also crucial, I was thinking allowing the users to do:

stuct Syststem
a::Float64
end
function (f::System)(du::Vector, u::Vector)
# here are eom
end
function (f::System)(J::Matrix, u::Vector)
# here is the jacob
end

I am aware that this cannot allow states that are matrices, but this is in general impossible for DynamicalSystems.

[ChrisRackauckas]

No, I am instead building a type for functions in the future.

https://github.com/JuliaDiffEq/DiffEqBase.jl/blob/master/src/diffeqfunction.jl
SciML/DiffEqBase.jl#52

It's very involved and likely overkill for your case.

[Datseris]

This is implemented and also the suggested behavior as of version 0.7