Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Add test_quiver in test_datetime.py #27407

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Conversation

rawwash
Copy link
Contributor

@rawwash rawwash commented Nov 30, 2023

PR summary

I have added a datetime smoke test for Axes.quiver in lib/matplotlib/test/test_datetime.py.
This addresses the Axes.quiver task from #26864.

The image below is the plot generated from my example code.
quiver test

PR checklist

@rawwash rawwash changed the title added test_quiver in test_datetime.py Add test_quiver in test_datetime.py Dec 1, 2023
u = np.sin(np.arange(len(x)))
v = np.cos(np.arange(len(x)))
fig, ax = plt.subplots(figsize=(10, 6))
ax.quiver(x, y, u, v, scale=20)
Copy link
Member

Choose a reason for hiding this comment

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

It seems like y could also be tested? I'm not sure if it also makes sense to try u and v as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Quiver plots typically expect numerical values for u and v (representing vector components), and y is usually a numerical position value. Using datetime objects for these variables would be unconventional and might not work directly with the quiver plot functionality. I think it might be better to maintain the test as is.

Copy link
Member

Choose a reason for hiding this comment

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

I don't really follow the assertion that y is usually a numerical position value. But in any case, these tests are to check whether the code works, not what the "usual" type is. We absolutely want to test things that are unusual.

Copy link
Member

Choose a reason for hiding this comment

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

I agree that y is not actually different from x here and should be tested, additionally I do think u/v should be tested with angles="xy" and u/v supplied as timedeltas. I think passing u/v as timedeltas should not be included with the (default) angles="uv"

Co-authored-by: Elliott Sales de Andrade <[email protected]>
@QuLogic QuLogic added this to the v3.9.0 milestone Dec 13, 2023
@QuLogic QuLogic modified the milestones: v3.9.0, v3.10.0 Apr 3, 2024
@ksunden ksunden modified the milestones: v3.10.0, future releases Oct 9, 2024
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.

4 participants