Thanks for reporting this. However I cannot run the script and it looks like you forgot to include the definition of "azis" and "r" in the script. Would you add that so we can get the exactly same result as you?

@stevezhang1999 thanks for flagging that, have updated now

@stevezhang1999 thanks for flagging that, have updated now

Thanks, now I can reproduce this with mpl = 3.7.2

A simpler example to reproduce issue

import numpy as np
import matplotlib.pyplot as plt
fig, ax = plt.subplots(1, 1,subplot_kw=dict(projection='polar'))

ax.set_theta_offset(1.570796327)
plt.subplots_adjust(wspace=0.5)

It looks like you are mostly referring to the "spine" (the bold outline) xref #16066 for that

But also seems to have problems with gridlines still... and I'm reminded of an idea from #24996 of possibly using axhline for gridlines, which may help?

I think this results from a calculation flaw within path.arc so this is not directly related to #16066. Will open a PR for more details and the fix tomorrow (hopefully)

Similar to the axhline suggestion, I can create a quick workaround for the "spine" using a plot command like this:

ax.plot(np.linspace(0, 2*np.pi, 50), np.ones(50)*250, color='black', linestyle='solid',linewidth=2)

This is much more relevant for my uses anyway, but obviously doesn't solve the bug within matplotlib.

@stevezhang1999 do you think this is something more like #13717?

@stevezhang1999 do you think this is something more like #13717?

Update: I think the results in #13717 looks good. Path.arc doesn't document what will happen if theta1 is greater than theta2. As long as (theta1 - theta2) is not close enough to multiple of 360, it's unlikely that we will suffer from the floating point comparison error from roundoff.

I suspect that they are related and will look at it later tonight. To fix this issue, I believe we need to replace the floating point comparison inside with np.isclose() - but it will break many tests and I’m still looking at them.