matplotlib-users Mailing List for matplotlib

One more thing on axis('equal')
There is an axis_equal_demo on CVS that demontrates the basic functionality
Mark

The revised axis('equal') command is now available on CVS.
Several emails have been posted regarding the proper
functioning. Let me explain what it is designed to do and
why, then we can see if we want to modify (and whether it
works as advertised).
The doc string for axis('equal') is
axis('equal') changes limits of x or y axis such that equal
tick mark increments are equal in size. This makes a circle
look like a circle, for example. This is persistent. For
example, when axis limits are changed after this command,
the scale remains equal
The axis('equal') command works as in matlab. When you give
the command, it will change the data limits of one of the
axes such that the scale is equal on both axes. If you
change the data limits after that with the command axis(),
then it will keep the scales equal, and will resize the
figure. As a result, the order of commands matters (the
same holds in matlab):
plot([1,2,3],[1,2,3])
axis('equal')
axis((1,3,1,3))
will produce a square graph with limits from 1 to 3 on
both axes, while
plot([1,2,3],[1,2,3])
axis((1,3,1,3))
axis('equal')
will create a rectangular plot with axes limits
(0.71620934959349603, 3.283790650406504, 1.0, 3.0)
So far for 'compatibility' with matlab. If you want to set
the axes equal, but not change the data limits, all in one
statement, you can do that as follows
plot([1,2,3],[1,2,3])
gca().set_aspect('equal',fixLimits=3DTrue)
Regarding the 'fixLimits' option, you are telling the
routine to fix the limits, so I think the choice of the
variable name is ok. It may be a good idea to add
'fixLimits' as an optional keyword to the pylab interface,
(I would use it a lot for that matter).
Now regarding the history, when using the toolbar in
interactive mode. I think we should modify the history such
that it saves both the data limits and the position. I can
do that (I think); let me know if that is what you want to
do.
The equal scale should be maintained when zooming-in with
the new toolbar.
Things that still need to be fixed: When you resize the
figure in interactive mode by dragging a corner or
expanding to full screen size, the scale of the axes are
not maintained, even if they are set to be equal. I am not
sure where to make this change (where does MPL know that
the figure got resized????). But it would be cool if that
worked as well.
Also, when axis are equal and the axis is shared, and you
change the axis limits such that the size of the subplot
changes, the shared axis size is not changed with it, as I
think it should. I need to fix that too.
I have not tested the current CVS, but hope to find time to
do that soon. Let me know what you think.
Mark

I am attempting to use subplot with pie charts to get multiple pie
charts on one figure.
I modified the pie_demo.py as show below. Unfortunatly
it seems that the second pie-chart is written on top of the first.
How do I get multiple pie-charts on one figure? Is subplot the wrong
way to do this?
 from pylab import *
 
 # make a square figure and axes
 figure(1, figsize=(8,4))
 ax = axes([0.1, 0.1, 0.8, 0.8])
 labels = 'Frogs', 'Hogs', 'Dogs', 'Logs'
 fracs = [15,30,45, 10]
 figure(1)
 subplot(1,2,1)
 pie(fracs, labels=labels)
 labels = 'Frogs', 'Hogs', 'Cat', 'Cans'
 fracs = [15,30,45, 77]
 figure(1)
 subplot(1,2,2)
 pie(fracs, labels=labels)
 ...
 show()

>>>>> "John" == John Gill <jn...@eu...> writes:
 John> I was also interested in some sort of legend for scatter
 John> plots recently. To that end I took a bit of a look at the
 John> legend code this am with a view to adding support for
 John> RegularPolyCollection's being passed in as handles for
 John> legends.
 John> My idea was just to assume the first element in the
 John> collection is representative of the others and use that to
 John> create a suitable RegularPolyPatch to use as the handle.
 John> I've not got it quite right as yet -- my current code
 John> produces a big blue blob in the middle of the plot.
 John> Is it worth me fixing this up and sending in a patch?
I think so, the case of a solid colored scatter with varying sizes
seems sufficiently common to warrant legend support.
So a patch would be great, if you aren't too busy with the Katrina
aftermath these days ...
Thanks,
JDH

I was also interested in some sort of legend for scatter plots recently.
To that end I took a bit of a look at the legend code this am with a 
view to adding support for RegularPolyCollection's being passed in as 
handles for legends.
My idea was just to assume the first element in the collection is 
representative of the others and use that to create a suitable 
RegularPolyPatch to use as the handle.
I've not got it quite right as yet -- my current code produces a big 
blue blob in the middle of the plot.
Is it worth me fixing this up and sending in a patch?
John
John Hunter wrote:
>>>>>>"Jack" == Jack Andrews <ef...@iv...> writes:
>>>>>> 
>>>>>>
>
> Jack> is there any more information you'd like to help me with
> Jack> constructing a legend for this scatter?
>
> Jack> i think i am misusing the scatter graph here... letting
> Jack> scatter assign colours from a continous selection rather
> Jack> than specifying a color.
>
>Yes, you probably want to assign specific colors in multiple calls to
>scatter. Scatter returns a
>matplotlib.collections.RegularPolyCollection, which legend is not
>equiped to deal with. To hack around this, you can create a proxy
>patch to pass to legend, which has the colors you want to use for the
>legend
>
>from matplotlib.patches import Rectangle
>from pylab import *
>
>N=20
>
>props = dict( alpha=0.75, faceted=False )
>
>x, y= rand(2,N)
>s=array(([400]+[30]*(N/2-1))*2)
>reds = scatter(x, y, c='red', s=s, **props)
>
>x, y= rand(2,N)
>s=array(([400]+[30]*(N/2-1))*2)
>
>blues = scatter(x, y, c='blue', s=s, **props)
>
>redp = Rectangle( (0,0), 1,1, facecolor='red')
>bluep = Rectangle( (0,0), 1,1, facecolor='blue')
>
>legend( (redp, bluep), ('reds', 'blues') )
>grid(True)
>
>show()
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>_______________________________________________
>Matplotlib-users mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
>

>>>>> "Jo=E3o" =3D=3D Jo=E3o Lu=EDs Silva <rom...@ya...> writes:
 Jo=E3o> Christian Kristukat wrote:
 >> Hi, is it possible to have an image map (imshow) with real axes
 >> like those created by 'contour' when supplying a xy meshgrid?
 >> The pcolor command unfortunately doesn't do interpolation.
 >> Regards, Christian
You can use set the coordinates of the image data using the extent
kwarg. Among other things, this lets you plot image data with other
data (eg line data). See examples/image_demo2.py. =20
 Jo=E3o> This would be useful for me too, as I need to display an
 Jo=E3o> imshow with nonuniform axes.
This is not possible. image data, by definition, is regularly
sampled. At least it is in matplotlib. However, supporting
interpolation and gouraud shading over patches (eg rectangles) is
becoming an increasing priority (in particular to support John
Porter's recent 3D surface plot work) so hopefully we'll have this
feature for pcolor soon.
JDH

Christian Meesters wrote:
>> Christian Meesters wrote:
>>
>>> Hi
>>> It's certainly no important problem and there are ways to work around 
>>> it, but I was wondering whether there is a way to do it directly 
>>> using matplotlib.
>>> My 'problem' is as follows: My detector does not detect at all times; 
>>> in case nothing is detected a 0 is written in the data-file. So what 
>>> I end up with are data like [0,0,1000,1001,999,0,1000 ...], which - 
>>> of course - looks a bit odd, when plotted. (The 0s are meaningless.) 
>>> Is it possible to plot only values unequal to zero? Or is there any 
>>> other way to 'mask' data which should be skipped for the plot?
>>
>>
>> I believe that all plot methods accept masked arrays:
>>
>> import MA
>>
>> y = sin(arange(10))
>> dat = MA.array(y,mask=(y<0))
>> plot(dat,'o-')
>>
> Thanks. Sounds good. But what is 'mask'. It is not part of MA or scipy, 
> or is it? Do you know in which submodule it is hidden?
> 
mask is a keyword argument to MA.array. It must be an array of the same shape as 
y, containing ones and zeros.
type help(MA.array) to get more information.
Regards, Christian

>>>>> "Martin" == Martin Richter <law...@gm...> writes:
 >>> 1) Unfortunetly this history seems not to work properly in
 >>> some cases. I was able to track down this error on the call of
 >>> the subplot-command
 Martin> [...]. is that neither the positioning nor the limits are
 Martin> restored. To be precise: They are not restored
 Martin> incorrectly; nothing happens if the buttons are
 Martin> pressed. (To be correct: The zoomhistory works only back
 Martin> to the last click which had an connected event. This state
 Martin> seems to be set as new 'home' - see the example which I
 Martin> sent the last time.)
Yep, this is a bug; I was able to replicate it. Could you file it on
the sourceforge site. I don't know what the immediate fix is, and
getting on sourceforge will help prevent it from falling through the
cracks.
 http://sourceforge.net/tracker/?group_id=80706&atid=560720
Thanks,
JDH

>>>>> "Martin" == Martin Richter <law...@gm...> writes:
 Martin> Hello John, it was pretty easy to rewrite the (formally
 Martin> called) LineSelector so that the callback-function now
 Martin> awaits two events (press and release). Now it is possible
 Martin> to use the different mousebuttons. (By the way: It is
 Martin> checked if press- and releasebutton are the same.)
 Martin> If you want to include the RubberbandWidget - please feel
 Martin> free to do so.
Thanks Martin,
The changes are in CVS
 Checking in lib/matplotlib/widgets.py;
 /cvsroot/matplotlib/matplotlib/lib/matplotlib/widgets.py,v <--
 widgets.py new revision: 1.23; previous revision: 1.22
I made a few stylistic changes to use mpl naming conventions and added
your example to examples/widgets/rectangle_selector.py . I also
decided on the name "RectangleSelector" since rubberband won't mean
much to many people.
 Martin> I took the latest CVS, tried it again with GTKAgg, WXAgg
 Martin> and TkAgg and (as you said) it worked fine!
That's the great thing about using Agg as a common renderer and doing
event handling with the MDE. Folks using other GUI toolkits get to
reuse your work (and contribute to it).
Thanks for the widget!
JDH

On Tue, 6 Sep 2005, John Hunter wrote:
[...]
> Hey Arnd,
>
> All of your suggestions look reasonable to me on cursory inspection,
> but the person best equipped to decide these things is Mark Bakker,
> who wrote the axes equal handling. I've CC'd him on this message.
OK, I think the best is that Mark has a look at the CVS version
and our comments and then we will move on ...
[...]
> I have a couple of minor comments:
>
> Arnd> While at this: I also don't like `autoscale_on` very much.
> Arnd> I think that `autoscale` (being True or False) would be enough.
>
> I recall Fernando objecting to this too, so it must be particularly
> irritating. My inclination for cosmetic things like this is to not
> break backwards compatibility for a slightly more pleasing name.
I can understand this, but on the other hand, we are at *0*.84,
so users should expect things to break when running < 1.0 software.
Also the breakage does not seem too bad to me.
Not changing it now means that it will also be in matplotlib 8.0
(and even in the upcoming MDE (Matplotlib Desktop Environment) ;-).
> Arnd> And one more (just to complicate matters even more): At the
> Arnd> moment there is only autoscaling for x and y at the same
> Arnd> time. Gnuplot, for example, allows to specify the xrange or
> Arnd> yrange separately and the other range is autoscaled. I am
> Arnd> mentionining this, because it might be a useful feature.
> Arnd> (However, it might make the coding of the autoscaling even
> Arnd> more involved...).
>
> I think this would be useful too. We could implement autoscalex and
> autoscaley properties which would handle this. I don't think the code
> would be particularly cumbersome. Then the question is: what should
> be done with autoscale_on: deprecate it, or have it set autoscalex and
> autoscaley together?
I think `autoscale` should imply `autoscalex` and `autoscaley`
(Note that I did not write `autoscale_on`,`autoscale_on_x`,
`autoscale_on_y` ;-).
Best,
Arnd

