clarify interface to path finding function

[jkfurtney]

The current optimal_path_2d() documents an interface for the path finding capability. There are a few problems.

• only square arrays work
• there is redundancy in specifying both dx and coords. Probably we want to construct coords from dx.

Once we settle the function interface we can write other path finding implementations which conform to this interface. Then we can run the same test cases on the various implementations.

[wmoebius]

What do you think about the interface of optpath_eulerforward? Additional options could specify max step number (which I haven't used yet).

[jkfurtney]

This looks good to me. I recommend that the startingpoint argument be renamed startingpoints and be a sequence of starting points. This way you can get several paths without recalculating the interpolation weights. Yes, an optional argument of maximum_steps would be a good idea.

[jkfurtney]

Maybe we should add another optional argument which gives the maximum arc-length between points reported back by the path finder? Have a look at brachistochrone_test.py:

The black dots are the results from the scipy integrator. For some applications one may want more detail about the path?

Nice work on using the scipy integration functions to find the path, very clever. This seems like the way to go, it is more accurate than the fixed step Runge-Kutta integrator as you can see here:

The light blue line is the exact solution, the red dots are the RK integrator and the white dots are the FE integrator.

Regarding speed, we should be able to cythonize rhs and solout. There may also be ways to make a pure-python solution faster? What are your thoughts on adding a c extension module? (as Cython would require this.) It definitely makes distributing the code more difficult.