Skip to content
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

Explaining a comment #152

Open
dbuenzli opened this issue Jul 19, 2022 · 2 comments
Open

Explaining a comment #152

dbuenzli opened this issue Jul 19, 2022 · 2 comments

Comments

@dbuenzli
Copy link

Hello,

Not an issue per se but the explanation of a comment.

I was reading your implementation and saw this comment here. The implementation of this part of the algorithm is quite convoluted in the reference implementation (available here which I believe this is a mirror on github). I haven't fully wrapped my head around yet…

The reference implementation uses indices 2 and 1 here. But if you are here in the code, left points coincide, this means you went through this line which pushes a 0 (NULL) at index 0, before the events.

In your code you track this via a boolean, not a NULL value in the events array. So this is why 1 and 0 are the correct values in your implementation, your events are not shifted to position 2 and 1 by a NULL value. :-)

@w8r
Copy link
Owner

w8r commented Jul 19, 2022 via email

@dbuenzli
Copy link
Author

dbuenzli commented Jul 21, 2022

Cool.

Btw. one thing I noticed is that both the reference implementation and this implementation do not compute the topological information for the result (holes + contour winding) when the operation hits one of the trivial paths.

I guess this may surprise users of the API which may expect to have that in the result.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants