matplotlib-users — Discussion related to using matplotlib

Re: [Matplotlib-users] "from pylab import *" will no longer override min() and max()

[Andrew S. <str...@as...>]

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

Re: [Matplotlib-users] trace a rectangle

[John H. <jdh...@ac...>]

>>>>> "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

Re: [Matplotlib-users] trace a rectangle

[Humufr <hu...@ya...>]

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

Re: [Matplotlib-users] trace a rectangle

[John H. <jdh...@ac...>]

>>>>> "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

Re: [Matplotlib-users] "from pylab import *" will no longer override min() and max()

[Chris B. <Chr...@no...>]

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...

Re: [Matplotlib-users] trace a rectangle

[Humufr <hu...@ya...>]

             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

Re: [Matplotlib-users] "from pylab import *" will no longer override min() and max()

[Todd M. <jm...@st...>]

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

Re: [Matplotlib-users] "from pylab import *" will no longer override min() and max()

[John H. <jdh...@ac...>]

>>>>> "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

Re: [Matplotlib-users] "from pylab import *" will no longer override min() and max()

[Norbert N. <No...@ne...>]

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...>

[Matplotlib-users] trace a rectangle

[Humufr <hu...@ya...>]

             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

Re: [Matplotlib-users] "from pylab import *" will no longer override min() and max()

[danny s. <dan...@ya...>]

my comments on modules being exposed appear to have fallen into a
vacuum. I still ask if "from matplotlib import *" should expose the
time module or the sys module?

Danny 

--- John Hunter <jdh...@ac...> wrote:

> >>>>> "Andrew" == Andrew Straw <str...@as...> writes:
> 
>     Andrew> I've just committed a patch to stop "from pylab import *"
>     Andrew> from overriding Python builtin functions like min() and
>     Andrew> max().
> 
>     Andrew> Spurred on by the potential of matplotlib included in the
>     Andrew> Enthought Edition of Python, I've gone ahead and added
> the
>     Andrew> following lines to pylab.py in CVS:
> 
>     Andrew> import __builtin__ min = __builtin__.min max =
>     Andrew> __builtin__.max sum = __builtin__.sum round =
>     Andrew> __builtin__.round abs = __builtin__.abs
> 
> 
> I thought we last left this with the idea that these changes would be
> made in matplotlib.numerix level, and that the old symbols would
> still
> be provided under the names amin, amax, aabs, etc..., and the
> existing
> matplotlib code and examples would be ported to the new naming
> scheme.
> Eg,
>
http://sourceforge.net/mailarchive/forum.php?thread_id=6323208&forum_id=36187
> 
> My fear is that if we do this in pylab but not numerix, confusion
> will
> only deepen.
> 
> FYI, we have until late Thursday I think to get anything we want in
> before the final enthon roll-up.
> 
> JDH
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive
> Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF,
> etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250

Re: [Matplotlib-users] Artefacts in contour plot?

[Dominique O. <Dom...@po...>]

Nadia Dencheva wrote:
> I've been able to reproduce the problem on MacOSX (after the 
> correction), although I don't have an answer to what's causing it now.

Results seem inconsistent; if i replace the 'rosenbrock' function in my 
previous script with

   def saddle(x,y): return y**2 - x**2

and use

   x = y = arange( -2, 2, 0.1 )

then

   contour( Z, x = X, y = Y, levels = 30, origin = 'lower' )

produces the zigzags, but

   contour( Z, x = X, y = Y, levels = 30, origin = 'upper' )

doesn't. The same isn't true of the rosenbrock function. I wonder if the 
zigzags might be coming from the C function which computes the levels. 
Is there a C interface to that function somewhere that we could try?

Dominique

Re: [Matplotlib-users] "from pylab import *" will no longer override min() and max()

[John H. <jdh...@ac...>]

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:

    Andrew> I've just committed a patch to stop "from pylab import *"
    Andrew> from overriding Python builtin functions like min() and
    Andrew> max().

    Andrew> Spurred on by the potential of matplotlib included in the
    Andrew> Enthought Edition of Python, I've gone ahead and added the
    Andrew> following lines to pylab.py in CVS:

    Andrew> import __builtin__ min = __builtin__.min max =
    Andrew> __builtin__.max sum = __builtin__.sum round =
    Andrew> __builtin__.round abs = __builtin__.abs


I thought we last left this with the idea that these changes would be
made in matplotlib.numerix level, and that the old symbols would still
be provided under the names amin, amax, aabs, etc..., and the existing
matplotlib code and examples would be ported to the new naming scheme.
Eg,
http://sourceforge.net/mailarchive/forum.php?thread_id=6323208&forum_id=36187

My fear is that if we do this in pylab but not numerix, confusion will
only deepen.

FYI, we have until late Thursday I think to get anything we want in
before the final enthon roll-up.

JDH

[Matplotlib-users] "from pylab import *" will no longer override min() and max()

[Andrew S. <str...@as...>]

I've just committed a patch to stop "from pylab import *" from 
overriding Python builtin functions like min() and max().

Spurred on by the potential of matplotlib included in the Enthought 
Edition of Python, I've gone ahead and added the following lines to 
pylab.py in CVS:

import __builtin__
min = __builtin__.min
max = __builtin__.max
sum = __builtin__.sum
round = __builtin__.round
abs = __builtin__.abs

Although I didn't do anything about it, and without having thought about 
it deeply, I like Norbert Nemec's idea of introducing __round__ (and 
__min__, __max__, and __sum__ for sequences) methods into standard 
Python, thus eliminating the need for functions in numpy/numarray to 
accomplish these same tasks.  Unfortunately, I don't have the time to 
get into this right now.  (This approach would also ask numpy/numarray 
to eliminate their abs() function in favor of implementing an __abs__() 
method on array types.)

Cheers!
Andrew

Re: [Matplotlib-users] ticklabel fontsize Q

[John H. <jdh...@ac...>]

>>>>> "Engelsma," == Engelsma, Dave <D.E...@La...> writes:

    Dave> Hi John, I'm wondering how to set the fontsize of the
    Dave> ticklabels on an axis (y axis in this case). I would
    Dave> like to do something as shown in the third line of
    Dave> code:

    Dave> .  .  .  graph_axes.set_xlim([0,24])
    Dave> graph_axes.set_ylim([0,MaxHourlyDowntime+100])
    Dave> graph_axes.set_yticklabels(fontsize=6) .  .  .

  for label in graph_axes.get_yticklabels(): 
      label.set_size(6)

Note you can also change the default label size "system wide" using
the rc param tick.labelsize - http://matplotlib.sf.net/.matplotlibrc
.  You can either change it in the rc file itself, or set it for the
application with, for example

from matplotlib import rc
rc('tick', labelsize=6)

