Skip to content

The original xlim changed by twinx #6860

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
fjdu opened this issue Jul 30, 2016 · 4 comments · Fixed by #7904
Closed

The original xlim changed by twinx #6860

fjdu opened this issue Jul 30, 2016 · 4 comments · Fixed by #7904
Labels
Difficulty: Easy https://matplotlib.org/devdocs/devel/contribute.html#good-first-issues
Milestone

Comments

@fjdu
Copy link

fjdu commented Jul 30, 2016

  • Matplotlib version: 1.4.3
  • Python version: Python 2.7.11 :: Anaconda 2.3.0 (x86_64)
  • Platform: OSX 10.11.5

The issue: when making a twinx of the original axis with xlim and ylim explicitly set, the twinx axis and the plotting actions that follow will change the xlim of the original plot. "Semantically", all the plots are still correct, but I doubt whether this is the intended behavior.

This can sometimes leads to serious confusions. One example is when the axis (and its twinx) is part of an axes grid, and when its xticklabels are set to be invisible (which is common in a regular grid of axes). In this case, plotting actions with twinx will change the x axis range implicitly and unknowingly, hence changing the alignment with other axes, making the quantitative interpretation of the plots impossible.

From the source code of twinx it is clear to me that the twinx only "inherits" the position of the original axis. I am thinking that it might be more helpful if it inherits all the properties of the original x axis.

See the following examples.

# This (x, y) pair will be used in all the following examples
x = array([-2, 0, 2, 4])
y = 0.3 * x + 0.2

fig = figure()
# This xlim and ylim are explicitly set, and I expect them not to be altered unless I explicitly do so.
ax = fig.add_axes((0.1,0.1,0.8,0.8), xlim=(0,2), ylim=(0,1), autoscalex_on=False, autoscaley_on=False)
ax.plot(x, y, color='blue', lw=10)

image

fig = figure()
ax = fig.add_axes((0.1,0.1,0.8,0.8), xlim=(0,2), ylim=(0,1), autoscalex_on=False, autoscaley_on=False)
ax.plot(x, y, color='blue', lw=10)
ax = twinx(ax)
ax.plot(x, y, color='red', lw=5)
# I would expect the two lines to overlap, but they don't.
# Both xlim and ylim are changed.
# Note that the blue line and the red line are still "semantically" correct.

image

fig = figure()
ax = fig.add_axes((0.1,0.1,0.8,0.8), xlim=(0,2), ylim=(0,1), autoscalex_on=False, autoscaley_on=False)
ax.plot(x, y, color='blue', lw=10)
ax = twinx(ax)
ax.plot(x, y, color='red', lw=5)
ax.set_xlim((0,2))
# This one is acceptible, since the twinx axis has the same xlim as the original one,
# though I expected that this should be the default behavior (without manually setting xlim).

image

fig = figure()
ax = fig.add_axes((0.1,0.1,0.8,0.8), xlim=(0,2), ylim=(0,1), autoscalex_on=False, autoscaley_on=False)
ax.plot(x, y, color='blue', lw=10)
ax = twinx(ax)
ax.plot(x, y, color='red', lw=5)
ax.set_ylim((0,1))
# In this case the two lines overlap, but the original xlim is changed.

image

fig = figure()
ax = fig.add_axes((0.1,0.1,0.8,0.8), xlim=(0,2), ylim=(0,1), autoscalex_on=False, autoscaley_on=False)
ax.plot(x, y, color='blue', lw=10)
ax = twinx(ax)
ax.plot(x, y, color='red', lw=5)
ax.set_ylim((0,1))
ax.set_xlim((0,2))
# This is what I expected in the beginning.
# Basically, I do not expect the twinx to change the original xlim
# (and any other properties of the x axis).

image

@fjdu fjdu changed the title Unexpected behavior of twinx The original xlim changed by twinx Jul 30, 2016
@tacaswell tacaswell added this to the 2.0.1 (next bug fix release) milestone Aug 3, 2016
@tacaswell
Copy link
Member

When making grids of axes that should share tick labels, it is best to use the sharex and sharey kwargs to keep the limits in sync (which avoids this problem); see the plt.subplots docs.

In all cases the y-limit of the original Axes did not change.

I think a pull request to copy the auto-scale state to the twined x-axis is a good idea, but do not think that propagating anything about the y-axis to the twin is a good idea.

@tacaswell tacaswell added the Difficulty: Easy https://matplotlib.org/devdocs/devel/contribute.html#good-first-issues label Aug 3, 2016
@LindyBalboa
Copy link
Contributor

LindyBalboa commented Aug 19, 2016

@tacaswell looking at the docs for plt.subplots that sharex takes 'row' and sharey takes 'col'. Is there any case where those make sense? I don't believe so and would opt to eliminate those if possible.

@WeatherGod
Copy link
Member

Sure, why wouldn't it? I can see why it might not be the case to do so most
of the time, but there isn't really any reason not to allow it.

On Fri, Aug 19, 2016 at 9:49 AM, Conner Phillips notifications@github.com
wrote:

@tacaswell https://github.com/tacaswell looking at the docs for
plt.subplots that sharex takes 'row' and sharey takes 'col'. Is there any
case where those make sense?


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#6860 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AARy-LT7_jB6SNAGoVdczTY_FmllT6Pjks5qhbSAgaJpZM4JYt-S
.

@LindyBalboa
Copy link
Contributor

I was just seeing sharex/sharex in the context of reducing redundant axis labels. But thinking about it, it makes sense in the case of a small multiples layout.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Difficulty: Easy https://matplotlib.org/devdocs/devel/contribute.html#good-first-issues
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants