Skip to content

Correctly compute path extents #16832

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

Merged
merged 1 commit into from
Apr 20, 2020
Merged

Conversation

brunobeltran
Copy link
Contributor

@brunobeltran brunobeltran commented Mar 19, 2020

PR Summary

Closes #16830 and #7184.

This code will be needed to implement MarkerStyle normalization correctly (building on the work now approved in #16773).

Roadmap:

#16812 (*) <- (This PR) (*) <- #16859 (*) <- #16888 <- #16889 (*) <- #16891 (MarkerStyle improvements!)

"<-" means "depends on", and "(*)" marks PRs whose implementations are complete and fully ready for review.

PR Checklist

  • Has Pytest style unit tests
  • Code is Flake 8 compliant
  • New features are documented, with examples if plot related
  • Documentation is sphinx and numpydoc compliant
  • Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
  • Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

@brunobeltran
Copy link
Contributor Author

I assume this doesn't count as a "major new feature"? If it does I'll add it to next_whats_new/.

@anntzer
Copy link
Contributor

anntzer commented Mar 19, 2020

Is the first commit elsewhere as a separate PR? If so please refer to it so that we can review things in order.

@brunobeltran
Copy link
Contributor Author

Is the first commit elsewhere as a separate PR? If so please refer to it so that we can review things in order.

Ooops, you're right. I got mixed up and thought it was the other way around.

This depends on #16812, which in turn depends on your #14199 being merged, which I just realized hasn't happened yet.

My bad.

@brunobeltran brunobeltran force-pushed the path_size_calc branch 4 times, most recently from dd3fec7 to 24b6d39 Compare March 19, 2020 17:57
@anntzer
Copy link
Contributor

anntzer commented Mar 21, 2020

Specifically for "stacked" PRs like this I would suggest squashing them to a single or a small number of commits cleanly on the top of the parent PR (or master, if the parent PR has been merged) to simplify the review. Otherwise it's too hard for the reviewer (well, at least for me) to keep track of what's done where.

@brunobeltran
Copy link
Contributor Author

@anntzer Thanks for the tip! I squashed all the PRs in this "stack" into one commit each, so you can review the relevant parts easily :)

Copy link
Contributor Author

@brunobeltran brunobeltran left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some comments that might be useful to the reviewer.

@@ -421,6 +432,54 @@ def iter_segments(self, transform=None, remove_nans=True, clip=None,
curr_vertices = np.append(curr_vertices, next(vertices))
yield curr_vertices, code

def iter_curves(self, **kwargs):
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did try to make iter_segments work first. But I found that here (and #16859, and upcoming PR on center of mass), I kept repeating this logic across each function I wrote so that I could get all the control points of each curve, so I went ahead and added this generator.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A problem is that naively you'd thing the difference between iter_segments and iter_curves is that one returns segments and the other returns curves, but actually it's something completely different: one excludes the start point of each segment/curve and the other includes it. So should this instead be a kwarg to iter_segments, e.g. include_starts?

Copy link
Contributor Author

@brunobeltran brunobeltran Mar 22, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy to make this a private helper method that is called by iter_segments when the parameter include_starts is passed, but I worry about bloating iter_segments with a bunch of options.

Especially because it's really obnoxious that .iter_segments() returns a flattened sequence of coordinate pairs, so in order to create the desired API (more importantly to not doom anyone using this code in the future to a lifetime of reshape calls), I'd have to add another parameter as well flattened=False which determines whether to flatten the (naturally (N,2)-shaped) array of control points before returning it.

Copy link
Contributor Author

@brunobeltran brunobeltran Mar 22, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, and currently, .iter_segments() returns a vertex that we're supposed to be ignoring (CLOSEPOLY) instead of correctly returning the first vertex of that stroke.

This is almost certainly a bug, but would probably want its own PR.

Adding the CLOSEPOLY bugfix, include_starts and flatten_vertices to iter_segments instead of just making a separate iter_curves makes the code significantly noisier, but if that's not as big of a priority as minimizing new API surface, I'm happy to do that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pushed up a new version where the generator yields BezierSegments and is named iter_bezier. I think this solves the problem that you (correctly) pointed out of the name .iter_curves not being intuitive, along with preventing me from having to make multiple, significant modifications to iter_segments.

@brunobeltran brunobeltran force-pushed the path_size_calc branch 3 times, most recently from 9dc3840 to f0571f0 Compare March 22, 2020 20:46
@tacaswell tacaswell added this to the v3.3.0 milestone Mar 22, 2020
@brunobeltran brunobeltran force-pushed the path_size_calc branch 2 times, most recently from 225b1f8 to 63ec774 Compare March 23, 2020 19:02
@brunobeltran
Copy link
Contributor Author

brunobeltran commented Apr 9, 2020

@QuLogic, Fixed tests to follow the "parametrize" conventions I found in tests/test_axes.py. Let me know if there are still changes I could make to have the tests be more in line with the mpl conventions!

@brunobeltran brunobeltran force-pushed the path_size_calc branch 3 times, most recently from 9161982 to b1732b6 Compare April 10, 2020 02:47
@brunobeltran
Copy link
Contributor Author

Wow, extremely surprising defaults for Bbox.update_from_data_xy caused a regression (needed to set ignore=False explicitly, otherwise bug would only appear during testing and not on command line :/)

But new, fully vectorized (and easier to read) version of the path extents code now pushed up, ready for re-review!

@brunobeltran brunobeltran force-pushed the path_size_calc branch 3 times, most recently from 5f689df to 1e44dbf Compare April 10, 2020 17:57
@brunobeltran
Copy link
Contributor Author

Included @anntzer 's vectorization suggestions (after some hiccups where 3.6 didn't have a no-args lru_cache decorator), sorry @QuLogic that means that the new vectorized __call__ needs to also be reviewed here now.

Copy link
Member

@QuLogic QuLogic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These comments are not too strong.

@brunobeltran brunobeltran mentioned this pull request Apr 20, 2020
6 tasks
@anntzer
Copy link
Contributor

anntzer commented Apr 20, 2020

anyone can merge postci

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

Successfully merging this pull request may close these issues.

_path.get_extents does not correctly handle bezier curves
5 participants