Should keyword arguments propagated to DiffEq always be an explicit keyword `diffeq`?
Datseris opened this issue · comments
So, when I first wrote trajectory, I thought it was a nice convenience to be able to propagate keywords directly to differential equations, e.g. trajectory(ds, 100; alg = Vern9(), abstol = 1e-9). As more complicated functions entered the library, that had many keyword arguments, I realized that it is a bit too much to allow so many keywords. This replaced the keyword propagation with having an explicit keyword diffeq which is a named tuple or dictionary, and this itself is expanded into the DiffEq solvers. E.g. basins_of_attraction(ds, grid; diffeq = (alg = Vern9(), abstol = 1e-9)).
The problem now is that some functions do automatic propagation, while some others expect diffeq options as an explicit keyword diffeq. This is not very harmonious :( I'm thinking that it is better to switch things and make the diffeq keyword an explicit keyword in all functions and never allow direct propagtion (i.e., there should be no function in DynamicalSystems.jl that can take alg as a keyword).
(this won't be a breaking change of course, but rather a deprecated warning).
What is the consencous? Put a thumbs up here if you agree or a thumbs down if you disagree.
I'm hoping more downstream libraries do this because I want to start warning if DiffEq gets incorrect arguments. Since named tuples exist we should use them.