matplotlib-users Mailing List for matplotlib (Page 1395)

Hello Nicolas

On Wed, Dec 01, 2004 at 09:34:51AM -0500, Humufr wrote:
> Another strange thing I remark is:
>=20
> if you are doing:
>=20
> plot([1,2],[4,5])
> legend(('toto'))
>=20
> the text for the legend is vertical and not horizontal, that's work=20
> normally when we are using more than one argument.
This happens because ('toto') is not a one-element list
but a string.  If you write

  plot([1,2],[4,5])
  legend(('toto',))

instead it works as expected.

I hope this helps,
Jochen
--=20
http://seehuhn.de/

Hi John,

I tried:


 > Yep, it's a bug.  Replace the indicate line from
 > axes.py
 >
 >    loc = kwargs.gry('loc', 1)
 >                
 > with
 >
 >    loc = kwargs.get('loc', 1)
 >                 ^^^

That correct the problem with legend() but I have another problem and I 
think it's another bug (not sure) it's not possible to tell to 
matplotlib in this case o use the "loc" keywords more it's impossible to 
use this keywords. There are always an error message:
  File "<string>", line 3, in legend
  File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 1502, 
in legend
    self.legend_ = Legend(self, lines, labels, loc, **kwargs)
TypeError: __init__() got multiple values for keyword argument 'loc'


example:

plot ([2,3],[4,5])
legend(('toto'),loc=2)

I tried everything: loc='upper left', loc=0,1 , loc=(0,1), loc=2 etc. 
Nothing work but if I omit the " loc=  " . It's ok and that explain 
probably why I cant do something like:

plot([1,2],[4,5],label='toto')
legend(loc='upper left')


Another strange thing I remark is:

if you are doing:

plot([1,2],[4,5])
legend(('toto'))

the text for the legend is vertical and not horizontal, that's work 
normally when we are using more than one argument.

Thank you very much for you fast answer and sorry for the second 
question I had to verify more precisely in the archival.


Nicolas

Hi,

I am looking for a simple way to have a plot on which I can interact
with a cursor. An example:
- I have two plots on the same window and I wish to perform
  some action on these plots (change the scale, plot a different slice
  of an array, etc) depending on the pressed key and its location in the
  window. So if I am within the first plot, select the nearest point
  and redraw some info related to that point in the second plot (only
  when clicking with the left mouse button for example).

  If I type ''z'' (for zoom) then it is waiting for a second ''z''
  interpreted as the 2 corners of a rectangle and a zoom is made
  for this region of the plot.

I can do all this easily with ppgplot (pgplot module), but I failed
to write something simple with matplotlib.

So my questions:
- is there a simple way to do this? (interact with the cursor, 
mouse/keyboard
  and retrieve the location so further actions can be taken)

thanks a lot in advance

Eric Emsellem

> 1) Seems to me that repr for the plot objects could be blanked out for 
> interactive mode. Having python print out what it does now isn't 
> usually useful and in some cases (like error bars) leads to a dump on 
> the screen. Any reason not to make repr mode dependent (or at least 
> configurable)?
> 
> John pointed out that one of the worst offenders (error bars) actually 
> return lists of plot objects so it wouldn't do much good to override 
> repr for the plot objects unless one used a list object where repr was 
> overridden as well. The annoyance factor in interactive use is perhaps 
> sufficient to do this though. What do others think?

This has not really bothered me, but if this dissapear I will not be sad
either...so 0

> 2) Any support for being able to specify colors using more than single 
> character codes (say, using "red" or "green", and line styles and 
> symbols with more descriptive terms like "dashed". This is not in place 
> of the existing scheme, but as a more verbose alternative. Along those 
> lines, allowing something like:
> 
> plot(x1, y1, x2, y2, x3, y3, color=['red','green','blue'])

good idea, but I am well used to matlab shortcuts so +0

> 3) Tick control can be awkward if one simply wants to add an integral 
> number of minor ticks to the chosen major tick interval. Currently 
> using minor ticks forces one to access the plot objects, and specify 
> the major tick interval as well. It would be nice if one could just ask 
> for n minor ticks for each major tick interval by using the appropriate 
> keyword (name tbd). Some illustrations of possible alternatives:
> 
> plot(x, y, xmajor=5)
> plot(x, y, xmajor=5, xminor=1)
> plot(x, y, xminordiv=5) # 5 minor ticks per major regardless  of major 
> tick size
> 
> Generally, I expect that people set these interactively after plotting 
> without these options. When they see what is automatically produced, 
> this is a simple way of tweaking the plot without doing a lot of object 
> manipulation.

very good idea, +1: ticking adjustment is common before outputting a
figure for printing, and this will make this tinkering more easy...

