ENH: secondary axis for a x or y scale. #10976
Comments
|
An Axis makes logical sense, but it doesn't fit deep-seated aspects of the way mpl works, which is very Axes-centric. Among other things, spines reside in the Axes, even though each spine is tied to an Axis. That's why I think that a variation on twinning, but with a stripped-down slave Axes rather than a full-fledged twin, is likely to provide the most direct route to the desired result. The slave would be designed solely for the purpose of providing alternative scales (with Locators and Formatters) for labeling the data plotted in the master. It would be added to the Figure just like any other Axes, so the master would not have to know about it, and the Axes class would not be changed. |
|
OK, I hadn't quite realized that axis objects didn't know about the spines. The reason I was thinking of it as a spine/xaxis is then it could be included in the bounding box for any tight/constrained_layout behaviour acting on the parent axes. For layout the parent needs to know about the child. I think I can still do that if we go an axes route, the way colorbars are done, but its a bit ugglier. |
|
Yes please! I have needed this functionality a few times, and solved it by using a |
|
Note that this is the functionality provided in |
|
I wanted to mention here that pandas uses It could be confusing if now matplotlib uses |
|
To simplify the API, instead of creating a new from mpl_toolkits.axes_grid.parasite_axes import SubplotHost
ax_host = SubplotHost(fig, 1, 1, 1)
ax_twin = ax_host.twin(convert=(lambda x: 1/(1+x), lambda y: y**2))which handles all the boiler-plate code to create the The only problem I see, is that currently, |
|
That’s possible. Axes_grid1 isn’t really part of core, so in my opinion it’d be nice to move this into the main functionality. |
|
This was done in #11859 |
Enhancement discussion
See #10961 #10960
Often it is desirable to have a second x or y scale on an axes with a different scale than the primary x/y axis; think frequency and period on the xaxis of a power spectrum, or date and datenum for a time series. (just assuming the x-axis for now:) Generally it'd be the same size as the existing xaxis, but would be offset vertically, have its own locator, formatter, and xlabel. it would update as the data is zoomed through, and be slave to the parent xaxis
It appears folks most often do this with twiny (i.e. https://stackoverflow.com/questions/10514315/how-to-add-a-second-x-axis-in-matplotlib) but there is nothing to make the axes continue to have the same x-limits under interactive viewing, and no simple way to have the new axes have a different scale.
The enhancement here would be to add something like:
where
secaxisis either an axis object or an axes.locwould be something like"top", "bottom", "above", "below", floatwhere "above" and "below" means that it goes above or below any existing axis, and the float is a hard-set axes fraction (like theset_positionofspinenow).convertwould be a conversion factor: a float would just be a multiplier, or a function could be passed that converts x to xnew. No doubt there could be a way to make this work with units instead, but...How to impliment
As discussed in #10961 @efiring thought implimenting as an axes with shrunk and hidden unused dimensions would be good.
I'd advocate an axis object so that the logical organization makes more sense. i.e. this would be a child of the original axes, and would be included as one of the axes decorators. But, I haven't thought through all the implimentation details yet.
The text was updated successfully, but these errors were encountered: