Optimize walking distance#7
Merged
Merged
Conversation
Records edge dependencies and uses that information to reorder edges in the edge sequence as long as the path length is reduced. This version calls the new method only on the final plan, since it is slightly slower than the original 'improveEdgeOrder'.
Childless "exterior" triangles can be completed in any order. If the triangle has children, make sure to complete the edge opposite of the final vertex early (not as the last edge). Otherwise the greedy optimizer might move the completion of that edge last, causing two (or more) triangles to be constructed at the same side of the edge at the same time. This usually shaves off some additional percents of the total route length.
- Improve speed of path length calculation using numpy operations - Ignore numerical inaccuracy "improvement" in path length - path length improvement: don't test some hopeless moves
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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?).