callable paths

[marcelvangerven]

Paths now use path.evaluate(). It would be more useful to use a call method instead. This is more in line with the other classes and allows us to use other callable control inputs that need not be derived from AbstractPath.

[patrick-kidger]

This was a deliberate choice, as it felt more natural (at least to me) to have evaluate and derivative methods, rather than __call__ and derivative methods.

In reality the derivative method isn't used that much, so if I was to do this again then indeed I would probably implement just AbstractPath.__call__ and let users invoke jax.jvp to obtain the derivative. (As AbstractPath.derivative currently does.)

[gerlero]

@patrick-kidger Regarding this, would you be interested in a simple PR that adds a __call__ method to solutions?

I see that #604 would also add __call__ methods, but I’m not sure whether that will be merged soon. I guess one could use a #604-compatible API for __call__ just in case (e.g. by making t1 and the rest of the arguments keyword-only)…

[patrick-kidger]

So #604 is on my radar -- I'm not sufficiently happy with the changes it brings, but I am hoping (eventually) to find the time to accomplish its goals a different way.

So at least right now I'd like to stick with .evaluate. This is so that we can leave __call__ free in case we need a different API later.

[gerlero]

Fair enough! Thanks