Skip to content

[Bug]: Units behavior of tri* methods #27499

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
ksunden opened this issue Dec 12, 2023 · 1 comment
Open

[Bug]: Units behavior of tri* methods #27499

ksunden opened this issue Dec 12, 2023 · 1 comment

Comments

@ksunden
Copy link
Member

ksunden commented Dec 12, 2023

Bug summary

As seen in #27491, #27488, #27494, #27487

It appears that the tri* methods do not actually properly handle units.

Code for reproduction

fig, ax = plt.subplots()
np.random.seed(19680801)
limit_value = 30

startdate = np.datetime64("2023-12-01")

x_dates = startdate + np.random.randint(0, 15, size=(limit_value-1,)).astype("timedelta64[D]")
y_dates = startdate + np.random.randint(0, 15,size=(limit_value-1,)).astype("timedelta64[D]")

x_dates_converted = mpl.dates.date2num(x_dates)

y_data = np.random.rand(limit_value - 1)

z_data = np.sin(x_dates_converted) + np.cos(y_data)

ax.triplot(x_dates, y_dates)
ax.tripcolor(x_dates, y_dates, z_data)
#ax.tricontour(x_dates, y_dates, z_data)
#ax.tricontourf(x_dates, y_dates, z_data)

Actual outcome

Prior to (probably, though I didn't actually bisect it) #24522, the code would actually error, as it attempted to cast the x/y arrays to float64 arrays.

Now it will actually work to plot (seemingly even getting the actual values converted, though now that I think about it not sure where... my guess is that it is actually coincidental that they are datetime64[D] dtype which happens to be the same scale/epoch as mpl, but it is not actually being properly converted) however it does not set the Formatters/etc.

Expected outcome

Units are set properly (including axisinfo such as formatters).

Additional information

No response

Operating system

No response

Matplotlib Version

3.9.0.dev821+gfa6be74127 (~main currently)

Matplotlib Backend

No response

Python version

No response

Jupyter version

No response

Installation

git checkout

@ksunden
Copy link
Member Author

ksunden commented Dec 12, 2023

The plot calls in #27491 actually obscure the problem, which is part of why it looks like it works...

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

No branches or pull requests

2 participants