matplotlib-users Mailing List for matplotlib

Sorry Andrew. I wasn't paying careful enough attention to what John was
saying and have a different idea of what numerix should evolve into: a
simple numarray/Numeric switcher which provides "normalized" access to
the standard packages. If multiple namespaces are combined, that's OK
as long as we don't inject new behavior which defeats numerix's role as
a Numeric replacement. In the general sense, the purpose of numerix is
to make Numeric software available for numarray users. Fairly soon I
think we're going to want to factor it out of matplotlib and use it in
other places.
I agree with John that numerix is not completely a simple switcher now, 
but I think that's where it needs to head. Whatever short term solution
is chosen for min,max,etc... isn't that big a deal.
Regards,
Todd
On Thu, 2005年01月20日 at 15:41, Andrew Straw wrote:
> OK, let's get this straight. The situation as it stands:
> 
> Currently in CVS is an implementation such that "from pylab import *" 
> does not override builtins. I think we all agree that this is the right 
> behavior. The question is now the implementation. (The code I checked 
> in simply restores of pylab's names to the builtins. e.g. in the 
> pylab.py: "min = __builtin__.min")
> 
> John suggests moving my "solution" (I prefer to think of it as a 
> band-aid, curing the symptom, but not the cause) up the chain to 
> numerix, such that numerix.min = __builtin__.min (same for max, etc). 
> Additionally, he suggests bringing a few more names into existence such 
> that numerix.nxmin = mlab.min (same again for max, etc). I have no 
> problem with this, but Todd "we should keep numerix compatible with 
> Numeric" Miller does, and I can see he has a valid point. Thus, I see 
> no easy resolution which is of little consequence to those of us who do 
> not use numerix in our code.
> 
> Since I am personally quite busy with other stuff, and I don't see a 
> clear consensus of this numerix issue, which is secondary to my initial 
> gripe regarding pylab. I am disinclined to do anything more at this 
> point. I will hereby let someone who cares more than I do about numerix 
> take it from here.
> 
> For the record, I agree with everyone that "from blah import *" is a bad 
> idea. However, pylab is special and thus deserves special attention. 
> Partly this is because John, Fernando, and others have spent many hours 
> making sure it plays well in IPython, resulting in IPython's pylab mode 
> being the best Python interactive scientific plotting solution. 
> Personally, I agree with Fernando's decision to do a "from pylab import 
> *" in ipython -pylab because it enables rapid, interactive data 
> exploration. (Besides which, it freakin' rocks!! :)
> 
> Given ipython -pylab is my most frequently used interactive Python, I 
> want min/max/etc to be the builtin functions (especially since I tend to 
> do "run -i blah.py" from IPython a lot, which thus inherit names, 
> including min and max, from ipython's interactive namespace).
> 
> Also, I am still intrigued by Norbert's suggestion to change Python 
> itself to eliminate this mess, but I don't have the time to deal with 
> it. Furthermore, even if someone did step up to the plate, this is a 
> longer term solution, and we'd still need a "band-aid" for the immediate 
> term.
> 
> Getting back to my day job now,
> Andrew

OK, let's get this straight. The situation as it stands:
Currently in CVS is an implementation such that "from pylab import *" 
does not override builtins. I think we all agree that this is the right 
behavior. The question is now the implementation. (The code I checked 
in simply restores of pylab's names to the builtins. e.g. in the 
pylab.py: "min = __builtin__.min")
John suggests moving my "solution" (I prefer to think of it as a 
band-aid, curing the symptom, but not the cause) up the chain to 
numerix, such that numerix.min = __builtin__.min (same for max, etc). 
Additionally, he suggests bringing a few more names into existence such 
that numerix.nxmin = mlab.min (same again for max, etc). I have no 
problem with this, but Todd "we should keep numerix compatible with 
Numeric" Miller does, and I can see he has a valid point. Thus, I see 
no easy resolution which is of little consequence to those of us who do 
not use numerix in our code.
Since I am personally quite busy with other stuff, and I don't see a 
clear consensus of this numerix issue, which is secondary to my initial 
gripe regarding pylab. I am disinclined to do anything more at this 
point. I will hereby let someone who cares more than I do about numerix 
take it from here.
For the record, I agree with everyone that "from blah import *" is a bad 
idea. However, pylab is special and thus deserves special attention. 
Partly this is because John, Fernando, and others have spent many hours 
making sure it plays well in IPython, resulting in IPython's pylab mode 
being the best Python interactive scientific plotting solution. 
Personally, I agree with Fernando's decision to do a "from pylab import 
*" in ipython -pylab because it enables rapid, interactive data 
exploration. (Besides which, it freakin' rocks!! :)
Given ipython -pylab is my most frequently used interactive Python, I 
want min/max/etc to be the builtin functions (especially since I tend to 
do "run -i blah.py" from IPython a lot, which thus inherit names, 
including min and max, from ipython's interactive namespace).
 
Also, I am still intrigued by Norbert's suggestion to change Python 
itself to eliminate this mess, but I don't have the time to deal with 
it. Furthermore, even if someone did step up to the plate, this is a 
longer term solution, and we'd still need a "band-aid" for the immediate 
term.
Getting back to my day job now,
Andrew

>>>>> "Humufr" == Humufr <hu...@ya...> writes:
 Humufr> I understand your point but I think that to draw on object
 Humufr> inside a figure, using some relative coordinate are not
 Humufr> very convenient. You add to play with the data coordinates
 Humufr> and the figures coordinates. That can be useful for some
 Humufr> objects but very often some people would like to plot a
 Humufr> rectangle (or what do you want) with the data corrdinate
 Humufr> and it's very disturbing at the beginning the way that
 Humufr> patches is working. I don't know if I'm clear this time
 Humufr> (my english is very poor sometimes).
Yes, apparently there is something of a language barrier -- my french
is not so good either, sigh. 
But I just want to reiterate, you are not using relative coords for
the rectangle in the example below. When you do the following,
 from pylab import *
 from matplotlib.patches import Rectangle
 ax = gca()
 p = Rectangle((1,1),3,3,fill=False)
 ax.add_patch(p)
your rectangle is in *data coordinates* and it is where it should be
(center at 1,1 and width=height=3). The problem is that your axis
"view" limits are not set properly (if you use the pan and zoom
features of the toolbar to move your view limits you'll see the
rectangle where it should be. Only the plot commands (plot, scatter,
etc,....) call autoscale_view to set the view limits (add_patch does
not), so you need to set the axis limits yourself.
 axis([0,10,0,10])
In summary, the rectangle is being added in the right coordinate
system (data coords) but the view limits are not automatically
autoscaled unless you issue a plot command. I choose not to do
autoscale every time a patch is added for performance reasons -- if
you are savvy enough to call add_patch, I assume you are savvy enough
to call set_xlim or set_ylim as appropriate for your data.
JDH

John Hunter wrote:
>>>>>>"Humufr" == Humufr <hu...@ya...> writes:
>>>>>> 
>>>>>>
>
>
> Humufr> but if you use axis only without redefine gca limit that
> Humufr> don't work:
>
> Humufr> from pylab import * from matplotlib.patches import
> Humufr> Rectangle axis([0,10],[0,10]) ax = gca() p =
> Humufr> Rectangle((1,1),3,3,fill=False) ax.add_patch(p)
>
>I think you screwed up the "axis" syntax. What you mean (I think) is:
>
> from pylab import *
> from matplotlib.patches import Rectangle
> axis([0,10,0,10])
> ax = gca()
> p = Rectangle((1,1),3,3,fill=False)
> ax.add_patch(p)
> show()
> 
>
yes sorry I did mistake in my mail but the result is the same. I can't 
draw the rectangle where I want. To do this I had to set the xlim and 
ylim manually.
> Humufr> I understand that gca return an instance but perhaps that
> Humufr> will be a good idea if by default that will use the axis
> Humufr> of the courrant figure and not [0,1,0,1].
>
>I'm a little confused here. gca returns the current axes (note axis
>and axes are different commands and have different meanings). The
>default axes is
>
>2 >>> ax = gca()
> 
>3 >>> ax.get_position()
>Out[3]: [0.125, 0.10999999999999999, 0.77500000000000002, 0.79000000000000004]
>
>Can you clarify your meaning? axis set the view limits of the current
>axes. The view limits are in data coordinates, and these are the same
>limits that are controlled by xlim and ylim. axes sets the position
>of the axes (the frame in which your plots are made) and these
>coordinates are in figure coords -- 0,0 is lower left of the figure
>and 1,1 is upper right.
> 
>
I understand your point but I think that to draw on object inside a 
figure, using some relative coordinate are not very convenient. You add 
to play with the data coordinates and the figures coordinates. That can 
be useful for some objects but very often some people would like to plot 
a rectangle (or what do you want) with the data corrdinate and it's very 
disturbing at the beginning the way that patches is working.
I don't know if I'm clear this time (my english is very poor sometimes).
Thanks,
 Nicolas

>>>>> "Humufr" == Humufr <hu...@ya...> writes:
 Humufr> but if you use axis only without redefine gca limit that
 Humufr> don't work:
 Humufr> from pylab import * from matplotlib.patches import
 Humufr> Rectangle axis([0,10],[0,10]) ax = gca() p =
 Humufr> Rectangle((1,1),3,3,fill=False) ax.add_patch(p)
I think you screwed up the "axis" syntax. What you mean (I think) is:
 from pylab import *
 from matplotlib.patches import Rectangle
 axis([0,10,0,10])
 ax = gca()
 p = Rectangle((1,1),3,3,fill=False)
 ax.add_patch(p)
 show()
 Humufr> I understand that gca return an instance but perhaps that
 Humufr> will be a good idea if by default that will use the axis
 Humufr> of the courrant figure and not [0,1,0,1].
I'm a little confused here. gca returns the current axes (note axis
and axes are different commands and have different meanings). The
default axes is
2 >>> ax = gca()
 
3 >>> ax.get_position()
Out[3]: [0.125, 0.10999999999999999, 0.77500000000000002, 0.79000000000000004]
Can you clarify your meaning? axis set the view limits of the current
axes. The view limits are in data coordinates, and these are the same
limits that are controlled by xlim and ylim. axes sets the position
of the axes (the frame in which your plots are made) and these
coordinates are in figure coords -- 0,0 is lower left of the figure
and 1,1 is upper right.
JDH

As long as this is being discussed, I'll put in my 0ドル.2
I think encouraging "import *" Is a BAD IDEA. Even for interactive use.
Since I've used Python, the only time I've used import * is for Numeric, 
and now I've started using import Numeric as N.
> Namespaces are one honking great idea -- let's do more of those!
That's why I'm resistant to using import *
Anyway, I'm very happy about matplotlib because it does most of what I 
need, does it well, works with wx and AGG, and is constantly being improved.
However, even though I'm an old matlab fanatic, I'm not thrilled with 
the efforts to make matplotlib matlab-like. I have various reasons for 
using Python rather than matlab, but one of the primary ones is that I 
like the language better, and I like OO. Hence, I'd much rather have a 
platting package be pythonic than matlab-like. Name spaces and OO are a 
big part of this.
Name spaces and an OO interface are very linked, by the way. The reason 
NumPy is commonly used with the import * approach is that there are a 
LOT of functions exposed, and we all get tired of typing Numeric. (or 
even N.). However, many of those functions should really be methods. 
I've always been confused by the Numeric docs, which suggest that the 
function interface is necessary so that you can do, for instance:
B = Numeric.transpose(A)
and A doesn't have to be a Numeric Array. This would be very cool if 
transpose (and many other ufuncs) returned the type that was input, but 
it doesn't, it returns an array, so it's really the equivalent of:
B = array(A)
B.transpose(B)
if transpose were an array method. Is it really so onerous to type that 
extra line? I like the extra line, because it makes things clear to me 
what's going on.
anyway, to cut my rant short, here is my vote for matplotlib development 
(not that I get a vote, but hopefully I'll have time to help out someday)
1) Deprecate "from pylab import *"
2) Improve the OO interface to make it just as easy to use.
Even with improvements, I understand that it will be a little bit more 
awkward to use in interactive mode, but how much does anyone really do 
interactively anyway? Even with Matlab, I soon learned that if I'm 
typing more that 3 lines, I should put it in a script.
I know we can do (2) without doing (1), but if (1) is what's in all the 
examples, it's going to get used.
OK, enough of my rant.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

 Hi,
 so I found some answer to the second problem, to draw a rectangle at a 
certain place you add to define the limit for gca instance, by default 
the limit of the figure are not use:
from pylab import *
from matplotlib.patches import Rectangle
ax = gca()
set(gca(),'xlim',[0,10],'ylim',[0,10])
p = Rectangle((1,1),3,3,fill=False)
ax.add_patch(p)
or more pythonic:
from pylab import *
from matplotlib.patches import Rectangle
ax = gca()
ax.set_xlim([0,10])
ax.set_ylim([0,10])
p = Rectangle((1,1),3,3,fill=False)
ax.add_patch(p)
but if you use axis only without redefine gca limit that don't work:
from pylab import *
from matplotlib.patches import Rectangle
axis([0,10],[0,10])
ax = gca()
p = Rectangle((1,1),3,3,fill=False)
ax.add_patch(p)
I understand that gca return an instance but perhaps that will be a good 
idea if by default that will use the axis of the courrant figure and not 
[0,1,0,1].
Thanks,
 Nicolas
Humufr wrote:
> Hi,
>
> I have a problem to draw a rectangle:
>
> The first is that I can't arrive to draw a rectangle with ipython 
> -pylab, the script who work when it's launch independantly is not 
> working interactively. The rectangle is not draw. Perhaps it's normal 
> but I don't think.
>
> The second problem I have is to draw a rectangle at a certain position 
> with certain height and width. It's seems (at least when I tried to 
> use it) that the position must be done relatively at the window and 
> not from the plot. It's not very convenient because if I have a plot 
> draw between 1 and 100 in x and y, to draw the rectangle I add to use 
> something between 0 and 1 so I had to rescale the rectangle.
>
> Thanks,
>
> Nicolas

On Thu, 2005年01月20日 at 09:28, John Hunter wrote:
> >>>>> "Norbert" == Norbert Nemec <No...@ne...> writes:
> 
> Norbert> Why not go one step higher and discuss the issue in
> Norbert> Numeric and numarray? It seems like a typical problem in
> Norbert> the python community that conflicts are not discussed and
> Norbert> decided centrally but instead everyone just does things
> Norbert> their way. The possibility to change and fix everything
> Norbert> by a wrapper module really causes a huge mess in the
> Norbert> various libraries...
> 
> I still believe that this is not a problem with Numeric or numarray
> [1]. There is nothing to fix there in my opinion (Todd or Perry can
> jump in here). Those modules provide min/max/etc in their respective
> mlab modules, which do exactly what they advertise: they provide
> matlab functionality and matlab provides min/max with a different
> signature than python's. 
I agree with this; pylab has a very clear "right" to choose whatever
API semantics it wants. It occurs to me now that numerix probably needs
to evolve away from MLab back to pure Numeric, but that has nothing to
do with the pylab API which can remain as it is.
I agree that overriding builtins is a mistake, but I think we're in a
bind here.
[snip]
> There is no problem as long as the user is
> mindful of namespaces; there's a reason your mother always told you
> never to do 'from somemodule import *'. I tend to heed that advice,
This is my position as well: Don't use from *. Using it opens you up
to new names appearing in your module namespace based on changes outside
the module; using it non-interactively is an engineering error. 
[snip]
> Perhaps I'm wrong, but I suspect that 1) Numeric developers would be
> very reluctant to change a name that has been in the code base for
> god-knows-how-long and thus would break lots of code, and 2) the
> functions in MLab actually do exactly what they are designed to do and
> are well advertised as such. I for one would definitely be against a
> change, because when I do MLab.min I want the matlab signature.
I have a strong aversion to breaking Numeric compatibility, so I need
to reverse my earlier "unleash Andrew" comment and we should keep
numerix compatible with Numeric.
[snip]
> MLab versions. Two different packages/modules can rightly have
> different policies on how closely they want to abide by the matlab
> names.
I agree. That's why Python has namespaces.
IMHO, this boils down to choosing the lesser of two evils, so if we're
talking about breaking APIs in the name of purity or remaining
compatible with Numeric but a little impure, I'd prefer compatible. My
$.02
Cheers,
Todd

>>>>> "Norbert" == Norbert Nemec <No...@ne...> writes:
 Norbert> Why not go one step higher and discuss the issue in
 Norbert> Numeric and numarray? It seems like a typical problem in
 Norbert> the python community that conflicts are not discussed and
 Norbert> decided centrally but instead everyone just does things
 Norbert> their way. The possibility to change and fix everything
 Norbert> by a wrapper module really causes a huge mess in the
 Norbert> various libraries...
I still believe that this is not a problem with Numeric or numarray
[1]. There is nothing to fix there in my opinion (Todd or Perry can
jump in here). Those modules provide min/max/etc in their respective
mlab modules, which do exactly what they advertise: they provide
matlab functionality and matlab provides min/max with a different
signature than python's. There is no problem as long as the user is
mindful of namespaces; there's a reason your mother always told you
never to do 'from somemodule import *'. I tend to heed that advice,
with the one exception being pylab, in which I try to provide a
matlab-like environment where the symbols are all provided in a single
namespace.
Note also that matplotlib's numerix module is more than a simple
numarray/Numeric switcher because it *combines* symbols from all of
their respective submodules. Eg from na_imports, which is where
matplotlib.numerix gets the numarray symbols from
 from numarray.linear_algebra.mlab import *
 from numarray import *
 import numarray.linear_algebra as LinearAlgebra
 import numarray.linear_algebra.mlab as MLab
 from numarray.linear_algebra import inverse, eigenvectors
 from numarray.convolve import convolve
 from numarray.fft import fft
 import numarray.random_array as RandomArray
 from numarray.numeric import nonzero