> 4) The current means of doing overplotting is modal and confusing to 
> many used to IDL's approach. It is easy to forget what the current mode 
> is. IDL uses different commands (e.g., oplot vs plot) to overplot. Some 
> alternatives John and I mentioned:
> 
> a) generate 'o' versions of all plot functions (oplot, oimplot, etc.). 
> Easy to do but clutters the namespace.
> 
> b) have an 'over' function to apply to all such commands: over(plot, x, 
> y, color='g')
> 
> c) use a keyword argument to only apply to the function call:
> plot(x, y, hold=True) # doesn't change the hold state after completion, 
> but does overplot
> 
> I'm happy to have c) myself.

+1 for c), +0 for a) and -0 for b), I do not like the idea of having two
time the number of functions for this...if only because it will clutter
help(matplotlib.matlab) or dir(matplotlib.matlab) for example

> 5) For many customizations plot objects must be manipulated directly. 
> I'm wondering if this is a problem or not (I suspect that it is for a 
> reasonably large class of user). In particular I'm worried that the 
> leap to the object view is sufficiently high enough that many less
> sophisticated users will find that an off-putting hurdle. How does 
> matlab handle these sorts of customizations? The same way matplotlib 
> does? If so then I suppose my worries are unfounded. Keeping a lot of 
> the customization exposed within a purely functional interface means
> adding more functions or keywords which is its own problem. To be more 
> specific, how minor ticking is handled is a good example of making the 
> keyword interface richer and avoiding object manipulations for common 
> customizations:
> 
> plot(x, y, xminordiv=4)
> 
> vs
> 
> plot(x, y)
> ax = gca()
> ax.xaxis.set_major_locator(MultipleLocator(20))
> ax.xaxis.set_minor_locator(MultipleLocator(5))
> # update 
> The same could be said for specifying different kinds of tickers

many times matlab require to use an "object" approach with set/get for
advanced customization or for performance reason when doing dynamic
stuff...In general having to do the same in matplotlib is thus not a big
problem, provided that we have the "get" return all the settable
parameters, or that the python help work well for the same purpose. 
I think there has been new development that allow the get to work like
in matlab now, so this is great for me!

Avoiding object manipulation is a good idea for common stuff imho, like
for the proposed ticking control. In fact avoiding the object approach
for simple stuff is a strength of matlab I feel, because it allows for a
quick and dirty approach to plotting that is often enough, and then you
always have the possibility to dig into an object approach at any time
should you have the need for advanced customization/usages...
All of this for saying that the current approach suits me well, and that
I am +0/-0 on adding  non-object based alternative to replace something
that is feasable using object now. the +0/-0 is dependent on the
frequency, I am -0 doing this for something that is seldom used, but I
fear that "seldom" is dependent on applications/users, so it will not
always be easy to have everybody agree on what to add...

> 6) If one does these object manipulations the display is not updated. 
> One of John's list postings suggests resizing or calling the draw 
> method. The first is often unacceptable, and the second isn't quite so 
> obvious (since it requires specifying a renderer). Perhaps a simple 
> function to do the update that doesn't start a mainloop (as show does) 
> is needed. John responded:
> >
> > This is a problem.  I think the solution may be to override setattr in
> > the artist base class to call draw_if_interactive.  The matlab
> > interface could add this method at module load time so as to not break
> > the interface separation between the OO layer and the matlab layer.
> > I'll have to look into it.
> 
> (could it be as simple as defining update() to get the current renderer 
> and then call gcf().draw(currentrenderer)?)

I though that calling draw() would update the active figure without
starting the mainloop already, or am I confused? Alternatively, in the
fltk backend, I have allowed calling show() multiple times, it just
check before running the mainloop that it is not already running...Maybe
this is also feasible in a more general way?


Best regards,

Greg.

>>>>> "Jos=E9" =3D=3D Jos=E9 Alexandre Nalon <na...@te...> writes:

    Jos=E9> That, and setting the x_lim inverted, worked as I wanted,
    Jos=E9> thanks.

Great

    Jos=E9> But one more thing: while I was searching for a specific
    Jos=E9> command to do that, I found something (but not much) about
    Jos=E9> transforms, which I couldn't exactly understand what they do
    Jos=E9> and how they work, but they might be handy in the near
    Jos=E9> future. What are they exactly, and how can they help?

The official documentation is at
http://matplotlib.sf.net/matplotlib.transforms.html , but this may be
of limited help because it is not a tutorial.

matplotlib is divided conceptually into three parts: the "matlab
interface" which are the plot functions that most people use and see,
the object oriented "artists" which are classes that store the figure
information and the "backends" which actually put the ink on the paper.

The "artists" are things like lines, text, rectangles, images and so
on, and all of them are concrete classes derived from
matplotlib.artist.Artist.  Stupid name, I know, but I'm weak when it
comes to naming.  There are, at a minimum, two coordinate systems to
consider when you plot, the "world" coordinates, ie your data
coordinates, and the display coordinates, which are physical locations
on the display device.  The mapping between these two is given by a
transformation.

matplotlib transformations generally store the information about the
data coordinates and display coordinates, and possibly also a
nonlinear function (eg, polar, log).  Every artist stores it's own
transform, and you can place different artists in the figure using
different coordinate systems (transforms).

The vast majority of all plot commands use the default data->display
transform and this is invisible in normal usage.  But for convenience
and internal usage, matplotlib provides a couple of extra
transformations that you can make use of.  For example, suppose you
wanted to place a rectangle in the middle of the axes that was 25%
from the left, bottom, top and right.  You would place this rectangle
in the axes in what I refer to as axes coordinates, where 0 is the
left side of the axes, 1 is the width, 0.5 is the middle and so on.
This hypothetical rectangle has left, bottom=3D0.25, 0.25 and width,
height=3D0.5, 0.5

    from matplotlib.matlab import *
    from matplotlib.patches import Rectangle

    ax =3D subplot(111)
    plot([1,2,3])
    trans =3D ax.transAxes
    r =3D Rectangle( (0.25, 0.25), 0.5, 0.5, transform=3Dtrans)
    ax.add_patch(r)
    show()
   =20
Likewise, the figure instance provides a default transformation to
allow you to place objects in figure coordinates, where 0,0 is the
bottom left of the figure, 0.5, 0.5 is the middle and 1,1 is the upper
right. =20

Internally, I use this all the time.  For example, I may want to place
the x-ticklabels a few points under the bottom of the y location of
the x-axis, and I have a transformation that allows me to do this with
minimal coding overhead in the presence o figure resizing, dpi
changes, etc.

These are examples of the transformations that are provided by
default, and they tend to cover most of the things people want to do.
But if you want to do something more, you can use affine
transformation (matplotlib.transforms.Affine) or otherwise and set
this for a given artist to place the object into the figure as you
like it.

The example examples/alignment_test.py in the matplotlib src
distribution makes heavy use of placing text in axes coordinates, so
you may want to take a look at this for an example.

JDH

>>>>> "Jon" == Jon Peirce <Jon...@no...> writes:

    Jon> Actually, since it's the package that most users probably
    Jon> actually want, would it be more suitable to move
    Jon> matplotlib.matlab into matplotlib itself? Then we could
    Jon> simply

    Jon> import matplotlib

    Jon> Obviously that would mix the main user routines (plot()...)
    Jon> with the more administrative namespace (get_backend(),
    Jon> is_interactive()...) and maybe you'd want to move those into
    Jon> a separate (always imported) subpackage along the lines of
    Jon> matplotlib.res?

It is technically possible to reorganize the code to support this, but
it would break a lot of code in a nontrivial way.  While it is trivial
to search and replace instances of 'from matplotlib.matlab' with 'from
matplotlib.pylab' and so on, it would not be trivial to port scripts
that were using the matplotlib admin funcs after the kind of
reorganization this would entail.

But your post did give me an idea that might satisfy everyone and
provide the ease of use your idea suggests.  If we migrate
matplotlib.matlab to matplotlib.pylab as discussed, *and* add an
additional file pylab.py that resides in site-packages and is a one
liner

  from matplotlib.pylab import * 

then we preserve the easy conversion from old namespace to new
namespace while making it easy for script writers to do

  from pylab import *

Plea to distutils gurus: if you can figure out a way in the current
matplotlib setup.py setup to get a module named pylab.py into
site-packages, please advise!  The current module layout is somewhat
complicated and already stretches my distutils capabilities.

Of course if you were using Fernando's wonderful pylab feature in
ipython, it would be a trifle concern anyhow, since the import is done
automagically.

JDH

>>>>> "seberino" == seberino  <seb...@sp...> writes:

    seberino> I noticed when I pass the mouse pointer over a point on
    seberino> a graph that the (X, Y) values are displayed.  This is
    seberino> *great*.

Glad you like it.  Fernando Perez pushed me into getting this
implemented by repeatedly glowing about how nice this was in
gnuplot ...  No better way to get me to implement a feature than
favorably compare gnuplot to matplotlib :-)

    seberino> What if I wanted to customize/extend what gets printed
    seberino> in response to mouse pointer position?  Is this
    seberino> possible?

Yes, you can use the fmt_xdata and fmt_ydata attributes of the axes
instance to set a custom function.  If these are not set, matplotlib
will fall back on the default tick formatter -- these are explained at
http://matplotlib.sf.net/matplotlib.ticker.html .  See
examples/date_demo1.py for an example of setting your own coordinate
formatter functions with fmt_xdata and fmt_ydata.  The basic usage is

  def price(x): return '$%1.2f'%x
  ax.fmt_xdata = DateFormatter('%Y-%m-%d')
  ax.fmt_ydata = price

Here fmt_xdata is set to a callable instance (a DateFormatter
instance) and fmt_ydata is a plain old function that takes y as a
value and returns a string.

    seberino> e.g. If you had say 5 graphs on one plot, could you
    seberino> display all "Y values" for every X value??

    seberino> (X, Y1, Y2, Y3, Y4, Y5)??

This is a harder problem.  You need to capture the mouse location (see
examples/coords_demo.py) to get the x location and use this
information in your y formatter function .  Basically, you want to
ignore the actual value passed to your y format function and use the y
values of your time series at a given x index which you capture with a
mouse move event.

In the example below I use a class to store the x location and
communicate between the mouse position and the y format function.  The
variable self.ind is the index into the x, y1 and y2 vectors that is
closest to the mouse x position.  The example assumes your xdata are
monotonic, though you could do it for non-monotonic x with minor
modifications.

Note in principle the example below should work on all matplotlib
backends and os platforms.  In practice, with a little testing, I
found that this example reveals some bugs in matplotlib event handling
which we are looking into.  So for now, it appears to only work
properly on the GTK* backends (sigh), though it doesn't use any gtk
specific code.

from matplotlib.matlab import *

class MyFormatter:

    def __init__(self, x, y1, y2):
        self.x = x
        self.y1 = y1
        self.y2 = y2
        self.ind = None

    def on_move(self, event):
        'save the last x coord and get the index'
        if event.inaxes:
            # get the index into x closest to 
            self.ind = searchsorted(self.x, event.xdata)
        else:
            self.ind = None

    def fmty(self, y):
        'ignore y and format the value of y1 and y2 at ind'
        if self.ind is None: return  ''
        thisy1 = self.y1[self.ind]
        thisy2 = self.y2[self.ind]
        return '%1.2f, %1.2f'%(thisy1, thisy2)
    
        
t = arange(0, 2.0, 0.01)
s1 = sin(2*pi*t)
s2 = 2*sin(3*pi*t)

plot(t, s1, t, s2)

canvas = get_current_fig_manager().canvas
ax = gca()

o = MyFormatter(t, s1, s2)
canvas.mpl_connect('motion_notify_event', o.on_move)
ax.fmt_ydata = o.fmty

show()

>>>>> "Carol" == Carol Leger <car...@sr...> writes:

    Carol> I am trying to overlay a polar grid on a previously plotted
    Carol> axis.  The plot looks fine on the screen and in a png file.
    Carol> However, I get an error message when making a postscript
    Carol> file.

Yep, this is a bug.  In backend_ps in the the set_linedashes function
on line 103, replace the line

    if seq: 

with 

    if seq is not None and len(seq):

My guess is you are using numarray, and if memory serves numarray but
not Numeric fails on using an array as a boolean, which is what
backend ps is doing here.

Overlaying a polar plot over a rectangular axes.  Man, what will they
think of next!?  You will send me the screenshot when you're done,
right?

JDH

I am trying to overlay a polar grid on a previously plotted axis.

The plot looks fine on the screen and in a png file.  However, I get an 
error message when making a postscript file.


Basically, I drew one set of axes in rectangular coordinates and then 
tried to overlay a polar grid with:
	# Save current axes
	ax = gca()
	l, b, w, h = ax.get_position()	# Normalized
	axp = axes([l, b, w, h], polar=True, frameon=False)
	theta = arange(0,1,0.001) * 2*2*pi
	r = array([1.0 for i in range(len(theta))])
	polar(theta, r, color='k')
	angles = arange(0,360,45)
	labels = ('','NE','','NW','','SW', '','SE' '')
	thetalines, thetatext = thetagrids(angles, labels)
	# Restore previous axes
	axes(ax)

I am using a version of the CVS code that I downloaded today, Nov. 30, 
2004.  I have source code I could send, but I doubt you want an 
attachment sent to the list.

Here are the messages that appear:
   File "testoverlay.py", line 90, in ?
     savefig('overlay.ps')
   File "/usr/lib/python2.3/site-packages/matplotlib/matlab.py", line 
1008, in savefig
     manager.canvas.print_figure(*args, **kwargs)
   File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 66, in print_figure
     agg.print_figure(filename, dpi, facecolor, edgecolor, orientation)
   File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_agg.py", 
line 385, in print_figure
     ps.print_figure(filename, dpi, facecolor, edgecolor, orientation)
   File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py", 
line 570, in print_figure
     self.figure.draw(renderer)
   File "/usr/lib/python2.3/site-packages/matplotlib/figure.py", line 
254, in draw
     for a in self.axes: a.draw(renderer)
   File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 
3125, in draw
     l.draw(renderer)
   File "/usr/lib/python2.3/site-packages/matplotlib/lines.py", line 
257, in draw
     lineFunc(renderer, gc, xt, yt)
   File "/usr/lib/python2.3/site-packages/matplotlib/lines.py", line 
513, in _draw_dotted
     renderer.draw_lines(gc, xt, yt)
   File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py", 
line 275, in draw_lines
     self._draw_lines(gc,points[0:1000])
   File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py", 
line 264, in _draw_lines
     self._draw_ps("\n".join(ps), gc, None)
   File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py", 
