Skip to content

shared axes switch to log scale #4450

Closed

Description

@anntzer

Consider

fig, axs = plt.subplots(2, 2, sharex=True, sharey=True)
for i in range(2):
    for j in range(2):
        axs[i, j].hist(np.arange(10) + 10 ** (i + j)) # widely varying scales
for ax in axs.flat:
    ax.set_xscale("log")

plt.show()

The axes end up x-relim'd to the data limits of the last axes, hiding away the other histograms (that part seems vaguely related to #3481?).

Of course, one may think "just call set_xscale("log") on one of the axes and the others will follow, right?". But switching to a single call axs[0, 0].set_xscale("log") end up as an even worse disaster; the scaling is not changed on the other axes but the tick markers are.

Activity

  1. added this to the milestone on May 21, 2015
  2. modified the milestones: , on Jul 16, 2015
  3. tacaswell commented on Jul 16, 2015

    @tacaswell
    Member

    There are two indepnedent problems here

    1. the scale does not properly propagate. This one is a bit upsetting, I suspect what is happening is that the Axis locator and formatter is getting updated (as they are the same objects) but the transforms on the axes are not as the Axis objects are not shared. I have a clean way to fix this (PR coming)
    2. the auto limit on shared axes only looks at the last axes (it probably does look at all of them, just independently and sense the shared axis means the Axis object backing each of them is the same object the limits on the last axes it looks at wins. As this works correctly with linear scales I suspect that the special case code for dealing with logs is broken (like much of the autoscaling with log). This is annoying, but can be fixed by manually setting the limits.
  4. added a commit that references this issue on Jul 16, 2015
    ef0dd78
  5. self-assigned this
    on Jul 16, 2015
  6. tacaswell commented on Jul 17, 2015

    @tacaswell
    Member

    Re opening this as #4709 only fixed one of two problems reported.

  7. modified the milestones: , on Oct 3, 2017
  8. afvincent commented on Nov 1, 2017

    @afvincent
    Contributor

    @tacaswell @anntzer Is this issue still active?

    2edf1e3 seems to be the switching point between between some wrong behavior and something that looks OK to me:

    • mwe with dc13688
      mwe_with_dc13688

    • mwe with 2edf1e3
      mwe_with_2edf1e3

  9. anntzer commented on Nov 1, 2017

    @anntzer
    ContributorAuthor

    Indeed, the issue is fixed now.

  10. modified the milestones: , v2.2.0 on Feb 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions