I initially changed it to allow faster (flat) tracebacks *during*
front evolution, but it turned out not to be necessary. Putting back
to minimize the changes of this PR.
Also fix in existing test related to how the traceback arrays is initialized:
first it was initialized with all -1, now with -2, and -1 at the seed points.
Also renamed Mcp_Connect to MCP_Connect.
Makes more sense to call it when the neighbor is frozen. In that
way the method is called exactly once for each pair of neighbours.
Plus the costs and paths are known and fixed.
This class adds a public def-method for the private cdef-method hooks.
This allows users to influence the behavior of the MCP algorithm by
subclassing it in pure Python.
This class finds the connections between the given seed points. This is
a bit similar to finding connections between start and end points, except
now start- and endpoints are the same.
Installed a few hooks to allow more flexibility in subclasses, refactored
traceback() to allow obtaining tracebacks fast during front evolution, and
moved some initializations to reset().
Full list:
* integer division in calculating indices
* traceback_offsets use -2 for uninitialized, -1 for seed point. In that
we we can distinguish between these two cases in traceback()
* Clearing of traceback_offset, cumulative_costs, pushing start positions
into the heap, are now all done in reset()
* Reset is called every time that find_cost is called.
* Add hook _goal_reached()
* Add hook _examine_neighbor()
* Add hook _update_node()
* Replace while loop with a for-loop to prevent infinite looping in case of a bug.
* Split traceback() in two functions to allow getting a flat traceback fast.
traceback() calles these two private functions and behaves as just before.
Dear diary, I spend a whole day searching for why this implementation
of the MPC was slower then my own implementation. I checked *everything*.
I rewrote the front evolution to match with mine almost exactly. I was
about to give up. And then I saw this... Arg!
Tony S Yu