This will affect both the x and y tick labels....

    Dave> but that won't work, because I'm not supply a list of
    Dave> ticklabels. Is there a simple answer to this? (I've
    Dave> looked through the mailing lists and the class library
    Dave> documentation with no success...

    Dave> Also, attached is a screenshot of an statistical
    Dave> application that is almost complete... all of the
    Dave> graphing and plotting functions are 100% complete and
    Dave> work courtesy of matplotlib. (you had helped me with a
    Dave> few issues last year and requested a screen shot...)

Cool -- thanks!

JDH

Re: [Matplotlib-users] Re: how show values *decreasing* up the y-axis like in a pcolor plot?

[John H. <jdh...@ac...>]

>>>>> "Andrew" == Andrew Becker <be...@da...> writes:

    Andrew> Hi - However, if you interact with the window (zoom in)
    Andrew> than this information is lost.  It would be nice to be
    Andrew> able to set a permanant attritute for the axis,
    Andrew> yaxis.reversed = True, or some such thing.

I assume you are working with an older version of matplotlib....
Gergory fixed this (I can't remember the version number it was fixed
din ) but it works as of the latest release.

JDH

[Matplotlib-users] Re: how show values *decreasing* up the y-axis like in a pcolor plot?

[Andrew B. <be...@da...>]

Hi - 

   However, if you interact with the window (zoom in) than this
information is lost.  It would be nice to be able to set a permanant
attritute for the axis, yaxis.reversed = True, or some such thing.

Andy

> ylim(ymax, ymin)
> OR
> xlim(xmax, xmin)
> 
> See, for example, http://matplotlib.sf.net/examples/invert_axes.py

Re: [Matplotlib-users] Re:

[John H. <jdh...@ac...>]

>>>>> "Dominique" == Dominique Orban <Dom...@po...> writes:

    Dominique> Is there any reason why we can't use the usual TeX
    Dominique> symbols for the accents, e.g.: \'{e} for acute accent,
    Dominique> \`{e} for grave, \"{a} for umlaut, etc.?

FYI, all of these *are* standard TeX commands.  The shortcuts are also
now in matplotlib CVS (I added them after my post yesterday); as in
TeX, the curly's are optional, so you can do \"{o}, \ddot{o}, \"o or
\ddot o.

JDH

[Matplotlib-users] ticklabel fontsize Q

[Engelsma, D. <D.E...@La...>]

Hi John,

I'm wondering how to set the fontsize of the ticklabels on an axis (y
axis in this case). I would like to do something as shown in the third
line of code:

.
.
.
graph_axes.set_xlim([0,24])
graph_axes.set_ylim([0,MaxHourlyDowntime+100])
graph_axes.set_yticklabels(fontsize=6)
.
.
.
        
but that won't work, because I'm not supply a list of ticklabels. Is
there a simple answer to this? (I've looked through the mailing lists
and the class library documentation with no success...

Also, attached is a screenshot of an statistical application that is
almost complete... all of the graphing and plotting functions are 100%
complete and work courtesy of matplotlib. (you had helped me with a few
issues last year and requested a screen shot...)

Thanks in advance,

Dave Engelsma

[Matplotlib-users] Re:

[Dominique O. <Dom...@po...>]

> To: Matt Newville <new...@ca...>
> Cc: Mayer Gerhard <ger...@co...>,
> 	<mat...@li...>
> Subject: Re: AW: [Matplotlib-users] French characters
> From: John Hunter <jdh...@ac...>
> Date: Tue, 18 Jan 2005 15:49:57 -0600
> 
> 
>>>>>>"Matt" == Matt Newville <new...@ca...> writes:
> 
> 
>     Matt> Sorry for the confusion, that's not what I meant.  I think
>     Matt> that the acute sign would have to be added to the list of
>     Matt> symbols that mathtext can handle.  That would probably mean
>     Matt> both special code in mathtext.py and an entry in
>     Matt> _mathtext_data.py. I'm not sure what the right entry in the
>     Matt> font table would be, as I don't understand the entries in
>     Matt> the latex_to_bakoma dictionary in _mathtext_data.py at all.
> 
> I just added support for accents in general to mathtext.  The
> following accents are provided: \hat, \breve, \grave, \bar, \acute,
> \tilde, \vec, \dot, \ddot.  All of them have the same syntax, eg to
> make an overbar you do \bar{o} or to make an o umlaut you do \ddot{o}.

Is there any reason why we can't use the usual TeX symbols for the 
accents, e.g.: \'{e} for acute accent, \`{e} for grave, \"{a} for 
umlaut, etc.?

There has been an attempt to introduce LaTeX commands into Powerpoint at 
some point (some package from Stanford I believe, called TeXPoint). It 
produces nice equations but very few use it simply because the commands 
aren't standard TeX.

Dominique

Re: [Matplotlib-users] Artefacts in contour plot?

[kristen k. <co...@ya...>]

Hola 
I have experienced exactly the same problem when using
 the contour plot with a windows installation.
Kristen



--- John Hunter <jdh...@ac...> wrote:

> >>>>> "Dominique" == Dominique Orban
> <Dom...@po...> writes:
> 
>     Dominique> If anyone is able to reproduce the
> problem, then it
>     Dominique> might indeed be a problem. If not,
> perhaps something is
>     Dominique> funny with my box.
> 
> A complete script which replicates the problem, w/
> an attached saved
> figure which shows it, would help immensely.
> 
> JDH
> 
> 
> 
>
-------------------------------------------------------
> The SF.Net email is sponsored by: Beat the
> post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt
> from ThinkGeek.
> It's fun and FREE -- well,
> almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
>
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250

[Matplotlib-users] The (new) navigation toolbar under WXAgg

[Michael S. <mic...@as...>]

Hi!

A few weeks ago I started using Python, Matplotlib, and WxPython for a new
project, and continue to be quite impressed. I now ran into a problem
however, which I cannot solve in a decent way: I am using a slightly more
complicated GUI than the ones in the examples, and positioned a Matplotlib
canvas and the toolbar inside a sizer, which is not the "root"-most sizer
(in the __init__ constructor of my wx.Frame-derived class I call
"self.SetSizer(sizer_A)" while I add the Matplotlib canvas to a different
sizer_B, kind of like "self.sizer_B.Add(self.canvas, 1, wxTOP | wxLEFT |
wxEXPAND)", with sizer_B being added via intermediate objects to sizer_A).

 

What now happens isn't completely clear to me - but it looks as if the
events aren't handled correctly anymore (nothing at all happens, if I use
the custom sizing given in one of the examples; if I call
self.SetToolBar(self.toolbar) instead, some of the buttons work, I think).
If I position both the canvas and the toolbar in the "root"-most sizer
instead, everything runs fine. Does anyone know a way to solve this?

 

I am using WxGlade to write some of the GUI code, because it seems to save
some typing work. Below, I added a simple example of the problem I
encounter. I basically combined the "embedding_in_wx4.py" with some
WxGlade-created code (the frame contains a sizer_A with a button and a
sizer_2 which contains the sizer_B that in turn contains the canvas. Of
course, this setup would be possible without this structure, it is just
meant to illustrate...) 

 

Does someone also have some input on WxGlade or other choices that are out
there? What about Boa Constructor? Is that any good? Currently I am using
SPE...

 

Thanks a lot in advance for your help,

 

Michael Sielemann

 

 

 

______ example code (not working like this, to illustrate the problem I am
encountering ________________

 

 

#!/usr/bin/env python

# -*- coding: ISO-8859-1 -*-

# generated by wxGlade 0.3.5.1 on Tue Jan 18 17:42:12 2005

 

 

from matplotlib.numerix import arange, sin, pi

 

import matplotlib

 

# uncomment the following to use wx rather than wxagg

#matplotlib.use('WX')

#from matplotlib.backends.backend_wx import FigureCanvasWx as FigureCanvas

 

# comment out the following to use wx rather than wxagg

matplotlib.use('WXAgg')

from matplotlib.backends.backend_wxagg import FigureCanvasWxAgg as
FigureCanvas

from matplotlib.backends.backend_wx import NavigationToolbar2Wx

 

from matplotlib.backends.backend_wx import _load_bitmap

from matplotlib.figure import Figure

from matplotlib.numerix import rand

 

 

import wx

 

class MyNavigationToolbar(NavigationToolbar2Wx):

    """

    Extend the default wx toolbar with your own event handlers

    """

    ON_CUSTOM = wx.NewId()

    def __init__(self, canvas, cankill):

        NavigationToolbar2Wx.__init__(self, canvas)

 

        # for simplicity I'm going to reuse a bitmap from wx, you'll

        # probably want to add your own.

        self.AddSimpleTool(self.ON_CUSTOM, _load_bitmap('stock_left.xpm'),

                           'Click me', 'Activate custom contol')

        EVT_TOOL(self, self.ON_CUSTOM, self._on_custom)

 

    def _on_custom(self, evt):

        # add some text to the axes in a random location in axes (0,1)

        # coords) with a random color

 

        # get the axes

        ax = self.canvas.figure.axes[0]

 

        # generate a random location can color

        x,y = tuple(rand(2))

        rgb = tuple(rand(3))

 

        # add the text and draw

        ax.text(x, y, 'You clicked me',

                transform=ax.transAxes,

                color=rgb)

        self.canvas.draw()

        evt.Skip()

 

 

 

class MyFrame(wx.Frame):

    def __init__(self, *args, **kwds):

        # begin wxGlade: MyFrame.__init__

        kwds["style"] = wx.DEFAULT_FRAME_STYLE

        wx.Frame.__init__(self, *args, **kwds)

        self.panel_1 = wx.Panel(self, -1)

        self.panel_2 = wx.Panel(self.panel_1, -1)

        self.button_1 = wx.Button(self.panel_1, -1, "Useless")

        

        # moved downwards

        #self.__set_properties()

        #self.__do_layout()

        # end wxGlade

        

        # "embedding_in_wx4.py" sample code integration

        self.SetBackgroundColour(wxNamedColor("WHITE"))

        

        self.figure = Figure(figsize=(5,4), dpi=100)

        self.axes = self.figure.add_subplot(111)

        

        self.canvas = FigureCanvas(self, -1, self.figure)

        

        t = arange(0.0,3.0,0.01)

        s = sin(2*pi*t)

        

        self.axes.plot(t,s)

        

        self.toolbar = MyNavigationToolbar(self.canvas, True)

 

        self.__set_properties()

        self.__do_layout()

        # end of "embedding_in_wx4.py" sample code integration

 

    def __set_properties(self):

        # begin wxGlade: MyFrame.__set_properties

        self.SetTitle("frame_1")

        self.SetSize((600, 500))

        # end wxGlade

        

        # "embedding_in_wx4.py" sample code integration

        self.toolbar.Realize()

        # end of "embedding_in_wx4.py" sample code integration

        

    def __do_layout(self):

        # begin wxGlade: MyFrame.__do_layout

        sizer_A = wx.BoxSizer(wx.VERTICAL)

        sizer_2 = wx.BoxSizer(wx.HORIZONTAL)

        

        # next lines were modified by hand

        self.sizer_B = wxBoxSizer(wxVERTICAL)

        self.sizer_B.Add(self.canvas, 1, wxTOP | wxLEFT | wxEXPAND)

 

        sizer_2.Add(self.sizer_B, 2, wxTOP | wxLEFT | wxEXPAND, 0)

 

        sizer_2.Add(self.button_1, 1, wx.EXPAND|wx.FIXED_MINSIZE, 0)

        self.panel_1.SetAutoLayout(True)

        self.panel_1.SetSizer(sizer_2)

        sizer_2.Fit(self.panel_1)

        sizer_2.SetSizeHints(self.panel_1)

        sizer_A.Add(self.panel_1, 1, wx.EXPAND, 0)

        #self.SetAutoLayout(True)

        #self.SetSizer(sizer_A)

        #self.Layout()

        # end wxGlade

 

        # "embedding_in_wx4.py" sample code integration

        if wxPlatform == '__WXMAC__':

            # Mac platform (OSX 10.3, MacPython) does not seem to cope with

            # having a toolbar in a sizer. This work-around gets the buttons

            # back, but at the expense of having the toolbar at the top

            self.SetToolBar(self.toolbar)

        else:

            # On Windows platform, default window size is incorrect, so set

            # toolbar width to figure width.

            tw, th = self.toolbar.GetSizeTuple()

            fw, fh = self.canvas.GetSizeTuple()

            # By adding toolbar in sizer, we are able to put it at the
bottom

            # of the frame - so appearance is closer to GTK version.

            # As noted above, doesn't work for Mac.

            self.toolbar.SetSize(wxSize(fw, th))

            self.sizer_B.Add(self.toolbar, 0, wxLEFT | wxEXPAND)

 

 

        # Capture the paint message        what was the use of this?

        #EVT_PAINT(self, self.OnPaint)        

 

        # update the axes menu on the toolbar

        self.toolbar.update()  

        #self.SetSizer(self.sizer)

        #self.Fit()

 

        # end of "embedding_in_wx4.py" sample code integration

 

        self.SetAutoLayout(True)

        self.SetSizer(sizer_A)

        self.Layout()

 

 

 

# end of class MyFrame

 

class MyAtmosphereApp(wx.App):

    def OnInit(self):

        wx.InitAllImageHandlers()

        frame_1 = MyFrame(None, -1, "")

        self.SetTopWindow(frame_1)

        frame_1.Show()

        return 1

 

# end of class MyAtmosphereApp

 

if __name__ == "__main__":

    import gettext

    gettext.install("AtmosphereApp") # replace with the appropriate catalog
name

 

    # more of my init stuff

    

 

    AtmosphereApp = MyAtmosphereApp(0)

    AtmosphereApp.MainLoop()

 

 

Re: [Matplotlib-users] Artefacts in contour plot?

[Nadia D. <den...@st...>]

I've been able to reproduce the problem on MacOSX (after the 
correction), although I don't have
an answer to what's causing it now.

Nadia Dencheva

On Jan 18, 2005, at 2:38 PM, Dominique Orban wrote:

> (Sorry, sending this again to correct a typo -- i inverted small and 
> large below)
>
> I have made several experiments; I have installed the latest matplotlib
> (with the 'contour' update) in both Win XP and SuSE Linux Pro 9.1. I
> made sure to uninstall everything pertaining to matplotlib before
> installing the latest version. In Windows, I use the pre-built
> distribution, and in Linux I compile it myself. The situation is this:
>
> - In Linux, some zigzagging lines appear when there are few points to
> interpolate. Eg, if i generate my grid from
> 	x = y = arange( -1, 1, delta ),
> zigzags would appear for LARGE values of delta (eg, delta = 0.2; ie 
> too few values of x and/or y). However, it seems that those zigzags 
> are a normal consequence of a large value of delta. For SMALLER 
> deltas, the contours are beautiful.
>
> - In XP, the same as above happens. But I see additional lines that
> don't seem to represent anything meaningful. I made sure I was
> performing a clean install. Are there updates to other packages I 
> should
> consider? Pygtk? This happened with both the TkAgg and GTKAgg backends.
> Perhaps I should try compiling matplotlib myself?
>
> If anyone is able to reproduce the problem, then it might indeed be a
> problem. If not, perhaps something is funny with my box.
>
> Thanks,
> Dominique
>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Re: AW: [Matplotlib-users] French characters

[John H. <jdh...@ac...>]

>>>>> "Matt" == Matt Newville <new...@ca...> writes:

    Matt> Sorry for the confusion, that's not what I meant.  I think
    Matt> that the acute sign would have to be added to the list of
    Matt> symbols that mathtext can handle.  That would probably mean
    Matt> both special code in mathtext.py and an entry in
    Matt> _mathtext_data.py. I'm not sure what the right entry in the
    Matt> font table would be, as I don't understand the entries in
    Matt> the latex_to_bakoma dictionary in _mathtext_data.py at all.

I just added support for accents in general to mathtext.  The
following accents are provided: \hat, \breve, \grave, \bar, \acute,
\tilde, \vec, \dot, \ddot.  All of them have the same syntax, eg to
make an overbar you do \bar{o} or to make an o umlaut you do \ddot{o}.

The changes are in CVS - make sure you get mathtext.py revision 1.9 or
later, and _mathtext_data.py revision 1.5 or later.

Here is the test script I used:

    from pylab import *
    plot(range(10))
    title(r'$\ddot{o}\acute{e}\grave{e}\hat{O}\breve{i}\bar{A}\tilde{n}\vec{q}\dot{x}$', fontsize=20)
    show()

Hope this helps!
JDH

PS:

Matt, the _mathtext_data dictionary latex_to_bakoma maps the TeX
symbol to a fontfilename, glyph index tuple.  To get the character
code in the font file corresponding to the glyph index, you can use
the FT2Font charmap dict

Here's a little demo script which shows you how to use the dict to
load a freetype2 glyph struct for a latex symbol "delta" from the
appropriate cm*.ttf file

    import os
    from matplotlib import get_data_path
    from matplotlib.ft2font import FT2Font
    from matplotlib._mathtext_data import latex_to_bakoma


    name, glyphind = latex_to_bakoma[r'\delta']
    fname = os.path.join(get_data_path(), name + '.ttf')

    font = FT2Font(fname)
    charmap = font.get_charmap()
    ccode = charmap[glyphind]
    glyph = font.load_char(ccode)

    print glyph.width/64.

Re: [Matplotlib-users] Artefacts in contour plot?

[John H. <jdh...@ac...>]

>>>>> "Dominique" == Dominique Orban <Dom...@po...> writes:

    Dominique> If anyone is able to reproduce the problem, then it
    Dominique> might indeed be a problem. If not, perhaps something is
    Dominique> funny with my box.

A complete script which replicates the problem, w/ an attached saved
figure which shows it, would help immensely.

JDH