line 375, in _draw_ps
     self.set_linedash(*gc.get_dashes())
   File 
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py", 
line 103, in set_linedash
     if seq:
   File "/usr/lib/python2.3/site-packages/numarray/generic.py", line 
477, in __nonzero__
     raise RuntimeError("An array doesn't make sense as a truth value. 
Use sometrue(a) or alltrue(a).")
RuntimeError: An array doesn't make sense as a truth value.  Use 
sometrue(a) or alltrue(a).


-- 
Ms. Carol A. Leger
SRI International			Phone: (650) 859-4114
333 Ravenswood Avenue G-273
Menlo Park, CA 94025                    e-mail: le...@sr...

I noticed when I pass the mouse pointer over
a point on a graph that the (X, Y) values are
displayed.  This is *great*.

What if I wanted to customize/extend what gets
printed in response to mouse pointer position?
Is this possible?

e.g. If you had say 5 graphs on one plot, could you
display all "Y values" for every X value??

(X, Y1, Y2, Y3, Y4, Y5)??

Chris
--
_______________________________________

Christian Seberino, Ph.D.
SPAWAR Systems Center San Diego
Code 2872
49258 Mills Street, Room 158
San Diego, CA 92152-5385
U.S.A.

Phone: (619) 553-9973
Fax  : (619) 553-6521
Email: seb...@sp...
_______________________________________

Yesterday I brought up some user interface issues with John. He agreed 
that these generally ought to be discussed in a broader forum (meaning 
he wasn't dead set against them; at least not most of them). So here 
were some of the thoughts that I raised that pertain mainly to 
generating plots during interactive analysis sessions:

1) Seems to me that repr for the plot objects could be blanked out for 
interactive mode. Having python print out what it does now isn't 
usually useful and in some cases (like error bars) leads to a dump on 
the screen. Any reason not to make repr mode dependent (or at least 
configurable)?

John pointed out that one of the worst offenders (error bars) actually 
return lists of plot objects so it wouldn't do much good to override 
repr for the plot objects unless one used a list object where repr was 
overridden as well. The annoyance factor in interactive use is perhaps 
sufficient to do this though. What do others think?

2) Any support for being able to specify colors using more than single 
character codes (say, using "red" or "green", and line styles and 
symbols with more descriptive terms like "dashed". This is not in place 
of the existing scheme, but as a more verbose alternative. Along those 
lines, allowing something like:

plot(x1, y1, x2, y2, x3, y3, color=['red','green','blue'])

3) Tick control can be awkward if one simply wants to add an integral 
number of minor ticks to the chosen major tick interval. Currently 
using minor ticks forces one to access the plot objects, and specify 
the major tick interval as well. It would be nice if one could just ask 
for n minor ticks for each major tick interval by using the appropriate 
keyword (name tbd). Some illustrations of possible alternatives:

plot(x, y, xmajor=5)
plot(x, y, xmajor=5, xminor=1)
plot(x, y, xminordiv=5) # 5 minor ticks per major regardless  of major 
tick size

Generally, I expect that people set these interactively after plotting 
without these options. When they see what is automatically produced, 
this is a simple way of tweaking the plot without doing a lot of object 
manipulation.

4) The current means of doing overplotting is modal and confusing to 
many used to IDL's approach. It is easy to forget what the current mode 
is. IDL uses different commands (e.g., oplot vs plot) to overplot. Some 
alternatives John and I mentioned:

a) generate 'o' versions of all plot functions (oplot, oimplot, etc.). 
Easy to do but clutters the namespace.

b) have an 'over' function to apply to all such commands: over(plot, x, 
y, color='g')

c) use a keyword argument to only apply to the function call:
plot(x, y, hold=True) # doesn't change the hold state after completion, 
but does overplot

I'm happy to have c) myself.

5) For many customizations plot objects must be manipulated directly. 
I'm wondering if this is a problem or not (I suspect that it is for a 
reasonably large class of user). In particular I'm worried that the 
leap to the object view is sufficiently high enough that many less
sophisticated users will find that an off-putting hurdle. How does 
matlab handle these sorts of customizations? The same way matplotlib 
does? If so then I suppose my worries are unfounded. Keeping a lot of 
the customization exposed within a purely functional interface means
adding more functions or keywords which is its own problem. To be more 
specific, how minor ticking is handled is a good example of making the 
keyword interface richer and avoiding object manipulations for common 
customizations:

plot(x, y, xminordiv=4)

vs

plot(x, y)
ax = gca()
ax.xaxis.set_major_locator(MultipleLocator(20))
ax.xaxis.set_minor_locator(MultipleLocator(5))
# update

The same could be said for specifying different kinds of tickers

