https://12461-1385122-gh.circle-artifacts.com/0/home/circleci/project/doc/build/html/gallery/subplots_axes_and_figures/secondary_axis.html#sphx-glr-gallery-subplots-axes-and-figures-secondary-axis-py

https://12461-1385122-gh.circle-artifacts.com/0/home/circleci/project/doc/build/html/api/_as_gen/matplotlib.axes.Axes.secondary_xaxis.html#matplotlib.axes.Axes.secondary_xaxis

https://12461-1385122-gh.circle-artifacts.com/0/home/circleci/project/doc/build/html/api/_as_gen/matplotlib.axes.Axes.secondary_yaxis.html#matplotlib.axes.Axes.secondary_yaxis

The creation of a secondary axes with a non-linear transform seems quite complicated. I'm wondering if there is an easier way to achieve this?

Ideally one would probably desire something like

secax = ax.secondary_xaxis('top', conversion=lambda x: 2*np.pi/x)

Would this be possible, internally inverting any function numerically?

2 np.pi / x is already accounted for without transform (secondary_xaxis('top', conversion='inverted', otherargs=2* np.pi)). As are power laws. We could add “arbitrary” and have otherargs be two vectors like the above example. Then the user would be responsible for the numerics.

Arbitrary transform API:

Using an inverse as an example, though that is already supplied by secondary_xaxis('top', conversion='inverted', otherargs=2* np.pi):

functions

def forward_func(x):
    return 2 * np.pi / x

def inverse_func(x):
   return x / (2 * np.pi)


secondary_xaxis('top', conversion=forward_func, otherargs=inverse_func)

Transforms

class LocalInvert(Transform):

    input_dims = 1
    output_dims = 1
    is_separable = True
    has_inverse = True

    def __init__(self, fac):
        Transform.__init__(self)
        self._fac = fac

    def transform_non_affine(self, values):
        return self.fac / values

    def inverted(self):
        """ we are just our own inverse """
        return LocalInvert(1.0 / self.fac)

secondary_xaxis('top', conversion=LocalInvert(2 * np.pi))

Arbitrary

xin = np.arange(300)
xout = 2 * np.pi / xin

secondary_xaxis('top', conversion='arbitrary', otherargs=(xin, xout))

(Note this has pretty bad numerical issues under zooming (will collapse to linear for delta xin < 1, and will be linear extrapolation for xin < 0 or xin > 300)...

@ImportanceOfBeingErnest and others, which of the three is the better arbitrary interface? I guess I like the functions approach the best (not implemented yet). Its basically the same as the Transform, but with a bit less overhead. Internally, it would just be a transform. Of course we should still support a Transform...

I would vote for the functions. If I were to write this for my own purposes I'd do

ax.secondary_xaxis('top', conv=lambda x: .... , inv=lambda k: ...)

but if you think there is a reason to name the arguments differently, that's fine (otherargs sounds very general though).

@ImportanceOfBeingErnest I just didn't want there to be a plethora of kwargs, but maybe otherargs is too mysterious. I do need it for 'linear' and ='inverted' though...

@ImportanceOfBeingErnest, @efiring

• added possibility of conversion=(forward, inverse) where these are forward and inverse functions
• removed the "string" options since they are pretty easy to use as above.
• removed 'otherargs' as a possible kwarg.

I could easily put the string options back, but I think it makes the docs a lot cleaner, and is more powerful for the user just to supply the function. It works very easily with lambda functions:

sec = ax.secondary_xaxis('top', conversion=(lambda x: 3 / x, lambda x: 1 / (x * 3)))

I would prefer simplifying the API further: accept only a pair of functions, and allow only one of the obvious ways of specifying them: as conversions=(forward,inverse) or using 2 required keyword-only arguments. This simplifies everything: the mpl code base, the example, and the documentation, and as far as I can see, it imposes no significant extra work on the user under any circumstances. The resulting user code is more readable. There is no chance of getting the order of slope and intercept mixed up. Everyone is happier, right? Am I missing something? Is there any use case this doesn't handle cleanly? (I haven't spent time on this yet, so certainly I might be missing all sorts of things.)

Between the two options--single kwarg vs two kwargs--I am inclined to prefer the latter as the most readable.

Two senior devs and @ImportanceOfBeingErnest for two-keyword, function-only interface

ax.secondary_xaxis('top', conversion=lamda x: 2/x, inverse=lambda x: 1 / (2 * x))

@timhoffm , @tacaswell? Anyone else object to this?

As I understand it, @efiring prefers the two-argument notation conversion=lambda x: 2*x, inverse=lambda x: x/2. while I personnally prefer the single argument tuple conversion=(lambda x: 2*x, lambda x: x/2.).
I wouldn't completely object the other solution, but with the tuple notation it is clearer in my eyes that you always need such forwards and backwards function to come as pair, while two single arguments may not make it too clear that one needs to specify both to work.

I would not abbandon at least the single factor solution for the following reason: I think part of the motivation for the secondary axes was to get a better way of creating an identical scale on the other side of the plot without abusing twinx/twiny in order to simply format this scale differently or use a different locator. In such case specifying the secondary_*axis as e.g. ax2 = ax.secondary_yaxis('right', conversion=lamda x: x, inverse=lambda x: x) instead of ax2 = ax.secondary_yaxis('right') feels quite cumbersome.

The no-conversion case can be handled concisely by making it the default, conversion=None, inverse=None.

In documentation and examples, I suggest avoiding the mystical-looking lambda, and instead define named functions as needed:

def reciprocal(x):
    return 1/x

ax2 = ax.secondary_yaxis('right', conversion=reciprocal, inverse=reciprocal)

I'm not adamantly opposed to the tuple alternative, conversion=(reciprocal, reciprocal), with a default of conversion=None, but I think the two-kw form is a bit more readable and easier to document. I am adamant that we need to choose one or the other.

This feature--the axis with a different but functionally-related scale--is a wonderful addition to mpl, and one that even the newest mpl user and the least programming-oriented user should be comfortable with. It is the kind of API for which we should put heavy weight on simplicity, explicitness, and readability.

I think my point was that a signature which looks like

 function(location, conversion=None, inverse=None)

does not make it clear that you need to specify conversion and inverse simultaneously, while with

function(location, conversion, inverse)

that would be obvious. However if deciding for that latter case, function(location), meaning "no conversion" would be impossible.

A signature like

function(location, conversion=None)

would overcome this, allowing for "no conversion" as None or a custom conversion in form of a tuple.

If we expect this feature to be widely used, I'm pretty sure that sooner or later people would demand for conversion also taking a constant, or a slope + offset, essentially what the current implementation already allows for. So it may be beneficial to implement this now and do it the way it can be agreed upon than having a user trying to implement it later and going through all the details of implementation in their PR when it comes in.

Oh, I think I forgot to say that I would certainly agree that one would not want to have a mixture like conversion=(forward,backward), inverse=None - that would sure be confusing and hard to document.

The problem with giving in to demand (if it were to arise) for multiple input forms is that it makes everything more complicated, for what I think is negligible gain in convenience. I'm really worried about code bloat in mpl, and excessive complexity in API and in documentation.

To me it looks like not allowing for the constant factor or slope + offset would save you some 20 lines of the 580 lines long code (from line 248 to 271), which is 4%.

ping @anntzer @efiring I think I hit all your requests...

I see a total of only 2 commits, the original, and one from a couple days ago which has only some of the indicated changes in it. Either something is going wrong with the way I am interpreting or using this web page, or you didn't push something you thought you pushed.

... merge?

I just ran the first example from this PR and the result looks like this on screen:

If resizing the figure window with the mouse this can become as bad as

The saved figure is fine though.
(This is with master fetched a few minutes ago, python 3.6.6 on windows 8.1, Qt5Agg)

Let me know if you need further details or want me to test anything particular with my configuration.

Well, huh - never tried resizing the window!