FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

secondary_xaxis doesn't seem to use formatters · Issue #15621 · matplotlib/matplotlib · GitHub

Repository navigation

secondary_xaxis doesn't seem to use formatters #15621

Closed

Description

Bug report

secondary_xaxis (and secondary_yaxis?) doesn't seem to use formatters.

Code for reproduction

import matplotlib.pyplot as plt
import numpy as np

fig, axs = plt.subplots(figsize=(0.6*4,0.6*3))
y = np.random.rand(10)
x = np.linspace(30,200,num=10)

p = plt.plot(x, y, marker='o', markersize=3)
plt.xscale("log")

def m2rho(m):
    return 1 / m * 1000

def rho2m(rho):
    return 1 / rho * 1000

secax = axs.secondary_xaxis('top', functions=(m2rho, rho2m))

from matplotlib.ticker import ScalarFormatter, NullFormatter
for axis in [axs.xaxis, secax.xaxis]:
    axis.set_major_formatter(ScalarFormatter())
    axis.set_minor_formatter(NullFormatter())
axs.set_xticks([50, 100, 200])
secax.set_xticks([20,10,5])

plt.tight_layout()
plt.show()

Actual outcome

Expected outcome

The top axis should be formatted similarly to the bottom (first) x-axis.

Matplotlib version

  • Operating system: Ubuntu 18.04
  • Matplotlib version: 3.1.1
  • Matplotlib backend: Qt5Agg
  • Python version: 3.7.4

Activity

  1. QuLogic commented on Nov 7, 2019

    Member
    def m2rho(m):
        return 1 / m * 1000
    
    def rho2m(rho):
        return 1 / rho / 1000

    I don't know about the formatters, but this doesn't look right. You have rho = 1 / m * 1000 = 1000 / m and m = 1 / rho / 1000 = 1e-3 / rho; those are not the inverse of each other.

  2. fmikulasch commented on Nov 7, 2019

    Author

    I don't know about the formatters, but this doesn't look right. You have rho = 1 / m * 1000 = 1000 / m and m = 1 / rho / 1000 = 1e-3 / rho; those are not the inverse of each other.

    Well spotted, i changed it - it doesn't change the outcome though.

  3. sujanasowrirajan commented on Jan 7, 2020

    Contributor

    Hi, I am on a new year resolution to start contributing to open source, and this looked like a good place to start :)

    This bug happens because the default formatters for log scale override the formatters that have been set here explicitly (ScalarFormatter and NullFormatter).
    The _secondary_axes.draw method calls self._set_scale, which calls self.set_xscale, which calls _set_scale method below:

    def _set_scale(self, value, **kwargs):
            self._scale = mscale.scale_factory(value, self, **kwargs)
            self._scale.set_default_locators_and_formatters(self)    # Overrides existing formatters and locators
    
            self.isDefault_majloc = True
            self.isDefault_minloc = True
            self.isDefault_majfmt = True
            self.isDefault_minfmt = True
    

    I think we should set default values only if formatters/locators do not already exist, something like:

        def _set_scale(self, value, **kwargs):
            self._scale = mscale.scale_factory(value, self, **kwargs)
    
            major_formatter = self.get_major_formatter()
            minor_formatter = self.get_minor_formatter()
            major_locator = self.get_major_locator()
            minor_locator = self.get_minor_locator()
    
            self._scale.set_default_locators_and_formatters(self)
    
            if major_formatter:
                self.set_major_formatter(major_formatter)
            else:
                self.isDefault_majloc = True
            if minor_formatter:
                self.set_minor_formatter(minor_formatter)
            else:
                self.isDefault_minloc = True
            if major_locator:
                self.set_major_locator(major_locator)
            else:
                self.isDefault_majfmt = True
            if minor_locator:
                self.set_minor_locator(minor_locator)
            else:
                self.isDefault_minfmt = True
    
  4. Wlodarski commented on Feb 22, 2020

    Thank you @lepuchi

    This bug was making me crazy. I applied your tentative correction and a software that was behaving capriciously suddenly works like expected.

  5. ImportanceOfBeingErnest commented on Feb 22, 2020

    Member

    Sorry, @lepuchi, it seems this fell through somehow. Your contribution is very welcome. Please feel free to open a pull request with the envisionned changes, which would make it easier to see them in action. There might be a few edge cases to consider, e.g. what happens if the scale of the original axes changes? So adding test cases would be helpful.

  6. jklymak commented on Feb 22, 2020

    Member

    I'd have to think about this. The logic is a bit convoluted because the parent and child have to know about each other's scale.

  7. jklymak commented on Feb 25, 2020

    Member

    Does #14592 address this?

  8. ImportanceOfBeingErnest commented on Feb 25, 2020

    Member

    #14592 indeed addresses this issue.

  9. jklymak commented on Feb 25, 2020

    Member

    Closing because #14592 is merged, but if #14592 does not actually fix the problem please re-open.

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions


      Back | FazBrowse Home | New Git URL