Since improveEdgeOrder is called several times in a loop, I put the new code in a new function, improveEdgeOrderMore, that is only called once on the final plan. This doesn't affect the running time of the program as much, but also may give slightly poorer results (the triangulation chosen with the improveEdgeOrder metric may not be the one giving the best result with improveEdgeOrderMore).
This still seems to make the path much shorter no matter what the triangulation actually is, so no harm there (perhaps the attempts loop could optimize on something else besides the path length again?).
This is a variation of the pull request #2.
Since
improveEdgeOrderis called several times in a loop, I put the new code in a new function,improveEdgeOrderMore, that is only called once on the final plan. This doesn't affect the running time of the program as much, but also may give slightly poorer results (the triangulation chosen with theimproveEdgeOrdermetric may not be the one giving the best result withimproveEdgeOrderMore).This still seems to make the path much shorter no matter what the triangulation actually is, so no harm there (perhaps the
attemptsloop could optimize on something else besides the path length again?).