> Assuming it's not easy to cast the input array to the float32 type,
> because I'm guessing it will be called with int arrays if not
> explicitly stated, can I suggest changing the documentation like:
> costs : (M, N) ndarray of float32
This limitation might just be due to my relative inexperience with
cython... Would it be better to have two identical functions, one
which takes int costs and one with float costs (and then maybe a
python wrapper function that selects between the two), or to write it
so that it casts to float internally?
For that matter, is there a "safe cast" function that would, say,
upcast ints to float32, but would complain about trying to cast
float64s to float32? Or just better to document and let the user deal
with the constraint?
> Also, can I suggest a returns section like this:
> tuple : (costs, paths)
> ``costs`` is an (M, N) ndarray of float32 of cumulative
> costs from the starting point
> ``paths`` is a list of paths where each path is a list
> of ``(x, y)`` positions ordered from the start to each
> end point
Thanks for helping get this in shape, Gary and Stéfan!