matplotlib-devel Mailing List for matplotlib

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> I am getting more comfortable with 'scaled' now. The problem
 Eric> is that neither 'equal' nor 'scaled' is as obvious as one
I think a mini-tutorial on aspect handling for axes and images,
especially with screenshots that show the different effects, and a
discussion of all the wild-and-wooly options would be a great addition
to the wiki.
JDH

Mark,
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):
 """
 aspect:
 '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
 aspect='equal'.
 adjustable:
 'box' - change physical size of axes
 'datalim' - change xlim or ylim
 anchor:
 'C' - centered
 'SW' - lower left corner
 'S' - middle of bottom edge
 'SE' - lower right corner
 etc.
 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.
Jeff,
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.
All,
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.
Eric
> 
> Mark
> 
> Helge Avlesen wrote:
> > On 3/22/06, Eric Firing < ef...@ha... 
> <mailto:ef...@ha...>> 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.
> >
> >
> > Hi,
> > 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?
> >
> > http://www.mathworks.com/access/helpdesk/help/techdoc/ref/axis.html
> >
> > Helge
> 
> Helge,
> 
> 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
> respects.)
> 
> 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.
> 
> Eric

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'll try to find time to test Eric's new implementation soon. Thanks for
all the hard work,
Mark
Helge Avlesen wrote:
> On 3/22/06, Eric Firing <ef...@ha...> 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.
>
>
> Hi,
> 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?
>
> http://www.mathworks.com/access/helpdesk/help/techdoc/ref/axis.html
>
> Helge
Helge,
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
respects.)
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.
Eric

On 2006年3月30日, John Hunter wrote:
>>>>>> "Pearu" == Pearu Peterson <pe...@sc...> writes:
>
> Pearu> Without the patch I get:
>
> Are you using matplotlib subversion?
Hmm, I was using cvs.., I didn't notice the switch to svn.
> What does
>
> >>> import matplotlib
> >>> matplotlib.__version__
>
> report?
>>> import matplotlib
>>> matplotlib.__version__
'0.87.1cvs'
> My guess is that this was fixed by Travis' commit that imported the
> old linalg namespace
>
> elif which[0] == "numpy":
> from numpy.linalg import *
> inverse = inv
> eigenvectors = eig
> try:
> from numpy.linalg.old import *
> except:
> pass
>
> I am not getting your import error w/ current numpy snv (rev 2312)
Ok, I'll switch to svn.
Thanks,
Pearu

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
 Charlie> I shoudl have tried this in the first place. The
 Charlie> widgets/radio_buttons.py example doesn't work at all for
 Charlie> me. In fact quite a few are broken.
I noticed today that the subplots_adjust toolbar widget is broken
too... So this is a fairly high priority bug.
JDH

>>>>> "Pearu" == Pearu Peterson <pe...@sc...> writes:
 Pearu> Without the patch I get:
Are you using matplotlib subversion? What does
 >>> import matplotlib
 >>> matplotlib.__version__
report?
My guess is that this was fixed by Travis' commit that imported the
old linalg namespace
elif which[0] == "numpy":
 from numpy.linalg import *
 inverse = inv
 eigenvectors = eig
 try:
 from numpy.linalg.old import *
 except:
 pass
I am not getting your import error w/ current numpy snv (rev 2312)
JDH

On 2006年3月30日, John Hunter wrote:
>>>>>> "Pearu" == Pearu Peterson <pe...@sc...> writes:
> Pearu> This fixes import errors when using only numpy.
>
> which import errors? I updated from numpy svn today and did a clean
> build and test against matplotlib's poor man's regression suite using
>
>>>> import numpy
>>>> numpy.__version__
> '0.9.7.2310'
>
> and did not encounter any errors.... Or is my numpy version already
> woefully out of date :-) ?
Without the patch I get:
>>> import pylab
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File "/usr/local/lib/python2.3/site-packages/pylab.py", line 1, in ?
 from matplotlib.pylab import *
 File "/usr/local/lib/python2.3/site-packages/matplotlib/pylab.py", line 
200, in ?
 from axes import Axes, PolarAxes
 File "/usr/local/lib/python2.3/site-packages/matplotlib/axes.py", line 
14, in ?
 from artist import Artist, setp
 File "/usr/local/lib/python2.3/site-packages/matplotlib/artist.py", line 
4, in ?
 from transforms import identity_transform
 File "/usr/local/lib/python2.3/site-packages/matplotlib/transforms.py", 
line 193, in ?
 from matplotlib.numerix.linear_algebra import inverse
ImportError: cannot import name inverse
>>>
Pearu

>>>>> "Pearu" == Pearu Peterson <pe...@sc...> writes:
 Pearu> This fixes import errors when using only numpy.
which import errors? I updated from numpy svn today and did a clean
build and test against matplotlib's poor man's regression suite using
>>> import numpy
>>> numpy.__version__
'0.9.7.2310'
and did not encounter any errors.... Or is my numpy version already
woefully out of date :-) ?
JDH

Index: lib/matplotlib/numerix/linear_algebra/__init__.py
===================================================================
RCS file: 
/cvsroot/matplotlib/matplotlib/lib/matplotlib/numerix/linear_algebra/__init__.py,v
retrieving revision 1.5
diff -r1.5 __init__.py
8a9,10
> inverse = inv
> eigenvectors = eig
This fixes import errors when using only numpy.
Regards,
Pearu

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> I think what you are proposing is a bit different from what
 Eric> John suggested in his subsequent message, but a common
 Eric> element is the separation of Axes nuts and bolts from
 Eric> fancier plotting. I will do that relatively simple job
 Eric> first; I think it will facilitate any subsequent more
 Eric> extensive refactoring.
This is an odd time to bring this up, when we are trying to prune the
Axes class, but I am trying to remove any pure pylab functionality.
To whit: 'setp' and 'getp' have been recently moved to
matplotlib.artist, 'load' and 'save' to matplotlib.mlab, and so on.
Basically, I want to have some ammunition when people complain that
the OO interface is harder to use than the pylab interface :-)
Which brings me to the 'axis' command. This is one of the few
remaining truly useful pieces of pylab functionality. Should this not
be a method of Axes (in the current, non-refactored understanding of
Axes)?
In any case, Eric, since you are intimately familiar with both axis
and the phase-I refactoring of Axes, I think this would be a good time
to make axis functionality available to non-pylab users, wherever it
fits best.
JDH

Helge Avlesen wrote:
> On 3/22/06, Eric Firing <ef...@ha...> 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.
> 
> 
> Hi,
> 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?
> 
> http://www.mathworks.com/access/helpdesk/help/techdoc/ref/axis.html
> 
> Helge
Helge,
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 
respects.)
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.
Eric

Jouni K Seppanen wrote:
> Eric Firing <ef...@ha...> writes:
> 
> 
>>The main organizational change would separate the functionality that
>>is directly involved in manipulating the axes from the more specific
>>plotting methods. This could be done, for example, by putting the
>>former in an AxesBase class, and then letting Axes inherit that.
> 
> 
> IMHO, it would make sense in the long term to make Axes a low-level
> class with a well-defined interface, and implement high-level plotting
> methods such as bar, boxplot, cohere, hist, specgram and what have you
> using that interface outside of Axes. Currently at least some of these
> methods "peek under the hood" by doing things like
> 
> if not self._hold: self.cla()
> 
> This looks like it will be a pain to maintain if the implementation
> details ever change. self._hold could probably be easily replaced by
> self.ishold(), but moving the methods to another class would help
> ensure that they stay kosher.
> 
Jouni,
I think what you are proposing is a bit different from what John 
suggested in his subsequent message, but a common element is the 
separation of Axes nuts and bolts from fancier plotting. I will do that 
relatively simple job first; I think it will facilitate any subsequent 
more extensive refactoring.
Eric