-
-
Notifications
You must be signed in to change notification settings - Fork 7.4k
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
[Bug]: unexpected thetalim behavior in polar plot #25568
Comments
I think the actual problem has to do with the ThetaLocator getting confused by the overlapping limits. When I do: import numpy as np
import matplotlib.pyplot as plt
fig = plt.figure()
ax = fig.add_subplot(projection='polar')
ax.set_thetalim(-np.pi*.999, +np.pi) # [-180°, +180°]
plt.show() That is, just barely nudging so that the limits do not end up overlapping. I get: Which, aside from the radial axis being shifted/having a line, is pretty much as expected. It's a workaround rather than a proper fix, though. Explicitly setting the ticks (with fig = plt.figure()
ax = fig.add_subplot(projection='polar')
ax.set_xticks(np.linspace(-np.pi, np.pi, 9)[1:])
ax.set_thetalim(-np.pi, +np.pi) # [-180°, +180°]
plt.show() |
The following diff gets at least very close to expected behavior (I might prefer 180 as a label instead of -180, but they are equivalent so, not soo bad). diff --git a/lib/matplotlib/projections/polar.py b/lib/matplotlib/projections/polar.py
index 9ac9bbe73c..3e4b1c8175 100644
--- a/lib/matplotlib/projections/polar.py
+++ b/lib/matplotlib/projections/polar.py
@@ -295,8 +295,9 @@ class ThetaLocator(mticker.Locator):
def __call__(self):
lim = self.axis.get_view_interval()
if _is_full_circle_deg(lim[0], lim[1]):
- return np.arange(8) * 2 * np.pi / 8
+ return (np.arange(8) * 2 * np.pi / 8) + np.deg2rad(min(lim))
else:
return np.deg2rad(self.base()) Yields (with the original code): It also does pass all extant polar tests. |
To summarize what was happening:
|
In the best of worlds, I would suggest ±180 ! |
This is already a 90% solution. IMHO good enough for a fix if we don't want to spend more time. If you want to go further, you'd need to distinguish between minval and maxval tick limits. Up to discussion, but I'd argue that you typically want the maxval, e.g. (-90°, 270°], (-180°, 180°]. Only [0*, 360°) wants the minval. Untested: It may be enough to shift the tick positions:
This would additionally need to be handled in One can obtain |
It's not obvious to me that 270 is the preferred label for the Another example that is not too unreasonable:
|
Since there appears to be such a strong preference on either side maybe we should just set it blank and have the user set it. Also, on sundens point of polar angle validation, I do not know if it exists or not, but there should be a way to turn it off. I can still see someone wanting to map non integer values |
I don't have a strong preference. "Smallest absolute value" seems reasonable too. |
I would also not describe my preference as "strong", quite the opposite in fact. My position has been "unclear what is desirable" in many cases. I came up with a heuristic that I think encapsulates my expectations, but still considering options. Leaving blank would be unexpected to me, as that would break the symmetry of where gridlines/ticks are placed. This is about defaults, as of course you can set them to whatever you like as the end user. @Higgs32584 I am not sure what you mean by "polar angle validation" here. Nothing in this discussion has been limited to integer values, as far as I can tell. The proposed diff (and variations on that theme, modulo which end gets kept) will work perfectly fine with e.g |
When I meant polar Angle validation I meant this part: "Another example that is not too unreasonable: [720,1080] I would expect the minval there" I apologize for calling your comments above "strong" |
I still do no understand what should be "turned off" about that. This particular code path only affects full circles, there is separate handling for non-full circle, which uses an underlying locator implementation. You can call |
Bug summary
I'd like to have a polar plot where angles go from -180° to +180°. It was my understanding that this was controled by
set_thetalim
, but this does not produce the expected result.Code for reproduction
Actual outcome
Expected outcome
A plot where angles go from -180° to +180°.
Additional information
No response
Operating system
Ubuntu 20.04.6 LTS
Matplotlib Version
3.6.2
Matplotlib Backend
Qt5Agg
Python version
Python 3.8.10
Jupyter version
No response
Installation
pip
The text was updated successfully, but these errors were encountered: