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

Skip to content

Add test_boxplot to test_datetime.py #27502

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

Closed
wants to merge 1 commit into from

Conversation

shriyakalakata
Copy link
Contributor

PR summary

I have added a datetime smoke test/example code under the test_boxplot method in lib/matplotlib/test/test_datetime.py. This addresses the Axes.boxplot task from #26864.

Here, since the statistical measures in boxplots don't translate well to dates, we convert dates to physical units.
(Using advice from @ksunden 's comment on #27485)

The plots generated from the latest test code:
boxplot

PR checklist

@ksunden
Copy link
Member

ksunden commented Dec 12, 2023

This does not accomplish what I was saying in that comment... If we were to decide to "apply statistics after converting units" (which I stated that I could make an argument for, but not that I actually thought it was the best option) that would have to be a change to how Axes.boxplot itself works, not a test that sidesteps that.

The statement about statistics plots (broadly) applying to physical units is to say I think it makes sense to have a boxplot that shows, e.g. "length in meters". This is not something we have built into our public interface (though we do have some forms of it in examples/other tests, and there is support for e.g. pint to interplay with mpl). This is even if it doesn't make sense for datetimes. It was more of a question than a final decision...

Further, there is already a PR that addresses this portion of #26864, #27038. In general our preference is to work with the first submitter of a similar PR, and to maintain authorship when a PR is built upon. I see that you commented there, though in general our preference is to at least provide the opportunity for the original submitter to respond.

@shriyakalakata
Copy link
Contributor Author

Ah I see, ok. Thank you for explaining it further.

I will keep that in mind.

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

Successfully merging this pull request may close these issues.

2 participants