>>>>> "Arnd" == Arnd Baecker <arn...@we...> writes:
 Arnd> On Fri, 2 Sep 2005, John Hunter wrote:
 Arnd> To be honest, from a user perspective such effects are very
 Arnd> problematic and I would usually considered as a bug.
 Arnd> Together with Martin Richter I had a closer look at this:
Hey Arnd, 
All of your suggestions look reasonable to me on cursory inspection,
but the person best equipped to decide these things is Mark Bakker,
who wrote the axes equal handling. I've CC'd him on this message. 
 Mark> Regarding the questions of axis('equal') and axis('scaled'),
 Mark> I submitted a patch for the axis('equal') command about a
 Mark> month ago that will turn it into the same behavior as
 Mark> matlab. After the axis('equal') command is given, the scale
 Mark> on both axes will be equal (such that a circle looks like a
 Mark> circle). It has a little demo file with it as
 Mark> well. Hopefully that will be implemented in CVS soon (let me
 Mark> know if I can help here, John),
Mark, I committed your patch and these guys are using CVS, so the
issues Arnd and Martin describe apply to the patched matplotlib.
If the three of you could hash this out and come up with an updated
patch you are all happy with, I'm happy to apply it. As always,
please provide some language with your patch for API_CHANGES, if there
are any.
I have a couple of minor comments:
 Arnd> While at this: I also don't like `autoscale_on` very much.
 Arnd> I think that `autoscale` (being True or False) would be enough.
I recall Fernando objecting to this too, so it must be particularly
irritating. My inclination for cosmetic things like this is to not
break backwards compatibility for a slightly more pleasing name.
 Arnd> And one more (just to complicate matters even more): At the
 Arnd> moment there is only autoscaling for x and y at the same
 Arnd> time. Gnuplot, for example, allows to specify the xrange or
 Arnd> yrange separately and the other range is autoscaled. I am
 Arnd> mentionining this, because it might be a useful feature.
 Arnd> (However, it might make the coding of the autoscaling even
 Arnd> more involved...).
I think this would be useful too. We could implement autoscalex and
autoscaley properties which would handle this. I don't think the code
would be particularly cumbersome. Then the question is: what should
be done with autoscale_on: deprecate it, or have it set autoscalex and
autoscaley together?
Thanks,
JDH

>>>>> "Jack" == Jack Andrews <ef...@iv...> writes:
 Jack> is there any more information you'd like to help me with
 Jack> constructing a legend for this scatter?
 Jack> i think i am misusing the scatter graph here... letting
 Jack> scatter assign colours from a continous selection rather
 Jack> than specifying a color.
Yes, you probably want to assign specific colors in multiple calls to
scatter. Scatter returns a
matplotlib.collections.RegularPolyCollection, which legend is not
equiped to deal with. To hack around this, you can create a proxy
patch to pass to legend, which has the colors you want to use for the
legend
from matplotlib.patches import Rectangle
from pylab import *
N=20
props = dict( alpha=0.75, faceted=False )
x, y= rand(2,N)
s=array(([400]+[30]*(N/2-1))*2)
reds = scatter(x, y, c='red', s=s, **props)
x, y= rand(2,N)
s=array(([400]+[30]*(N/2-1))*2)
blues = scatter(x, y, c='blue', s=s, **props)
redp = Rectangle( (0,0), 1,1, facecolor='red')
bluep = Rectangle( (0,0), 1,1, facecolor='blue')
legend( (redp, bluep), ('reds', 'blues') )
grid(True)
show()

Regarding the questions of axis('equal') and axis('scaled'), I submitted a=
=20
patch for the axis('equal') command about a month ago that will turn it int=
o=20
the same behavior as matlab. After the axis('equal') command is given, the=
=20
scale on both axes will be equal (such that a circle looks like a circle).=
=20
It has a little demo file with it as well. Hopefully that will be=20
implemented in CVS soon (let me know if I can help here, John),=20
Mark
matlab also has a handy axis('tight') command that sets tight limits on the=
=20
axes such that it contains all data tighly; that would be easy to implement=
=20
as well.

On Tue, 6 Sep 2005, Christian Meesters wrote:
> Hi
>
> It's certainly no important problem and there are ways to work around
> it, but I was wondering whether there is a way to do it directly using
> matplotlib.
> My 'problem' is as follows: My detector does not detect at all times;
> in case nothing is detected a 0 is written in the data-file. So what I
> end up with are data like [0,0,1000,1001,999,0,1000 ...], which - of
> course - looks a bit odd, when plotted. (The 0s are meaningless.) Is it
> possible to plot only values unequal to zero?
What about using compress before plotting:
In [1]: from Numeric import *
In [2]: x=arange(10)
In [3]: x
Out[3]: array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])
In [4]: xred=compress(x>0,x)
In [5]: xred
Out[5]: array([1, 2, 3, 4, 5, 6, 7, 8, 9])
> Or is there any other way
> to 'mask' data which should be skipped for the plot?
There are also masked arrays in matplotlib, maybe
some else has a simple example.
Best,
Arnd

On Tuesday 06 September 2005 9:42 am, Rob Hetland wrote:
> When I try to pcolor a large array, say a few hundred elements in
> each dimension with text.usetex:True set in the rc file, pcolor gives
> an error. [Mac OS X 10.4, python 2.4.1, matplotlib 0.83.2, TkAgg
> backend]
>
> Plotting smaller arrays, or not using TeX gives no error.
Please post an example and the error message.
Darren

Hi
It's certainly no important problem and there are ways to work around 
it, but I was wondering whether there is a way to do it directly using 
matplotlib.
My 'problem' is as follows: My detector does not detect at all times; 
in case nothing is detected a 0 is written in the data-file. So what I 
end up with are data like [0,0,1000,1001,999,0,1000 ...], which - of 
course - looks a bit odd, when plotted. (The 0s are meaningless.) Is it 
possible to plot only values unequal to zero? Or is there any other way 
to 'mask' data which should be skipped for the plot?
Thanks a lot in advance,
Christian

When I try to pcolor a large array, say a few hundred elements in 
each dimension with text.usetex:True set in the rc file, pcolor gives 
an error. [Mac OS X 10.4, python 2.4.1, matplotlib 0.83.2, TkAgg 
backend]
Plotting smaller arrays, or not using TeX gives no error.
-Rob.
-----
Rob Hetland, Assistant Professor
Dept of Oceanography, Texas A&M University
p: 979-458-0096, f: 979-845-6331
e: he...@ta..., w: http://pong.tamu.edu

Hello everyone,
when using errorbar() it is possible to change the attributes (linethickness
etc.) with setp(). This works really well.
But on the otherhand when you try to set the attributes within the
errorbar()-command it will not work - see the exapmle below.
Finding this a bit disturbing I took a look at "axes.py" where errorbar() is
placed. I found out that the drawing of those bars and caps (also
just beeing lines) are added to the plot without the "**kwargs".
Credulously and optimistic I just added it there and - of course - got an
errormessage. So I made a copy of kwargs in the method errorbar() and poped
out all the keywords which could be problematic (I only found out 'marker',
'ls' and 'linestyle') by
kwargs_bars = kwargs.copy() # make copy of kwargs (not only a
 # pointer)
if kwargs.has_key('marker'): # Is the 'marker' keyword given in
 # kwargs?
 marker=kwargs_bars.pop('marker')# filter this entry out (would raise
 # error "duplicate keyword argument")