6) If one does these object manipulations the display is not updated. 
One of John's list postings suggests resizing or calling the draw 
method. The first is often unacceptable, and the second isn't quite so 
obvious (since it requires specifying a renderer). Perhaps a simple 
function to do the update that doesn't start a mainloop (as show does) 
is needed. John responded:
>
> This is a problem.  I think the solution may be to override setattr in
> the artist base class to call draw_if_interactive.  The matlab
> interface could add this method at module load time so as to not break
> the interface separation between the OO layer and the matlab layer.
> I'll have to look into it.

(could it be as simple as defining update() to get the current renderer 
and then call gcf().draw(currentrenderer)?)

It's possible that there are two or more different kinds of functional 
interfaces and philosophy such that there should be different modules 
to satisfy the different camps. But both John and I thought that if at 
all possible, these sorts of issues should be accommodated within one 
module. That the matlab (soon to be pylab) shouldn't necessarily be a 
strict matlab clone in interface but also take some of the better ideas 
from other packages. Any comments on the above suggestions?

Perry Greenfield

Thanks very much. Setting clim(0.0, 1.0) inside the loop stabilized the
color mapping.

Wendell Cropper


At 02:58 PM 11/30/2004 -0600, John Hunter wrote:
>>>>>> "Wendell" == Wendell Cropper <wcr...@uf...> writes:
>
>    Wendell> I have been trying to use pcolor() to display a grid with
>    Wendell> discrete values (1-4) that are changing over time. I'm
>    Wendell> generating a series of saved figures that also include a
>    Wendell> line graph of the sums of the 4 categories. The problem
>    Wendell> is that that mapping of numbers to colors isn't constant
>    Wendell> for the pcolor output. I changed the array from Float32
>    Wendell> (used out of habit) to integer and got the same type of
>    Wendell> result. It would also be nice to be able to use the same
>    Wendell> color mapping for both sub plots.
>
>    Wendell> I think (guess) that cmap=cm.jet controls the color
>    Wendell> scheme, but it isn't clear to me how to change that, what
>    Wendell> format it has, or why it seems to change with repeated
>    Wendell> calls to pcolor() inside the program.
>
>It sounds to me like the color limits are being autoscaled with each
>call to pcolor.  cm.jet does define the color map, but the color
>limits define the range of your data that correspond to the min and
>max of the colormap.
>
>See help(clim)
>
>If after each call to pcolor, you manually set the clim, you should
>have no problems.
>
>JDH
>
>
>
>    Wendell> -------------------------------------------------------
>    Wendell> SF email is sponsored by - The IT Product Guide Read
>    Wendell> honest & candid reviews on hundreds of IT Products from
>    Wendell> real users.  Discover which products truly live up to the
>    Wendell> hype. Start reading now.
>    Wendell> http://productguide.itmanagersjournal.com/
>    Wendell> _______________________________________________
>    Wendell> Matplotlib-users mailing list
>    Wendell> Mat...@li...
>    Wendell> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
>


University of Florida
School of Forest Resources and Conservation
214 Newins-Ziegler
PO Box 110410
Gainesville, FL 32611-0410

352-846-0859  phone
352-392-1707  fax

wcr...@uf...

>>>>> "Wendell" == Wendell Cropper <wcr...@uf...> writes:

    Wendell> I have been trying to use pcolor() to display a grid with
    Wendell> discrete values (1-4) that are changing over time. I'm
    Wendell> generating a series of saved figures that also include a
    Wendell> line graph of the sums of the 4 categories. The problem
    Wendell> is that that mapping of numbers to colors isn't constant
    Wendell> for the pcolor output. I changed the array from Float32
    Wendell> (used out of habit) to integer and got the same type of
    Wendell> result. It would also be nice to be able to use the same
    Wendell> color mapping for both sub plots.

    Wendell> I think (guess) that cmap=cm.jet controls the color
    Wendell> scheme, but it isn't clear to me how to change that, what
    Wendell> format it has, or why it seems to change with repeated
    Wendell> calls to pcolor() inside the program.

It sounds to me like the color limits are being autoscaled with each
call to pcolor.  cm.jet does define the color map, but the color
limits define the range of your data that correspond to the min and
max of the colormap.

See help(clim)

If after each call to pcolor, you manually set the clim, you should
have no problems.

JDH



    Wendell> -------------------------------------------------------
    Wendell> SF email is sponsored by - The IT Product Guide Read
    Wendell> honest & candid reviews on hundreds of IT Products from
    Wendell> real users.  Discover which products truly live up to the
    Wendell> hype. Start reading now.
    Wendell> http://productguide.itmanagersjournal.com/
    Wendell> _______________________________________________
    Wendell> Matplotlib-users mailing list
    Wendell> Mat...@li...
    Wendell> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

>>>>> "Nicolas" == Nicolas Gruel <hu...@ya...> writes:

    Nicolas> Hello, I have some question on the legend.

    Nicolas> the first is perhaps a bug:

    Nicolas> I was trying something like:

    Nicolas> plot([1,2,3],[2,3,4],label='toto') legend()

    Nicolas> I can't obtain a legend, instead I have an error
    Nicolas> message. So perhaps I didn't understand at all the
    Nicolas> message I obtain with: help(legend) (it's possible with
    Nicolas> my poor english :) ) or there are a problem.

Yep, it's a bug.  Replace the indicate line from axes.py

   loc = kwargs.gry('loc', 1)
                
with 

   loc = kwargs.get('loc', 1)
                ^^^

Note to self: run pychecker more often.

    Nicolas> second things: I would like to have the box create by the
    Nicolas> legend commande behind my plot and not above because it
    Nicolas> hide some of the point. Perhaps another solution is to
    Nicolas> put the box bacground in "alpha mode" but I don't know
    Nicolas> how to do this.

http://sourceforge.net/mailarchive/forum.php?thread_id=6039503&forum_id=33405

JDH

Jon Peirce wrote:
> Actually, since it's the package that most users probably actually want, 

most, maybe, but not all.

> would it be more suitable to move matplotlib.matlab into matplotlib 
> itself? Then we could simply
> 
> import matplotlib

please don't' do that. I haven't done much with it yet, but I'm much 
more interested in using the pythonesque api than the matlabesque one. 
I'm not using Matlab for a reason.

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

Hello, 

I have some question on the legend.

the first is perhaps a bug:

I was trying something like:

plot([1,2,3],[2,3,4],label='toto')
legend()

I can't obtain a legend, instead I have an error
message. So perhaps I didn't understand at all the
message I obtain with: help(legend) (it's possible
with my poor english :) ) or there are a problem.

second things:
I would like to have the box create by the legend
commande behind my plot and not above because it hide
some of the point. Perhaps another solution is to put
the box bacground in "alpha mode" but I don't know how
to do this. 

I will appreciate a lot your help, thanks.


Nicolas


	

	
		
Vous manquez d’espace pour stocker vos mails ? 
Yahoo! Mail vous offre GRATUITEMENT 100 Mo !
Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/

Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis. A télécharger gratuitement sur http://fr.messenger.yahoo.com

I have been trying to use pcolor() to display a grid with discrete values
(1-4) that are changing over time. I'm generating a series of saved figures
that also include  a line graph of the sums of the 4 categories. The
problem is that that mapping of numbers to colors isn't constant for the
pcolor output. I changed the array from Float32 (used out of habit) to
integer and got the same type of result. It would also be nice to be able
to use the same color mapping for both sub plots. 

I think (guess) that cmap=cm.jet controls the color scheme, but it isn't
clear to me how to change that, what format it has, or why it seems to
change with repeated calls to pcolor() inside the program.

Thanks,

Wendell Cropper


University of Florida
School of Forest Resources and Conservation
214 Newins-Ziegler
PO Box 110410
Gainesville, FL 32611-0410

352-846-0859  phone
352-392-1707  fax

wcr...@uf...

> Actually, since it's the package that most users probably actually want,
> would it be more suitable to move matplotlib.matlab into matplotlib
> itself? Then we could simply
>
> import matplotlib
>
> Obviously that would mix the main user routines (plot()...) with the
> more administrative namespace (get_backend(), is_interactive()...) and
> maybe you'd want to move those into a separate (always imported)
> subpackage along the lines of matplotlib.res?
>
> Just an idea.
> Jon
>

That would introduce some problems if the user wanted to change rc settings, 
which currently has to be done before importing matplotlib.matlab.

-- 

Darren

Actually, since it's the package that most users probably actually want, 
would it be more suitable to move matplotlib.matlab into matplotlib 
itself? Then we could simply

import matplotlib

Obviously that would mix the main user routines (plot()...) with the 
more administrative namespace (get_backend(), is_interactive()...) and 
maybe you'd want to move those into a separate (always imported) 
subpackage along the lines of matplotlib.res?

Just an idea.
Jon

>To: mat...@li...
>From: John Hunter <jdh...@ac...>
>Date: Mon, 29 Nov 2004 17:23:04 -0600
>Subject: [Matplotlib-users] matlab (TM)
>
>
>I'm concerned that at some point down the road, The Mathworks may not
>like the fact that matplotlib uses the name matlab, which is
>trademarked.  I think I'll rename the matlab interface to pylab.  In
>some sense, this name is more appropriate any way, because I'd like to
>incorporate the best features of IDL, gnuplot and python, while still
>retaining and enhancing core matlab compatibility.  I emailed Travis,
>who previously used pylab.sf.net before it became part of scipy, and
>he didn't have a problem with our using this name.  And Fernando
>already uses pylab as the option to ipython to make ipython support
>matplotlib.
>
>So my plan is to change the name of the matplotlib.matlab module to
>matplotlib.pylab, but wanted propose this here first since this will
>effect almost every script.  It should be an easy search and replace
>operation, and I'll probably post a little python script to
>recursively replace all matplotlib.matlab references in a given
>directory with matplotlib.pylab, since I have a few directories myself
>that will need to be renamed.
>
>Comments or objections welcome.
>
>JDH
>


