Mark Bakker wrote:
Sorry that I have not been involved much in the reworking of the
aspect ratio handling, but I have been travelling (I know, what
an excuse is that).
Regarding the options used, the 'equal' option mimics matlab, both
in functionality and in name. Besides, I think it is not a bad descriptor,
so my vote is to keep it.
The 'scaled' term I made up. It might be a bad word, but the functionality
is much more useful IMHO in that it keeps the limits on the axes
and it changes the size of the plotting area such that the axes are scaled.
The 'equal' option is surely a pain in the ass to use I think, as any time
you add something to the damn figure, it will reset the axes limits. But,
if former matlab users want it, I don't mind keeping it.
I am getting more comfortable with 'scaled' now. The problem is that neither 'equal' nor 'scaled' is as obvious as one would like. Both set the data aspect ratio to 1, the first by changing the plot box dimensions and the second by changing the data view limits, but this is not obvious from the usage axis('equal') and axis('scaled'). It may be the best we can do, so I don't mind leaving it. Both 'equal' and 'scaled' functionality have important uses.
The Axes.set_aspect method is more verbose and expressive:
def set_aspect(self, aspect, adjustable=None, anchor=None):
'auto' - automatic; fill position rectangle with data
'normal' - same as 'auto'; deprecated
'equal' - same scaling from data to plot units for x and y
num - a circle will be stretched such that the height
is num times the width. aspect=1 is the same as
'box' - change physical size of axes
'datalim' - change xlim or ylim
'C' - centered
'SW' - lower left corner
'S' - middle of bottom edge
'SE' - lower right corner
ACCEPTS: ['auto' | 'equal' | aspect_ratio]
The kwargs also have their own set methods; the kwargs are included in set_aspect so that it can be used to set everything in one line.
I see now that I need to add to the docstring the clarification that the anchor kwarg is active only for adjustable=box.
This is where I put the plot-box location option. I used the Tk-style "anchoring" terminology because it seems to me to be very compact, expressive, and easy to remember. Unfortunately, it differs from what is used in the legend command. If there is any sentiment that it would be desirable, I could make legend understand it as well, for the sake of consistency.
I have not tried to load the anchor options into the pylab axis command; I think this would be making it too complicated, for no real benefit. I consider pylab to be mainly for interactive use, for which the simplicity/power tradeoff should be biased towards simplicity.
I factored the plot box resizing and repositioning code out into a PBox class ("Position Box", subclassed from list), presently in its own pbox.py file, because I think it will be more generally useful; the colorbar command is one such intended use. It may be helpful to make Axes._position a PBox instance instead of an ordinary list.
I think that aspect-ratio handling is now reasonably solid and complete; I have tested it with pan and zoom, with and without ganged axes. I had to put in a couple of hacks in backend_bases to prevent exceptions. (More careful analysis and fixing of the underlying causes would be good.) Testing by other people would be very useful; you are likely (maybe I should say 'certain') to try combinations of commands and events I have not tested, which will turn up additional problems.
In case I failed to mention it in an earlier post: PolarAxes now uses aspect-ratio handling to keep circles circular when windows are resized.
I'll try to find time to test Eric's new implementation soon. Thanks for
all the hard work,
Thank you, Mark, for the original work that made the changes possible.
Helge Avlesen wrote:
> On 3/22/06, Eric Firing < efiring@…229… > <mailto:efiring@…229…>> wrote:
>>unintuitive. Maybe we could find better names than 'equal' and
>>'scaled', for example. Even with the docstrings, I have a hard time
>>keeping track of which is supposed to do what.
> I think it would be nice if pylab "semantics" were kept close to matlab.
> Maybe for instance axis('scaled') could be renamed to axis('image'), and
> use similar wording as mathworks documentation in the docstrings?
I understand the sentiment, but I don't always agree with it; while I
don't want to do things differently from Matlab just for the sake of
being different (except insofar is it may be necessary to avoid
violating copyright), neither do I want to slavishly follow Matlab.
Pylab/matplotlib can and should be better than Matlab. (And is in many
In the case of Matlab's axis command, the Matlab documentation makes my
head spin, and the whole command strikes me as too complicated for
anyone's good. I don't think every possible capability should go into
the pylab interface; past a certain point, it is better to simply call
axis methods, etc.
For now, I have added an axis('image') mode, which is not quite the same
as 'scaled', and I have tried to improve the descriptions of the
options. Please try out the various axis modes, and see if you think
both the behavior and the descriptions make sense.