if kwargs.has_key('ls'): # Is the 'ls' keyword given in kwargs?
 marker=kwargs_bars.pop('ls') # filter this entry out (vlines, hlines
 # would not be drawn)
if kwargs.has_key('linestyle'): # Is the 'linestyle' keyword given
 marker=kwargs_bars.pop('linestyle') # in kwargs?
and then added **kwargs_bars to the following vlines, hlines and plots:
barlines.extend( self.hlines(y, x, left,**kwargs_bars) )
barlines.extend( self.hlines(y, x, right,**kwargs_bars) )
caplines.extend( self.plot(left, y, '|', ms=2*capsize,**kwargs_bars) )
caplines.extend( self.plot(right, y, '|', ms=2*capsize,**kwargs_bars) )
and also for yerr.
Now the example below worked fine.
I'm now thinking of two things - the second one of them beeing a
possible drawback.
 i) I'm not sure if other keywords should also be poped out. I can't imagine
any further problems - but we all know that this means completely
nothing in the wide field of possible errormessages ;-)
ii) Like before you have the ability to set the color of the cap- and
barlines seperatly from the color of the line connecting the points.
The problem mentioned above (you can't change the thickness of the caps and
bars from the errorbar()-command) still persists for 'linestyle'. Therefor
I'm not sure if the confusion existing before is cleared away. Propably not.
Just imagine a user: "I would like to change the style of the bars and caps
to '-.'. Why do I have to use setp() instead of giving it to errorbar()?"
But I hope that the changes in axes.py are helpful.
Bye,
Martin
PS: Would it be more agreeable if I try to create a patch ruther
then sending the codesnippets? If yes: could anyone give me a hint on how
to find information about patches (how t omake them, how to apply
them)?
Thanks!
#-------------------------------------------------------------------------------
"""This little program shows that it makes an enormous difference
 where the properties of the errorbar()-command are set.
 a) within the command errorbar(...)
 b) seperately with an setp() command
"""
from pylab import *
N=20
x = 1.0*arange(N)/(N-1)
yerrors = .02*rand(N) # errors in y
xerrors = .02*rand(N) # errors in x
y = exp(-x) # plain curve
figure(1)
subplot(121)
print ("Left : If the features are set with setp() everything works out
fine.")
error_plot_1 = errorbar(x,y, yerr=yerrors,xerr=xerrors,
 ls='none',ecolor='r')
setp(error_plot_1,linewidth=3,markeredgewidth=2)
subplot(122)
print ("Right : But if one uses the command errorbars() itself not.")
error_plot = errorbar(x,y, yerr=yerrors,xerr=xerrors,
 ls='none',ecolor='r',
 linewidth=3,markeredgewidth=2)
show()
-- 
GMX DSL = Maximale Leistung zum minimalen Preis!
2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl

Christian Kristukat wrote:
> Hi,
> is it possible to have an image map (imshow) with real axes like those 
> created
> by 'contour' when supplying a xy meshgrid? The pcolor command unfortunately
> doesn't do interpolation.
> Regards, Christian
> 
> 
This would be useful for me too, as I need to display an imshow with 
nonuniform axes.
João Silva

Hi,
is it possible to have an image map (imshow) with real axes like those created
by 'contour' when supplying a xy meshgrid? The pcolor command unfortunately
doesn't do interpolation.
Regards, Christian

Hello everyone, 
Hello Mark,
what I meant with
>> 1) Unfortunetly this history seems not to work properly in some cases. I
>> was able to track down this error on the call of the subplot-command
[...].
is that neither the positioning nor the limits are restored. To be precise:
They are not restored incorrectly; nothing happens if the buttons are
pressed. (To be correct: The zoomhistory works only back to the last click
which had an connected event. This state seems to be set as new 'home' - see
the example which I sent the last time.)
Thanks for your Mail,
Martin
-- 
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse für Mail, Message, More +++