Accepting comments on this. Of course, not for 3.0, so no rush. Tests, examples, etc still to be done.

@ImportanceOfBeingErnest you are very familiar w/ the axes_grid API. Any comments here?

I like this. It allows to get a second scale for a plot, without creating a totally new twin axes. Up to now people needed to use such twin axes in cases where they only wanted to have a different formatter on the right side or different colors etc.

I'm currently not sure how would this behave in cases with set aspect. I.e. what if the parent has a specific aspect set? And more importantly, what if the user callsset_aspect on thisSecondary_Axis object?
Some tests for those edge cases would be good.

In general I think the documentation should point towards the differences between twinx and secondary_xaxis.

I'm currently not sure how would this behave in cases with set aspect. I.e. what if the parent has a specific aspect set? And more importantly, what if the user calls set_aspect on this Secondary_Axis object?

Ooh, good point. I'm not sure either. I suspect issues ;-).

I'll make it so the user will not have aset_aspect method available on the secondary axes.

I'm currently not sure how would this behave in cases with set aspect. I.e. what if the parent has a specific aspect set? And more importantly, what if the user calls set_aspect on this Secondary_Axis object?

OK,set_aspect on parent works.set_aspect on secondary axis has been disabled (with a warning)

One could argue that the secondary axes might be able to set an aspect using its "units", but I think that'd be very hard to make work in general (i.e. w/ non-linear conversion between the axes), and I don't think its unreasonable to ask the user to specify the aspect ratio on the parent axes. The secondary axes is just a decoration, not meant to control the other axes.

Similarly set_xlim doesn't work for the secondary axes...

I only had a quick look at the code, but it seems to me that it only changes the limit of an secondary axis. Then, I guess the location of ticks will be correct only if the convert function is linear. If this is the case, allowing an arbitrary function may not be a good idea.

That's a good point. So I guess the documentation needs to be very very clear about the fact that only because you use some arbitrary function, it does not mean that the axes itself is following this function.

Instead one still needs to set some custom locator and formatter, or use a customScale on that axis.

Or else, it would of course be cool to have this function manage this as well.

In any case, in a next stage there will then need to be some example on how to produce a plot with e.g. frequency and wavelength correctly.

I only had a quick look at the code, but it seems to me that it only changes the limit of an secondary axis. Then, I guess the location of ticks will be correct only if the convert function is linear. If this is the case, allowing an arbitrary function may not be a good idea.

Ooops, yes, thats correct. Shouldn't advertise something I didn't really make work. I imagine its possible to encompass non-linear transformations in the locator, but would have to look at it.

Also, I supposes I"ve made no effort to link the xscale, so if I make the parent a logarithm, the secondary axes should be as well. That should be doable.

OK, that took a while, and needs a bit of an API discussion.

What we need to do to make ticks be properly spaced is callsec.set_xscale('arbitrary', transform=transform) where we need to define the transform, and the "arbitrary" scale gets registered. So that all works in prototype (not pushed yet).

For an API, I have the following options:

importnumpyasnpimportmatplotlib.pyplotaspltfrommatplotlib.transformsimportTransformfig,ax=plt.subplots()ax.plot(np.arange(2,11),np.arange(2,11))classLocalInverted(Transform):"""    Return a/x    """input_dims=1output_dims=1is_separable=Truehas_inverse=Truedef__init__(self,out_of_bounds='mask'):Transform.__init__(self)self._fac=1.0deftransform_non_affine(self,values):withnp.errstate(divide="ignore",invalid="ignore"):q=self._fac/valuesreturnqdefinverted(self):""" we are just our own inverse """returnLocalInverted(1/self._fac)axsecond=ax.secondary_xaxis(0.2,conversion='power',otherargs=(1.5,1.))axsecond=ax.secondary_xaxis(0.4,conversion='inverted',otherargs=2)axsecond=ax.secondary_xaxis(0.6,conversion=[3.5,1.])axsecond=ax.secondary_xaxis(0.8,conversion=2.5)axsecond=ax.secondary_xaxis(1.0,conversion=LocalInverted())plt.show()

TheArbitraryScale class that gets used by the non-linear transformations just uses the AutoLocator and ScalarFormater. Of course the user could specify these themselves....

Closing for now so I can sync between machines w/o triggering CI every time. This is close to working, but the transform structure needs some thought...

(I hope I comment in the right place, if not please direct me to the right place)

First, I have to say that I was quite excited when I saw this feature arriving in 3.1, because I always felt this was a bit hacky to implement using previous versions of matplotlib. For getting a secondary axis quick it is already nice.
Nevertheless, I encountered two problems with the current implementation:

(a) Why do I need to supply a forward and backward transform? I assume there is a technical reason for it, but from a user perspective this makes not much sense to me. There are cases where I can define easily a forward transform, but not so easily a backward transform. In theses cases I have to define a grid and resort to linear interpolation for the forward and backward transformation, as shown in the"arbitrary transform" example. The question than arises, if the call to the secondary_axis as such could be made in a way, that if a user supplies only one transform, the backward transform is handled internally, e.g. via linear interpolation?

(b) I was not able to get minor_ticks working, e.g. in the deg2rad example from the documentation I tried

secax = ax.secondary_xaxis('top', functions=(deg2rad, rad2deg))secax.set_xlabel('angle [rad]')secax.minorticks_on()

but that didn't work.

@Knusper, can you open a new issue that outlines your concerns with minor ticks? Hopefully that is something straight forward.

For forward/inverse transformations, you need to be able to go from plot space to data space in order to do the tick labelling, so the inverse is crucial. We appreciate the problem with coming up with an inverse, but hopefully you can appreciate the issue with us automatically making one for you - there is no guarantee that a transform is one-to-one, and hence the inverse may not be unique. So the user should supply the inverse to make the one-to-one mapping clear.

Out of curiousity, what are you trying to map that doesn't have an inverse?

For example transformations from vacuum wavelengths to air wavelengths. The inverse transformation will always be an approximation, since you require the refractive index as a function of vacuum wavelength. If you want to look at the mess you can check here:http://www.astro.uu.se/valdwiki/Air-to-vacuum%20conversion - maybe thats a very specific case...

Gotcha, well, you definitely need the inverse, and for now we are probably going to keep it user-supplied. But if there is a PR that implemented doing it on our side, I'm sure it'd be considered.