Fix two issues regarding the PD Code of the Link class - #42716
Draft
soehms wants to merge 4 commits into
Draft
Conversation
implements new methods components, _normalize_pd and _is_pd_normalized. Furthermore, it rewrites _directions_of_edges
|
Documentation preview for this PR (built with commit 99bc0ca; changes) is ready! 🎉 |
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.
1. Currently, the
_directions_of_edgesmethod returns incorrect results if a link'spd_codecontains loops. Example:Here, the crossing involving the loop
[9, 10, 10, 11]appears three times as aheadand only once as atail. The implementation calculates the position of an edge within the crossing usingindex; however, this function never returns the second position of the10within the crossing.2. The PD-Code generated from the braid and DT notations does not strictly adhere to standard conventions (such as those explained at KnotInfo).
This poses a problem when these PD-Codes are used as input for other programs (such as Khoca) that implicitly assume that consecutive segments of a component are labeled with consecutive numbers.
The following is implemented
components, which explicitly returns the components of a link as lists of edge labels derived from the PD code._directions_of_edgeswhich fixes the first issue, innumber_of_componentsas well as in two new internal methods (_is_pd_normalizedand_normalize_pd), which assist in calculating a normalized PD code of a link given in braid or DT notation.__init__to alert the user to non-normalized PD inputs.📝 Checklist
⌛ Dependencies