-
Notifications
You must be signed in to change notification settings - Fork 719
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added Manhattan MST #138
Added Manhattan MST #138
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great!
I actually switched back to integers so no floats necessary :^) Besides, the only floats that would be used are absolute differences in the floating point values and adding them together, so I don't think we need to worry about it much. |
Well, there's still a note in the description about floats. If you remove that note I can remove the scary-looking label. :) (My worries re floats here are if float imprecision caused segments to be skipped based on a "there are better candidates" argument, and those skip-in-favor-of ended up circular. I'd need to understand the algorithm to determine whether that can actually be the case.) |
Alright, shortened the documentation. Technically I removed the reference to floats :^). If you still wanna check it out for float correctness, feel free. I'm pretty sure it'll be fine though - the points are never modified and the only operation made to them that could introduce FPE in the algorithm is |
The main API decision to make here is whether we want to include MST within the implementation or to just return the set of candidate edges.
If we want to include the MST within the implementation, then I think we should include the MST code inside the notebook elsewhere and call it from here.