-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Add widths
, heights
and angles
setter to EllipseCollection
#26375
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
Conversation
c553db5
to
013f69b
Compare
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.
It probably makes sense to use the newly added methods in the constructor.
(Are there getters as well?)
Thank you @oscargus for the review, this should be all done.
I didn't add the getters because we don't need them and I don't know how to get their value after the transform. But if someone give me some pointers, I am happy to do that in this PR - if there are setters, it would be fair to expect getters too! |
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.
I cannot help with the getters, unfortunately. While it is indeed ideal to have both, it is clearly better to have only setters compared to nothing.
We talked about this on the call and are 👍🏻 on it going in but would like getters. The consensus on the call was for the getters to undo the geometric transformations, but don't worry about the ravel (if someone is passing in higher than 1D data, we would like to know why before bending over backwards to give it back). |
bdbc78e
to
bdde2e9
Compare
I added the getters which return the same as what is given to the setters and rebased. The CI failures shouldn't be related to the changes of this PR. |
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.
In a similar case #26410 (comment) where multiple related arrays can be set, we advocated for a central function that can take one or multiple of the arrays and make sure the final data (mixture of existing and new arrays) has consistent array lengths.
I suggest that we follow this approach here as well - at least for the geometry parameters widths, heights, angles, offsets. I grant that we won't check other potentially sequence-like parameters (e.g. linewidths), but AFAIK they are just cycled continuously and don't have to match in lengths.
A friendly ping on this; I'd like to put out 3.9 beta/rc next week. |
That may work, but it's a bit tricky because the matplotlib/lib/matplotlib/artist.py Lines 139 to 150 in 9e18a34
You may have to care for Edit: I see this is slightly more complicated than #26410 (comment). I thought we make an equivalent to |
I added a |
0cfe854
to
bdde2e9
Compare
Similarly as in #26410, I remove checking the length of the parameters to leave for another PR. |
assert_array_almost_equal(ec._widths, np.array(widths).ravel() * 0.5) | ||
assert_array_almost_equal(ec._heights, np.array(heights).ravel() * 0.5) | ||
assert_array_almost_equal(ec._angles, np.deg2rad(angles).ravel()) |
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.
Do we need to check internals now that we have the getters?
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.
These check that the internal values are correct (multiplication of 0.5) and these are different from the values returned by the getter, so I would say that this is still worth checking these values?
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.
Testing internals is not ideal, but OTOH these tests do not impose a big liability. It's unlikely that we will refactor the internals and if so, the tests can be easily adapted.
Alternatives would be an image comparison (not favored) or checking the bounding box of an EllipseCollection with a single entry.
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.
If this is find to keep to check as it is I would prefer that option because it is straighforward and more simple than the bounding box alternative.
bdde2e9
to
729467c
Compare
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.
Thanks @QuLogic, I have addressed your comments!
assert_array_almost_equal(ec._widths, np.array(widths).ravel() * 0.5) | ||
assert_array_almost_equal(ec._heights, np.array(heights).ravel() * 0.5) | ||
assert_array_almost_equal(ec._angles, np.deg2rad(angles).ravel()) |
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.
These check that the internal values are correct (multiplication of 0.5) and these are different from the values returned by the getter, so I would say that this is still worth checking these values?
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.
Take or leave the internal check.
I think we can ignore the AppVeyor failure here, as it seems to be something to do with wxPython. |
PR summary
Currently, the following example:
will fails with the errors:
PR checklist