-- 
Jon Peirce
http://www.psychology.nottingham.ac.uk/staff/jwp/


This message has been scanned but we cannot guarantee that it and any
attachments are free from viruses or other damaging content: you are
advised to perform your own checks.  Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

On Mon, 2004-11-29 at 17:23 -0600, John Hunter wrote:

> Comments or objections welcome.

The rename sounds fine to me, John.  I've been using "ipython -pylab"
since SciPy '04 anyway :-)

-- 
Stephen Walton <ste...@cs...>
Physics & Astronomy CSUN

I'm concerned that at some point down the road, The Mathworks may not
like the fact that matplotlib uses the name matlab, which is
trademarked.  I think I'll rename the matlab interface to pylab.  In
some sense, this name is more appropriate any way, because I'd like to
incorporate the best features of IDL, gnuplot and python, while still
retaining and enhancing core matlab compatibility.  I emailed Travis,
who previously used pylab.sf.net before it became part of scipy, and
he didn't have a problem with our using this name.  And Fernando
already uses pylab as the option to ipython to make ipython support
matplotlib.

So my plan is to change the name of the matplotlib.matlab module to
matplotlib.pylab, but wanted propose this here first since this will
effect almost every script.  It should be an easy search and replace
operation, and I'll probably post a little python script to
recursively replace all matplotlib.matlab references in a given
directory with matplotlib.pylab, since I have a few directories myself
that will need to be renamed.

Comments or objections welcome.

JDH

>>>>> "Carol" == Carol Leger <car...@sr...> writes:

    Carol> I want to make a semi-transparent box around the text
    Carol> labels along the radial axis of a polar plot.  Is there a
    Carol> method that returns the coordinates of a box that encloses
    Carol> the text?

    Carol> I see that a text instance has a method called
    Carol> get_window_extent.  What does it return?  What would I use
    Carol> for the parameter 'renderer'?  Are there any examples
    Carol> showing how to use this?


The problem here is that there is no way to know the text size
(bounding box) until the renderer (backend) is known.  matplotlib
enforces a rigid separation between the "artists" (lines, texts,
things that go into a figure) and the things that draw them (renderer
/ backend) .  In most cases this presents no difficulties, but in the
case of text it does, since layout information is not available until
the figure is drawn, since that is when the backend/renderer is drawn.
So that is what the renderer is and the short answer is that it is not
available at the matlab interface level.

But I've been wanting to support the ability to put bounding boxes
around text instances and your post triggered the idea on how to do
this.  I added a new text property "bbox" which takes as a dictionary
of Rectangle properties 


    t = title('hi mom', bbox={'edgecolor':'k', 'facecolor':'r', 'alpha':0.5})


In addition to the rectangle properties, the bbox dict accepts an
additional property 'pad' which gives the padding around the text in
points.

I checked the changes into CVS - it usually takes the mirrors a few
hours to update.

If you get a snazzy screenshot of your polar plot after all these
customizations that would look nice on the web site, please send it my
way!

JDH

I want to make a semi-transparent box around the text labels along the 
radial axis of a polar plot.  Is there a method that returns the 
coordinates of a box that encloses the text?

I see that a text instance has a method called get_window_extent.  What 
does it return?  What would I use for the parameter 'renderer'?  Are 
there any examples showing how to use this?




-- 
Ms. Carol A. Leger
SRI International			Phone: (650) 859-4114
333 Ravenswood Avenue G-273
Menlo Park, CA 94025                    e-mail: le...@sr...

Hello!

> Perhaps you can be a little more specific about what you want to do.

I think that a 'picture' can help - in this case, I think fixed
fonts will really help understanding. I remember using some
command in Matlab to do this, but can't remember exactly what
it was, and I can't search the help because I uninstalled it.
What I need is, basically, this:


                            *| x
                   *         |
             *               |
         *                   |
       *                     |
      *                      |
      *                      |
y --------------------------+


>   plot(y, x)

That, and setting the x_lim inverted, worked as I wanted, thanks.

But one more thing: while I was searching for a specific command
to do that, I found something (but not much) about transforms, which
I couldn't exactly understand what they do and how they work, but
they might be handy in the near future. What are they exactly, and
how can they help?

---
José Alexandre Nalon
na...@te...

On Mon, 29 Nov 2004, Jos=E9 Alexandre Nalon apparently wrote:
> In a figure I'm generating, I need to plot a function rotated
> 90 degrees counter-clockwise, so that x-axis is vertical, and
> y-axis is horizontal (increasing from right to left). I searched
> the documentation and the examples and couldn't find how (what I
> tried didn't work). Probably there is a simple way to do that, if
> somebody can point that out, I would really appreciate. :)

Can you fill in your needs more precisely.
Why can you not just switch the order of
the sequences you provide to 'plot'
(perhaps in a loop is there are several)?

Cheers,
Alan Isaac