So we are taking names from a bunch of different namespaces and
pooling them in numerix, which is then pooled into pylab. This is a
good thing for users who want a matlab-like environment, and who want
to be able to switch between Numeric and numarray w/o having to write
a bunch of conditional code to handle the different directory layouts,
but as we've observed can bite you if you are unaware that pylab is
providing matlab names rather than python names in some cases.
Perhaps I'm wrong, but I suspect that 1) Numeric developers would be
very reluctant to change a name that has been in the code base for
god-knows-how-long and thus would break lots of code, and 2) the
functions in MLab actually do exactly what they are designed to do and
are well advertised as such. I for one would definitely be against a
change, because when I do MLab.min I want the matlab signature.
Basically the question is: when confronted with a name clash, should a
module prefer python over matlab. Numeric.MLab rightly (I think)
chose to go with matlab names, but some disagree with this decision
(yes, you Fernando). For pylab, which has its genesis in matlab
compatibility but serves a wider community that may not know or care
about matlab, it may be sensible to make a different choice. In
brief, I don't think it is terribly confusing for Numeric.MLab to have
one policy that when confronting a name clash they go with the matlab
name, and for matplotlib.numerix have a different policy and say we'll
go with the built-in and provide the amin, amax, etc symbols for the
MLab versions. Two different packages/modules can rightly have
different policies on how closely they want to abide by the matlab
names.
JDH
[1] http://sourceforge.net/mailarchive/message.php?msg_id=10514961

Am Mittwoch, 19. Januar 2005 23:39 schrieb John Hunter:
> I thought we last left this with the idea that these changes would be
> made in matplotlib.numerix level
Why not go one step higher and discuss the issue in Numeric and numarray? It 
seems like a typical problem in the python community that conflicts are not 
discussed and decided centrally but instead everyone just does things their 
way. The possibility to change and fix everything by a wrapper module really 
causes a huge mess in the various libraries...
-- 
_________________________________________Norbert Nemec
 Bernhardstr. 2 ... D-93053 Regensburg
 Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
 eMail: <No...@Ne...>

 Hi,
I have a problem to draw a rectangle:
The first is that I can't arrive to draw a rectangle with ipython 
-pylab, the script who work when it's launch independantly is not 
working interactively. The rectangle is not draw. Perhaps it's normal 
but I don't think.
The second problem I have is to draw a rectangle at a certain position 
with certain height and width. It's seems (at least when I tried to use 
it) that the position must be done relatively at the window and not from 
the plot. It's not very convenient because if I have a plot draw between 
1 and 100 in x and y, to draw the rectangle I add to use something 
between 0 and 1 so I had to rescale the rectangle.
Thanks,
 Nicolas