matplotlib-users Mailing List for matplotlib (Page 7)

On Jan 4, 2008 4:33 PM, Mephisto <dr_...@ho...> wrote:
>
> For some simple but effective Python code you can use to create a mask
> similar to that provided by the Matlab roipoly function, see
> http://www.ariel.com.au/a/python-point-int-poly.html
> http://www.ariel.com.au/a/python-point-int-poly.html . The code seems to be
> quite effective.

matplotlib implements these algorithms in C -- see
matplotlib.nxutils.pnpoly for a testing inclusion of a single point,
and matplotlib.nxutils.points_inside_poly for testing multiple points.
 There is some example code using the latter function at
http://matplotlib.sf.net/examples/lasso_demo.py.  Not sure why this
example is not working for Venkat.

JDH

On Jan 2, 2008 10:25 PM, Aitor Gonzalez <ait...@gm...> wrote:
> Hi,
>
> I have some two sets of data with their x- and y-coordinates, (x1, y1) and
> (x2, y2). I want to plot these curves as a parametric plot:
> #########
> from numpy import *
> from pylab import *
>
> t = arange ( 0.0 , pi/2 , 0.05)
> x1= cos(t)
> y1 = -sin(t)
> x2 = -1+2/pi*t
> y2 = -2/pi*t

I think you want something like

plot(x1, y1, 'g-', x2, y2, 'r-')

Setting ps.useafm = True while ps.fonttype = 42 allows illustrator to 
open the eps files again and gives me back text editing capability, but 
I don't have any control over the typeface anymore, it just defaults to 
Helvetica.

Jordan

On Jan 15, 2008 7:46 AM, Michael Droettboom <md...@st...> wrote:
> Ah -- just thought of something else.
>
> If I adjust simple_plot_fps.py to have 100,000 data points rather than
> 1,000 I see something that starts to match with what you're seeing:
>
> GtkAgg:
> wallclock: 4.23297405243
> user: 3.33
> fps: 23.6240522057
>
> Gtk:
> wallclock: 15.0203828812
> user: 14.92
> fps: 6.65761990165
>
> TkAgg:
> wallclock: 4.8252530098
> user: 4.67
> fps: 20.7243018754
>
> You can see that the Gtk time is starting to explode.  If I go to
> 1,000,000 points, Gtk runs out of memory before the first plot, whereas
> the other two continue to chug along at a reasonable pace.
>
>  From looking at the code, I suspect the crucial difference is that the
> Gdk backend uses the Python sequence API (rather slow) to access the
> data as it gets rendered, whereas GtkAgg uses the numpy array interface
> which is essentially raw access to a C array.

This is not likely to be the culprit -- for drawing markers, the old
matplotlib API made a separate call to draw_polygon for every marker,
with a new gc each time.  Many moons ago, we implemented draw_markers
as a renderer method to avoid this problem.  For hundreds of thousands
of markers, we saw performance benefits of 25x to 100x.  The backends
which implement draw_markers (Agg and PS) get the benefits, but the
other backends which did not are still slow. Basically it is a problem
with a lot of redundant function call overhead.   The backend_bases
renderer method _draw_markers discusses this a little bit (it is
underscore hidden).

My guess is this difference will not be so pronounced on the trunk.

JDH

On Jan 16, 2008 1:03 PM, Kevin Christman <kch...@ya...> wrote:
>
> I'm new to matplotlib. Currently the x-axis shows numbers from 0 to 1.
>   I would like it to show it in percent notation (e.g. 0% to 100%).
>   How do I do this in matplotlib?

You can either multiply your x data by 100 (where x is a numpy array)

>>> plot(x*100, y)

or set a custom formatter

from matplotlib.ticker import FuncFormatter

def myfunc(x, pos=0):
    return '%1.2f''%(100*x)

ax = subplot(111)
ax.plot(x, y)
ax.xaxis.set_major_formatter(FuncFormatter(myfunc))

There is a section on custom tick formatting in the user's guide on the web site

JDH

JDH

Thanks Eric!  Here is corrected code that works:

import matplotlib
from datetime import *
import time
from pylab import *


def toOrd(strDate):
	return datetime(*time.strptime(strDate,"%m/%d/%y")[0:5]).toordinal()

def main():
	
	startDate = toOrd("05/24/05")
	endDate = toOrd("11/21/06")
	
	dates = range(startDate,endDate,7)
	figure(1)
	
	ax1 = subplot(211,axisbelow=True)
	plot_date(dates,dates,visible = False)
	ax1.bar(dates,dates, width=3.0)
	
	ax2 = subplot(212,axisbelow=True, sharex=ax1)
	plot_date(dates,dates) #,'-',color = priceColor)
	
	show()

	

if __name__ == '__main__':
	main()
	


On Jan 16, 2008, at 1:02 PM, Eric Firing wrote:

> John Harrison wrote:
>> bump.  please...?
>> Begin forwarded message:
>>>
>>> I have some code that produces a series of graphs of data over  
>>> time.  For the most part it works well, but for certain  
>>> combinations of dates the two plots do not line up, due to the  
>>> width of the bars in the first subplot.  What is the best way for  
>>> force my second subplot's x axis to be identical to that of the  
>>> first subplot?
>
> Check the sharex kwarg.  In the examples directory, see  
> ganged_plots.py, shared_axis_demo.py, and any others that include  
> the sharex kwarg.
>
> Eric
>
>
>>>
>>> Thanks!
>>>
>>> Here is minimal code reproducing the problem:
>>>
>>> import matplotlib
>>> from datetime import *
>>> import time
>>> from pylab import *
>>>
>>>
>>> def toOrd(strDate):
>>> return datetime(*time.strptime(strDate,"%m/%d/%y")[0:5]).toordinal()
>>>
>>> def main():
>>>
>>>
>>> startDate = toOrd("05/24/05")
>>> endDate = toOrd("11/21/06")
>>>
>>>
>>> dates = range(startDate,endDate,7)
>>> figure(1)
>>>
>>>
>>> axis = subplot(211,axisbelow=True)
>>> plot_date(dates,dates,visible = False)
>>> axis.bar(dates,dates, width=3.0)
>>>
>>>
>>> axis = subplot(212,axisbelow=True)
>>> plot_date(dates,dates) #,'-',color = priceColor)
>>>
>>>
>>> show()
>>>
>>>
>>>
>>> if __name__ == '__main__':
>>> main()
>>>
>> --------------------------------------------------------------------- 
>> ---
>> --------------------------------------------------------------------- 
>> ----
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> --------------------------------------------------------------------- 
>> ---
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

John Harrison wrote:
> bump.  please...?
> 
> Begin forwarded message:
>>
>> I have some code that produces a series of graphs of data over time.  
>> For the most part it works well, but for certain combinations of dates 
>> the two plots do not line up, due to the width of the bars in the 
>> first subplot.  What is the best way for force my second subplot's x 
>> axis to be identical to that of the first subplot?

Check the sharex kwarg.  In the examples directory, see ganged_plots.py, 
shared_axis_demo.py, and any others that include the sharex kwarg.

Eric


>>
>> Thanks!
>>
>> Here is minimal code reproducing the problem:
>>
>> import matplotlib
>> from datetime import *
>> import time
>> from pylab import *
>>
>>
>> def toOrd(strDate):
>> return datetime(*time.strptime(strDate,"%m/%d/%y")[0:5]).toordinal()
>>
>> def main():
>>
>>
>> startDate = toOrd("05/24/05")
>> endDate = toOrd("11/21/06")
>>
>>
>> dates = range(startDate,endDate,7)
>> figure(1)
>>
>>
>> axis = subplot(211,axisbelow=True)
>> plot_date(dates,dates,visible = False)
>> axis.bar(dates,dates, width=3.0)
>>
>>
>> axis = subplot(212,axisbelow=True)
>> plot_date(dates,dates) #,'-',color = priceColor)
>>
>>
>> show()
>>
>>
>>
>> if __name__ == '__main__':
>> main()
>>
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

I'm new to matplotlib. Currently the x-axis shows numbers from 0 to 1.
  I would like it to show it in percent notation (e.g. 0% to 100%).
  How do I do this in matplotlib?

Thanks, 

Kevin



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

bump.  please...?

Begin forwarded message:
>
> I have some code that produces a series of graphs of data over  
> time.  For the most part it works well, but for certain  
> combinations of dates the two plots do not line up, due to the  
> width of the bars in the first subplot.  What is the best way for  
> force my second subplot's x axis to be identical to that of the  
> first subplot?
>
> Thanks!
>
> Here is minimal code reproducing the problem:
>
> import matplotlib
> from datetime import *
> import time
> from pylab import *
>
>
> def toOrd(strDate):
> 	return datetime(*time.strptime(strDate,"%m/%d/%y")[0:5]).toordinal()
>
> def main():
> 	
> 	startDate = toOrd("05/24/05")
> 	endDate = toOrd("11/21/06")
> 	
> 	dates = range(startDate,endDate,7)
> 	figure(1)
> 	
> 	axis = subplot(211,axisbelow=True)
> 	plot_date(dates,dates,visible = False)
> 	axis.bar(dates,dates, width=3.0)
> 	
> 	axis = subplot(212,axisbelow=True)
> 	plot_date(dates,dates) #,'-',color = priceColor)
> 	
> 	show()
>
> 	
>
> if __name__ == '__main__':
> 	main()
>

   Hi,

I want to display the values of some variable (namely, alpha, beta, gamma,
delta) on a plot, and making a legend  like
"$ \alpha=%G, \  \bet=%G, \ \gamma=%G, \ \delta=%G $" % values is not very
readable.
Is there away to make multiline mathtext ?


thanks

BL

On Wednesday 16 January 2008 01:02:04 pm Thorsten Kranz wrote:
> Hi list!
>
> I have another question, which hopefully is not that hard. I want to
> control the distance of the ticklabels from the axiy. How can I do this?
> Maybe by one of the rc-Parameters?

Yes, see the (x,y)tick.(major,minor).pad parameter.

Hi list!

I have another question, which hopefully is not that hard. I want to control
the distance of the ticklabels from the axiy. How can I do this? Maybe by
one of the rc-Parameters?

Thanks in advance,

Thorsten

Ok... I'm running python 2.5 on winxp.  I recently upgraded from 
matplotlib 88ish to 91.1, and now the font embedding in eps files no 
longer works for me: all fonts end up as paths when I open an eps file 
in illustrator, and I can't do any font editing like I could before I 
upgraded.  I found a reference to changing ps.fonttype to 42 on one of 
the matplotlib faq pages to embed the entire truetype font in the eps 
file, but when I do that illustrator can't open the eps file, failing 
with "The operation cannot complete because of an unknown error."  How 
do I make the fonts editable in illustrator again?

Jordan

Michael Droettboom wrote:
> It's sort of a pygtk issue -- it 
> would have to be rewritten to take numpy arrays 

not quite -- it would have to be re-written to use the array interface, 
which is different, as that can be done without requiring numpy, or its 
headers.

 > which is probably
> unlikely to happen in the official codebase.

That was true before the array interface, when supporting arrays 
essentially meant a dependency on numpy. That's not longer true, so it's 
quite likely that the pygtk folks would accept a patch -- someone still 
would need to write that patch, though!

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

On Wednesday 16 January 2008 08:22:45 am Michael Droettboom wrote:
> I'm having an enormous sense of deja vu...
>
> There was a very similar bug filed here,
> http://sourceforge.net/tracker/index.php?func=detail&aid=1757315&group_id=8
>0706&atid=560720

I think it is identical, I overlooked the original bug report...

> which I thought I had resolved in revision 4197 (which would have made
> it into all of the 0.91.x releases).

and it appears to be fixed on my machine (caveat below). Lorenzo, what 
matplotlib version are you using?

> My fix there was just to forcibly set the plot back to linear in cla()
> -- the idea being that if a new plot is created and hold is False, it is
> forcibly set back to linear (i.e. pristine state) by calling
> set_xscale('linear') and set_yscale('linear), which resets both the
> transform and the locators/formatters etc.  This fix works whether you
> use loglog() to create the plot, or plot() followed by set_?scale().
>
> But reading Darren's new bug report makes me wonder if my fix was
> correct.  To be honest, I'm a little confused by the bug report, not out
> of any lack of clarity on Darren's part, but I think due to insufficient
> understanding of the problem.  As assumption about the purpose of cla is
>   that is should return the plot to a pristine state -- and in this case
> that means linear axes.  But are you suggesting that sometimes that is
> not the case?

If you have hold=True, and the x or y scale is log, repeated calls to plot() 
will add new lines to the plot without changing the scaling. If hold is 
instead False, one might reasonably expect that future calls to plot would 
replace the old line with the new one, again without changing the scaling. 
That would be consistent. Instead, the scaling changes.

> Just so we're on the page, does this bug still occur post r4197 and with
> 0.91.x, or is this a 0.90.1 issue?

I don't see the bug in svn. Lorenzo?

> Darren Dale wrote:
> > Hi Lorenzo,
> >
> > On Tuesday 15 January 2008 4:14:24 pm Lorenzo Isella wrote:
> >> Dear All,
> >> I am sending this email out of frustration, but I hope that someone will
> >> be able to tell me what is going on.
> >> I am using pylab on a Debian testing box.
> >> I have the feeling that there is some problem with pylab when I
> >> alternate, as I am doing now, many linear and log-log plots. Very often,
> >> pylab complains about the fact that I cannot take the log of a negative
> >> number even if all the quantities are positive or even if I have
> >> replaced the loglog with a linear plot...
> >> An example (sorry but there are long arrays involved and I cannot
> >> reproduce all my code here):
> >>
> >>
> >> #! /usr/bin/env python
> >>
> >> import scipy as s
> >> import numpy as n
> >> import pylab as p
> >> #from rpy import r
> >> #import distance_calc as d_calc
> >>
> >> # now I try performing a least-square fitting
> >> import scipy.optimize as sopt
> >>
> >>
> >> #do my stuff here
> >>
> >> print "my_n_clus_fit is, ", my_n_clus_fit
> >> print "my_r_sq_fit",my_r_sq_fit
> >> print "n_clu_rep2 is, ", n_clu_rep2
> >> print "R_sq is", R_sq
> >>
> >> p.plot(n_clu_rep2,R_sq,"bo",my_n_clus_fit,my_r_sq_fit, "ro")
> >> p.xlabel('particles in cluster')
> >> p.ylabel('R square')
> >> #p.legend(('beta=1e-2,100 part','beta=1e-1, 100 part', 'beta=1e-1, 200
> >> part'))
> >> p.title('Cluster-size vs average radius of gyration')
> >> p.grid(True)
> >> p.savefig("R_gyr_vs_N_fit.pdf")
> >> p.hold(False)
> >>
> >> and the relevant part of the output is:
> >
> > [...]
> >
> >> Traceback (most recent call last):
> >>   File "./r_gyr.py", line 322, in ?
> >>     p.plot(n_clu_rep2,R_sq,"bo",my_n_clus_fit,my_r_sq_fit, "ro")
> >>   File "/usr/lib/python2.4/site-packages/matplotlib/pylab.py", line
> >> 2028, in plot
> >>     ret =  gca().plot(*args, **kwargs)
> >>   File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 2540,
> >> in plot
> >>     self.autoscale_view(scalex=scalex, scaley=scaley)
> >>   File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 1207,
> >> in autoscale_view
> >>     self.set_xlim(XL)
> >>   File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 1493,
> >> in set_xlim
> >>     raise ValueError('Cannot set nonpositive limits with log transform')
> >> ValueError: Cannot set nonpositive limits with log transform
> >
> > I think this is a bug. It sounds like the same issue I reported a while
> > back:
> > http://www.nabble.com/Cannot-set-nonpositive-limits-with-log-transform-to
> >12154187.html
> >
> > I havent had a chance to look into a solution. I filed a bug report at
> > sourceforge (1872462). I'm worried the fix will be disruptive, but
> > several people have run into this. I'm sorry you got bit as well.
> >
> > Darren
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users



-- 
Darren S. Dale, Ph.D.
Staff Scientist
Cornell High Energy Synchrotron Source
Cornell University
275 Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853

dar...@co...
office: (607) 255-3819
fax: (607) 255-9001
http://www.chess.cornell.edu

Hi MAtthias,

yes, I can confirm this behavior. This is what I get as well. But the
solution is easy: just get rid of th line

cb.ax.yaxis.set_major_formatter(formatter)

We don't need it anymore and it messes it all up. Without it, it should
work.

Greetings,
Thorsten

2008/1/11, Matthias Michler <Mat...@gm...>:
>
> Hi Thorsten,
>
> On Wednesday 09 January 2008 15:35, Thorsten Kranz wrote:
> > Hi list, Hi Matthias,
> >
> > I found another way to deal with this problem. when defining the
> colorbar,
> > one can give an additional kwarg "format", so by defining the kwarg
> > "format=formatter", we solved the problem.
>
> I'm happy that your problem disappeared, but I still have a question. On
> my
> system the problem still exist, if I use "format=formatter" in colorbar
> and
> after that use
> cb.ax.yaxis.set_major_formatter(formatter)
> in the example-code of my last email.
> Can anybody confirm this behaviour (data range 0.0 ... 0.54 -> 0.0 ...
> 0.95)?
> And if so: Is this the expected behaviour?
>
> best regards,
> Matthias
>
>
> > Anyway, I think an option as Matthias implemented would be very handy
> for
> > all those users like us here in Germany who might want to have the
> numbers
> > formatted with commata.
> >
> > Greetings,
> > Thorsten
> >
> > 2008/1/9, Matthias Michler <Mat...@gm...>:
> > > Hello list,
> > > Hello Thorsten,
> > >
> > > On Wednesday 09 January 2008 11:38, Thorsten Kranz wrote:
> > > > I have a question concerning reformatting of axis-ticks via the
> > > > FuncFormatter-class. In german, it's common to use a comma as
> separator
> > >
> > > for
> > >
> > > > decimal numbers instead of a dot. To realize it in matplotlib, I do
> > > > something like
> > > >
> > > > >from matplotlib.ticker import FuncFormatter
> > > >
> > > > import pylab
> > > > pylab.figure()
> > > > formatter = FuncFormatter(lambda x,pos: ("%.2f"%x).replace(".",","))
> > > > ax = pylab.axes()
> > > > ax.xaxis.set_major_formatter(formatter)
> > > > ax.yaxis.set_major_formatter(formatter)
> > > > ax.plot(pylab.arange(0,1,0.1),pylab.arange(0,1,0.1))
> > > > This works fine for me,
> > >
> > > I had the same idea ;-). The problem is that you have a fixed number
> of
> > > digits
> > > behind the comma, which is not the desirable behaviour during zoom.
> > > I changed the ticker.py/ axes.py files to circumwait this
> disadvantage. I
> > > attached a patch showing my changes and maybe somebody can test it.
> > > You can activate it using:
> > >   ax.ticklabel_format(style='comma')
> > > for an ScalarFormatter
> > >
> > > > but I encounter a problem when I do an
> > > > imshow-command with a colorbar. In the imshow-axes, it's o.k., but
> for
> > >
> > > the
> > >
> > > > colorbar it doesn't really work. I do
> > > >
> > > > cb = pylab.colorbar()
> > > > cb.ax.yaxis.set_major_formatter(formatter)
> > > >
> > > > and, actually, all dots are replaced by com9mata, but the values are
> > >
> > > also
> > >
> > > > changed! E.g. instead of the old values (without formatter) from
> > > > 0-0.54, the
> > > >
> > > > values are increased to 0-0.95.
> > >
> > > [...]
> > >
> > > > Can anyone explain why it doesn't work out as I expect it to work?
> > >
> > > I don't know were the problem comes from. I attached your example in a
> > > slitly
> > > modified version and this shows that the problem is not due to your
> > > special
> > > formatting. It occurs with matplotlib.ticker.ScalarFormatter, too.
> > >
> > > best regards,
> > > Matthias
> > >
> > > > Or is there a better, more standard way to substitute the dots by
> > >
> > > commata?
> > >
> > > > Thanks,
> > > > Thorsten
> > >
> > >
> -------------------------------------------------------------------------
> > > Check out the new SourceForge.net Marketplace.
> > > It's the best place to buy or sell services for
> > > just about anything Open Source.
> > >
> > >
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketpl
> > >ace _______________________________________________
> > > Matplotlib-users mailing list
> > > Mat...@li...
> > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

I'm having an enormous sense of deja vu...

There was a very similar bug filed here, 
http://sourceforge.net/tracker/index.php?func=detail&aid=1757315&group_id=80706&atid=560720

which I thought I had resolved in revision 4197 (which would have made 
it into all of the 0.91.x releases).

My fix there was just to forcibly set the plot back to linear in cla() 
-- the idea being that if a new plot is created and hold is False, it is 
forcibly set back to linear (i.e. pristine state) by calling 
set_xscale('linear') and set_yscale('linear), which resets both the 
transform and the locators/formatters etc.  This fix works whether you 
use loglog() to create the plot, or plot() followed by set_?scale().

But reading Darren's new bug report makes me wonder if my fix was 
correct.  To be honest, I'm a little confused by the bug report, not out 
of any lack of clarity on Darren's part, but I think due to insufficient 
understanding of the problem.  As assumption about the purpose of cla is 
  that is should return the plot to a pristine state -- and in this case 
that means linear axes.  But are you suggesting that sometimes that is 
not the case?

Just so we're on the page, does this bug still occur post r4197 and with 
0.91.x, or is this a 0.90.1 issue?

Cheers,
Mike

Darren Dale wrote:
> Hi Lorenzo,
> 
> On Tuesday 15 January 2008 4:14:24 pm Lorenzo Isella wrote:
>> Dear All,
>> I am sending this email out of frustration, but I hope that someone will
>> be able to tell me what is going on.
>> I am using pylab on a Debian testing box.
>> I have the feeling that there is some problem with pylab when I
>> alternate, as I am doing now, many linear and log-log plots. Very often,
>> pylab complains about the fact that I cannot take the log of a negative
>> number even if all the quantities are positive or even if I have
>> replaced the loglog with a linear plot...
>> An example (sorry but there are long arrays involved and I cannot
>> reproduce all my code here):
>>
>>
>> #! /usr/bin/env python
>>
>> import scipy as s
>> import numpy as n
>> import pylab as p
>> #from rpy import r
>> #import distance_calc as d_calc
>>
>> # now I try performing a least-square fitting
>> import scipy.optimize as sopt
>>
>>
>> #do my stuff here
>>
>> print "my_n_clus_fit is, ", my_n_clus_fit
>> print "my_r_sq_fit",my_r_sq_fit
>> print "n_clu_rep2 is, ", n_clu_rep2
>> print "R_sq is", R_sq
>>
>> p.plot(n_clu_rep2,R_sq,"bo",my_n_clus_fit,my_r_sq_fit, "ro")
>> p.xlabel('particles in cluster')
>> p.ylabel('R square')
>> #p.legend(('beta=1e-2,100 part','beta=1e-1, 100 part', 'beta=1e-1, 200
>> part'))
>> p.title('Cluster-size vs average radius of gyration')
>> p.grid(True)
>> p.savefig("R_gyr_vs_N_fit.pdf")
>> p.hold(False)
>>
>> and the relevant part of the output is:
> 
> [...]
>> Traceback (most recent call last):
>>   File "./r_gyr.py", line 322, in ?
>>     p.plot(n_clu_rep2,R_sq,"bo",my_n_clus_fit,my_r_sq_fit, "ro")
>>   File "/usr/lib/python2.4/site-packages/matplotlib/pylab.py", line
>> 2028, in plot
>>     ret =  gca().plot(*args, **kwargs)
>>   File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 2540,
>> in plot
>>     self.autoscale_view(scalex=scalex, scaley=scaley)
>>   File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 1207,
>> in autoscale_view
>>     self.set_xlim(XL)
>>   File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 1493,
>> in set_xlim
>>     raise ValueError('Cannot set nonpositive limits with log transform')
>> ValueError: Cannot set nonpositive limits with log transform
> 
> 
> I think this is a bug. It sounds like the same issue I reported a while back: 
> http://www.nabble.com/Cannot-set-nonpositive-limits-with-log-transform-to12154187.html
> 
> I havent had a chance to look into a solution. I filed a bug report at 
> sourceforge (1872462). I'm worried the fix will be disruptive, but several 
> people have run into this. I'm sorry you got bit as well.
> 
> Darren
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Thanks.  I think that's actually unrelated to your patch -- but is new 
since 0.91.2.  Fixed in SVN r4872.

Thanks for your help,
Mike

Paul Novak wrote:
> The patch for legends works except for LineCollection. For any call to 
> legend(), I get the errors below,
> 
> Paul
> 
> Traceback (most recent call last):
>   File 
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py", 
> line 331, in expose_event
>     self._render_figure(self._pixmap, w, h)
>   File 
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py", 
> line 75, in _render_figure
>     FigureCanvasAgg.draw(self)
>   File 
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
> line 257, in draw
>     self.figure.draw(self.renderer)
>   File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 
> 698, in draw
>     for a in self.axes: a.draw(renderer)
>   File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 1397, 
> in draw
>     a.draw(renderer)
>   File "/usr/lib/python2.5/site-packages/matplotlib/legend.py", line 
> 206, in draw
>     h.draw(renderer)
>   File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 480, 
> in draw
>     lineFunc(renderer, gc, tpath, affine.frozen())
>   File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 740, 
> in _draw_dashed
>     renderer.draw_path(gc, path, trans)
> ValueError: Dash sequence must be an even length sequence; found 1
> Traceback (most recent call last):
>   File 
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py", 
> line 331, in expose_event
>     self._render_figure(self._pixmap, w, h)
>   File 
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py", 
> line 75, in _render_figure
>     FigureCanvasAgg.draw(self)
>   File 
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
> line 257, in draw
>     self.figure.draw(self.renderer)
>   File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 
> 698, in draw
>     for a in self.axes: a.draw(renderer)
>   File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 1397, 
> in draw
>     a.draw(renderer)
>   File "/usr/lib/python2.5/site-packages/matplotlib/legend.py", line 
> 206, in draw
>     h.draw(renderer)
>   File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 480, 
> in draw
>     lineFunc(renderer, gc, tpath, affine.frozen())
>   File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 740, 
> in _draw_dashed
>     renderer.draw_path(gc, path, trans)
> ValueError: Dash sequence must be an even length sequence; found 1
> Traceback (most recent call last):
>   File 
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py", 
> line 331, in expose_event
>     self._render_figure(self._pixmap, w, h)
>   File 
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py", 
> line 75, in _render_figure
>     FigureCanvasAgg.draw(self)
>   File 
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
> line 257, in draw
>     self.figure.draw(self.renderer)
>   File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 
> 698, in draw
>     for a in self.axes: a.draw(renderer)
>   File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 1397, 
> in draw
>     a.draw(renderer)
>   File "/usr/lib/python2.5/site-packages/matplotlib/legend.py", line 
> 206, in draw
>     h.draw(renderer)
>   File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 480, 
> in draw
>     lineFunc(renderer, gc, tpath, affine.frozen())
>   File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 740, 
> in _draw_dashed
>     renderer.draw_path(gc, path, trans)
> ValueError: Dash sequence must be an even length sequence; found 1
> 
> 
> 
> 
> Michael Droettboom wrote:
>> [I'm bringing this back to the list.  Hope you don't mind.]
>>
>> I've been doing a lot of non-matplotlib work lately and this fell off 
>> my radar.  Thanks for the reminder.
>>
>> The patch looks good to me.  I'm not concerned about doing all this in 
>> _get_handles as opposed to Legend.__init__.  I actually think it's 
>> better in _get_handles because then it's more connected to the 
>> creation of the handles themselves.  (And of course _get_handles is 
>> only ever called from __init__ anyway, so it really is just an 
>> organizational extension of __init__).  I moved all references to 
>> _xdata to _get_handles to be consistent.
>>
>> The one concern I had is that _xdata is being stored as a member 
>> variable, which implicitly assumes that it will be the same for all 
>> handles.  After your patch, it can be different for each handle -- for 
>> instance a line made of markers vs. dashing.  So I've just made it a 
>> local variable to _get_handles and recreate it separately for each 
>> handle.  There's no reason to try to share something so small, and it 
>> just feels safer (fewer potential side effects) that way.
>>
>> I've committed this in r4871.  Please check it out and kick the tires 
>> with all the test cases you came up with along the way and let me know 
>> how it goes.
>>
>> Cheers,
>> Mike
>>
>> Paul Novak wrote:
>>> Mike,
>>>
>>> Thank you for handling the PS backend issues. Below is an email I 
>>> sent earlier about an updated patch for fixing legends with 
>>> numpoints=1; I didn't get any response probably because of my delay 
>>> in responding. If I should restart this thread on the mailing list, I 
>>> can.
>>>
>>> Included below is an updated patch fixing the legend with 
>>> numpoints=1. The patch has been made against SVN and works for 
>>> Line2D, LineCollection, Patch, and RegularPolyCollection. The patch 
>>> could be merged.
>>>
>>> I also think the patch could be improved. Currently, handle._marker 
>>> is examined to determine if the legend should contain lines or 
>>> symbols, but this is done in the _get_handles function. It would be 
>>> better if that could be moved into the Legend class definition, 
>>> however, I do not know how to examine handle._marker in the Legend 
>>> class definition.
>>>
>>> Again, I would appreciate any comments or improvements.
>>>
>>> Thanks,
>>>
>>> Paul
>>>
>>> diff -u a/lib/matplotlib/legend.py b/lib/matplotlib/legend.py
>>> --- a/lib/matplotlib/legend.py    2008-01-09 13:11:00.000000000 -0600
>>> +++ b/lib/matplotlib/legend.py    2008-01-09 13:08:36.000000000 -0600
>>> @@ -175,9 +175,7 @@
>>>          # make a trial box in the middle of the axes.  relocate it
>>>          # based on it's bbox
>>>          left, top = 0.5, 0.5
>>> -        if self.numpoints == 1:
>>> -            self._xdata = npy.array([left + self.handlelen*0.5])
>>> -        else:
>>> +        if self.numpoints > 1:
>>>              self._xdata = npy.linspace(left, left + self.handlelen, 
>>> self.numpoints)
>>>          textleft = left+ self.handlelen+self.handletextsep
>>>          self.texts = self._get_texts(labels, textleft, top)
>>> @@ -236,6 +234,7 @@
>>>
>>>      def _get_handles(self, handles, texts):
>>>          HEIGHT = self._approx_text_height()
>>> +        left = 0.5
>>>
>>>          ret = []   # the returned legend lines
>>>
>>> @@ -243,6 +242,10 @@
>>>              x, y = label.get_position()
>>>              x -= self.handlelen + self.handletextsep
>>>              if isinstance(handle, Line2D):
>>> +                if self.numpoints == 1 and handle._marker == 'None':
>>> +                    self._xdata = npy.linspace(left, left + 
>>> self.handlelen, 2)
>>> +                elif self.numpoints == 1:
>>> +                    self._xdata = npy.array([left + 
>>> self.handlelen*0.5])
>>>                  ydata = (y-HEIGHT/2)*npy.ones(self._xdata.shape, float)
>>>                  legline = Line2D(self._xdata, ydata)
>>>                  legline.update_from(handle)
>>> @@ -253,7 +256,8 @@
>>>
>>>                  ret.append(legline)
>>>              elif isinstance(handle, Patch):
>>> -
>>> +                if self.numpoints == 1:
>>> +                    self._xdata = npy.linspace(left, left + 
>>> self.handlelen, 2)
>>>                  p = Rectangle(xy=(min(self._xdata), y-3/4*HEIGHT),
>>>                                width = self.handlelen, height=HEIGHT/2,
>>>                                )
>>> @@ -263,6 +267,8 @@
>>>                  p.set_clip_path(None)
>>>                  ret.append(p)
>>>              elif isinstance(handle, LineCollection):
>>> +                if self.numpoints == 1:
>>> +                    self._xdata = npy.linspace(left, left + 
>>> self.handlelen, 2)
>>>                  ydata = (y-HEIGHT/2)*npy.ones(self._xdata.shape, float)
>>>                  legline = Line2D(self._xdata, ydata)
>>>                  self._set_artist_props(legline)
>>> @@ -277,6 +283,8 @@
>>>                  ret.append(legline)
>>>
>>>              elif isinstance(handle, RegularPolyCollection):
>>> +                if self.numpoints == 1:
>>> +                    self._xdata = npy.array([left])
>>>                  p = Rectangle(xy=(min(self._xdata), y-3/4*HEIGHT),
>>>                                width = self.handlelen, height=HEIGHT/2,
>>>                                )
>>>
>>>
>>>
>>> Michael Droettboom wrote:
>>>> Thanks for pointing that out -- I didn't even notice.
>>>>
>>>> There was an ordering problem in how colors were being set.  This 
>>>> should be fixed in r4870.
>>>>
>>>> Cheers,
>>>> Mike
>>>>
>>>> Paul Novak wrote:
>>>>> I have another problem after updating to SVN r4869. The ticks take 
>>>>> the color of the plotted line without regard to the default. For 
>>>>> example,
>>>>>
>>>>> matplotlib.rc('xtick', color='black')
>>>>> matplotlib.rc('ytick', color='black')
>>>>> plot(x, y, 'red')
>>>>>
>>>>> will give red ticks.
>>>>>
>>>>> Paul
>>>>>
>>>>> Michael Droettboom wrote:
>>>>>> It's a bug.  It's now possible for rgba colors to make their way 
>>>>>> all the way down to that level, so the code needs to truncate that 
>>>>>> to rgb (Ps can't handle alpha anyway).
>>>>>>
>>>>>> This is committed in SVN r4869.
>>>>>>
>>>>>> Cheers,
>>>>>> Mike
>>>>>>
>>>>>> Paul Novak wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I am trying to use the PS backend to make some simple line plots, 
>>>>>>> using the following script, but I get the error messages included 
>>>>>>> below when I try to plot with usetex=True. I have also included 
>>>>>>> the output from --verbose=helpful. I am using the current SVN, 
>>>>>>> and I don't recall having this problem when using 0.91.1.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Paul
>>>>>>>
>>>>>>> ---
>>>>>>> #!/usr/bin/env python
>>>>>>>
>>>>>>> import matplotlib
>>>>>>> matplotlib.use('PS')
>>>>>>> matplotlib.rc('text', usetex = 'True')
>>>>>>> from pylab import *
>>>>>>>
>>>>>>> x = arange(0,5)
>>>>>>> y = 2 * x
>>>>>>> figure(1)
>>>>>>> plot(x, y)
>>>>>>> savefig('psfig')
>>>>>>> show()
>>>>>>>
>>>>>>> ---
>>>>>>> $HOME=/home/pnovak
>>>>>>> CONFIGDIR=/home/pnovak/.matplotlib
>>>>>>> matplotlib data path 
>>>>>>> /usr/lib/python2.5/site-packages/matplotlib/mpl-data
>>>>>>> loaded rc file /home/pnovak/.matplotlib/matplotlibrc
>>>>>>> matplotlib version 0.98pre
>>>>>>> verbose.level helpful
>>>>>>> interactive is False
>>>>>>> units is False
>>>>>>> platform is linux2
>>>>>>> numerix numpy 1.0.3.1
>>>>>>> Using fontManager instance from 
>>>>>>> /home/pnovak/.matplotlib/fontManager.cache
>>>>>>> backend PS version Level II
>>>>>>> Found dvipng version 1.5
>>>>>>>
>>>>>>> Traceback (most recent call last):
>>>>>>>    File "junk.py", line 15, in <module>
>>>>>>>      savefig('psfig')
>>>>>>>    File "/usr/lib/python2.5/site-packages/matplotlib/pyplot.py", 
>>>>>>> line 271, in savefig
>>>>>>>      return fig.savefig(*args, **kwargs)
>>>>>>>    File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", 
>>>>>>> line 854, in savefig
>>>>>>>      self.canvas.print_figure(*args, **kwargs)
>>>>>>>    File 
>>>>>>> "/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py", 
>>>>>>> line 1085, in print_figure
>>>>>>>      **kwargs)
>>>>>>>    File 
>>>>>>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_ps.py", 
>>>>>>> line 837, in print_ps
>>>>>>>      return self._print_ps(outfile, 'ps', *args, **kwargs)
>>>>>>>    File 
>>>>>>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_ps.py", 
>>>>>>> line 863, in _print_ps
>>>>>>>      orientation, isLandscape, papertype)
>>>>>>>    File 
>>>>>>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_ps.py", 
>>>>>>> line 1051, in _print_figure_tex
>>>>>>>      self.figure.draw(renderer)
>>>>>>>    File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", 
>>>>>>> line 698, in draw
>>>>>>>      for a in self.axes: a.draw(renderer)
>>>>>>>    File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", 
>>>>>>> line 1397, in draw
>>>>>>>      a.draw(renderer)
>>>>>>>    File "/usr/lib/python2.5/site-packages/matplotlib/axis.py", 
>>>>>>> line 680, in draw
>>>>>>>      tick.draw(renderer)
>>>>>>>    File "/usr/lib/python2.5/site-packages/matplotlib/axis.py", 
>>>>>>> line 179, in draw
>>>>>>>      self.label1.draw(renderer)
>>>>>>>    File "/usr/lib/python2.5/site-packages/matplotlib/text.py", 
>>>>>>> line 761, in draw
>>>>>>>      Text.draw(self, renderer)
>>>>>>>    File "/usr/lib/python2.5/site-packages/matplotlib/text.py", 
>>>>>>> line 309, in draw
>>>>>>>      self._fontproperties, angle)
>>>>>>>    File 
>>>>>>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_ps.py", 
>>>>>>> line 544, in draw_tex
>>>>>>>      color = '%1.3f,%1.3f,%1.3f'% gc.get_rgb()
>>>>>>> TypeError: not all arguments converted during string formatting
>>>>>>>
>>>>>>> ------------------------------------------------------------------------- 
>>>>>>>
>>>>>>> This SF.net email is sponsored by: Microsoft
>>>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>>>>> _______________________________________________
>>>>>>> Matplotlib-users mailing list
>>>>>>> Mat...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>>>
>>>>
>>

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Dear all,=0A=0AI wrote an application allowing to display an imshow image i=
n one part of a Tk GUI and the corresponding colorbar in another part. This=
 allows me to work on the image with more freedom. My problem is then to sa=
ve the result which implies getting the 2 axes into another figure. I've be=
en fighting for some time but I can't get it right. The problem in the end =
is that I don't really understand the exact link between: figure <-> canvas=
 <-> axes. I guessed that one creates a Figurecanvas which is the GUI link =
where to put the figure which itself contains the axes. But when I tried to=
 get the axes and put them into a new figure, they don't appear...=0A=0ACan=
 anyone give me a hint on what I did wrong ? I'm using matplotlib v.0.90.1=
=0A=0AThe code looks something like:=0A=0A------=0A########## init part ###=
########=0Aimport matplotlib as mpl=0Ampl.use('TkAgg')=0Afrom matplotlib.ba=
ckends.backend_tkagg import FigureCanvasTkAgg=0A=0A########## creating GUI =
elements ###########=0A#create figures=0Aself.mplfImageDisplay  =3D mpl.fig=
ure.Figure(figsize=3D(5,4),dpi=3D100,facecolor=3D'white')=0Aself.mplfImageC=
olorbar =3D mpl.figure.Figure(figsize=3D(0.7,4),dpi=3D100,facecolor=3D'whit=
e')=0A=0A #add tk.DrawingArea=0A self.cvImageDisplay =3D FigureCanvasTkAgg(=
self.mplfImageDisplay,master=3DleftPaneImage)=0A self.cvImageDisplay.get_tk=
_widget().pack()=0A self.cvImageColorbar =3D FigureCanvasTkAgg(self.mplfIma=
geColorbar,master=3DcenterPaneImage)=0A self.cvImageColorbar.get_tk_widget(=
).pack()=0A=0A #pack all in main frame=0A self.cvImageDisplay._tkcanvas.pac=
k()=0A self.cvImageColorbar._tkcanvas.pack()=0A=0A########## adding axes to=
 GUI elements ###########=0A#get data (2d matrix)=0Aself.finaldata =3D self=
.build_data()=0A=0A#define first axes (image)=0Aself.axes1 =3D self.mplfIma=
geDisplay.gca(frameon=3DFalse)=0Aself.axes1.set_position((0.015,0.02,0.98,0=
.96))=0Adisplay =3D self.axes1.imshow(self.finaldata,=0A                   =
                        origin=3D'upper',=0A                               =
            aspect=3D'auto',=0A                                           i=
nterpolation=3Dinterpolation,=0A                                           =
cmap=3Dimagecolormap,=0A                                           vmin=3Dm=
invalue,=0A                                           vmax=3Dmaxvalue)=0Ase=
lf.axes1.set_axis_off()=0A=0A#define colorbar=0Aself.axes2 =3D self.mplfIma=
geColorbar.gca()=0Aself.axes2.set_position((0.1,0.05,barsize,0.9))=0Aself.c=
olorbar =3D figcolorbar.colorbar(display,=0A                               =
                      format=3D'%'+legendformat,=0A                        =
                             cax=3Dself.axes2)=0A#set font size=0Acolorbart=
extlist =3D self.axes2.get_yticklabels()=0Afor element in colorbartextlist:=
 element.set_fontsize(fontsize)=0A=0A#display image=0Aself.cvimage.show()=
=0Acvcolorbar.show()=0A=0A########## saving result ###########=0A #get curr=
ent figure=0Aimage =3D self.mplfImageDisplay.gca()=0Acolorbar =3D self.mplf=
ImageColorbar.gca()=0A=0A#calculate fig width=0Aimagewidth =3D self.mplfIma=
geDisplay.get_figwidth()=0Acolorbarwidth  =3D self.mplfImageColorbar.get_fi=
gwidth()=0Atotalwidth =3D imagewidth + colorbarwidth=0A=0A #calculate fig h=
eight=0A imageheight    =3D self.mplfImageDisplay.get_figheight()=0A colorb=
arheight =3D self.mplfImageColorbar.get_figheight()=0A totalheight =3D max(=
imageheight,colorbarheight)=0A =0A#create new figure=0Aoutputfigure =3D mpl=
.figure.Figure(figsize=3D(totalwidth,totalheight),dpi=3D100,facecolor=3D'wh=
ite')=0A=0A#add axes=0Aoutputfigure.add_axes(axes=3Dimage,anchor=3D'w')=0A=
=0Aoutputfigure.add_axes(axes=3Dcolorbar,anchor=3D'e')=0A=0A=0A#I also trie=
d playing about adding a canvas but it didn't help much=0A#cvouputfigure =
=3D FigureCanvasTkAgg(outputfigure)=0A#outputfigure.draw(cvouputfigure.get_=
renderer())=0A=0A#save figure=0Aoutputfigure.savefig(outputfilename)=0A----=
--=0A=0A=0A=0A=0A=0A=0A=0A      ___________________________________________=
__________________________________ =0ANe gardez plus qu'une seule adresse m=
ail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr

Hello,
The situation (at least in my case) has definitely improved (for now) 
after adding a clf() command at the end of every figure I generate.
Somehow, it looks like pylab cannot properly "forget" the previous 
figure before drawing a new one unless you explicitly tell it.
Maybe it is worth a try.
Cheers

Lorenzo


Darren Dale wrote:
> Hi Lorenzo,
>
> On Tuesday 15 January 2008 4:14:24 pm Lorenzo Isella wrote:
>   
>> Dear All,
>> I am sending this email out of frustration, but I hope that someone will
>> be able to tell me what is going on.
>> I am using pylab on a Debian testing box.
>> I have the feeling that there is some problem with pylab when I
>> alternate, as I am doing now, many linear and log-log plots. Very often,
>> pylab complains about the fact that I cannot take the log of a negative
>> number even if all the quantities are positive or even if I have
>> replaced the loglog with a linear plot...
>> An example (sorry but there are long arrays involved and I cannot
>> reproduce all my code here):
>>
>>
>> #! /usr/bin/env python
>>
>> import scipy as s
>> import numpy as n
>> import pylab as p
>> #from rpy import r
>> #import distance_calc as d_calc
>>
>> # now I try performing a least-square fitting
>> import scipy.optimize as sopt
>>
>>
>> #do my stuff here
>>
>> print "my_n_clus_fit is, ", my_n_clus_fit
>> print "my_r_sq_fit",my_r_sq_fit
>> print "n_clu_rep2 is, ", n_clu_rep2
>> print "R_sq is", R_sq
>>
>> p.plot(n_clu_rep2,R_sq,"bo",my_n_clus_fit,my_r_sq_fit, "ro")
>> p.xlabel('particles in cluster')
>> p.ylabel('R square')
>> #p.legend(('beta=1e-2,100 part','beta=1e-1, 100 part', 'beta=1e-1, 200
>> part'))
>> p.title('Cluster-size vs average radius of gyration')
>> p.grid(True)
>> p.savefig("R_gyr_vs_N_fit.pdf")
>> p.hold(False)
>>
>> and the relevant part of the output is:
>>     
>
> [...]
>   
>> Traceback (most recent call last):
>>   File "./r_gyr.py", line 322, in ?
>>     p.plot(n_clu_rep2,R_sq,"bo",my_n_clus_fit,my_r_sq_fit, "ro")
>>   File "/usr/lib/python2.4/site-packages/matplotlib/pylab.py", line
>> 2028, in plot
>>     ret =  gca().plot(*args, **kwargs)
>>   File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 2540,
>> in plot
>>     self.autoscale_view(scalex=scalex, scaley=scaley)
>>   File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 1207,
>> in autoscale_view
>>     self.set_xlim(XL)
>>   File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 1493,
>> in set_xlim
>>     raise ValueError('Cannot set nonpositive limits with log transform')
>> ValueError: Cannot set nonpositive limits with log transform
>>     
>
>
> I think this is a bug. It sounds like the same issue I reported a while back: 
> http://www.nabble.com/Cannot-set-nonpositive-limits-with-log-transform-to12154187.html
>
> I havent had a chance to look into a solution. I filed a bug report at 
> sourceforge (1872462). I'm worried the fix will be disruptive, but several 
> people have run into this. I'm sorry you got bit as well.
>
> Darren
>
>   

Hi Lorenzo,

On Tuesday 15 January 2008 4:14:24 pm Lorenzo Isella wrote:
> Dear All,
> I am sending this email out of frustration, but I hope that someone will
> be able to tell me what is going on.
> I am using pylab on a Debian testing box.
> I have the feeling that there is some problem with pylab when I
> alternate, as I am doing now, many linear and log-log plots. Very often,
> pylab complains about the fact that I cannot take the log of a negative
> number even if all the quantities are positive or even if I have
> replaced the loglog with a linear plot...
> An example (sorry but there are long arrays involved and I cannot
> reproduce all my code here):
>
>
> #! /usr/bin/env python
>
> import scipy as s
> import numpy as n
> import pylab as p
> #from rpy import r
> #import distance_calc as d_calc
>
> # now I try performing a least-square fitting
> import scipy.optimize as sopt
>
>
> #do my stuff here
>
> print "my_n_clus_fit is, ", my_n_clus_fit
> print "my_r_sq_fit",my_r_sq_fit
> print "n_clu_rep2 is, ", n_clu_rep2
> print "R_sq is", R_sq
>
> p.plot(n_clu_rep2,R_sq,"bo",my_n_clus_fit,my_r_sq_fit, "ro")
> p.xlabel('particles in cluster')
> p.ylabel('R square')
> #p.legend(('beta=1e-2,100 part','beta=1e-1, 100 part', 'beta=1e-1, 200
> part'))
> p.title('Cluster-size vs average radius of gyration')
> p.grid(True)
> p.savefig("R_gyr_vs_N_fit.pdf")
> p.hold(False)
>
> and the relevant part of the output is:

[...]
> Traceback (most recent call last):
>   File "./r_gyr.py", line 322, in ?
>     p.plot(n_clu_rep2,R_sq,"bo",my_n_clus_fit,my_r_sq_fit, "ro")
>   File "/usr/lib/python2.4/site-packages/matplotlib/pylab.py", line
> 2028, in plot
>     ret =  gca().plot(*args, **kwargs)
>   File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 2540,
> in plot
>     self.autoscale_view(scalex=scalex, scaley=scaley)
>   File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 1207,
> in autoscale_view
>     self.set_xlim(XL)
>   File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 1493,
> in set_xlim
>     raise ValueError('Cannot set nonpositive limits with log transform')
> ValueError: Cannot set nonpositive limits with log transform


I think this is a bug. It sounds like the same issue I reported a while back: 
http://www.nabble.com/Cannot-set-nonpositive-limits-with-log-transform-to12154187.html

I havent had a chance to look into a solution. I filed a bug report at 
sourceforge (1872462). I'm worried the fix will be disruptive, but several 
people have run into this. I'm sorry you got bit as well.

Darren

Dear All,
I am sending this email out of frustration, but I hope that someone will 
be able to tell me what is going on.
I am using pylab on a Debian testing box.
I have the feeling that there is some problem with pylab when I 
alternate, as I am doing now, many linear and log-log plots. Very often, 
pylab complains about the fact that I cannot take the log of a negative 
number even if all the quantities are positive or even if I have 
replaced the loglog with a linear plot...
An example (sorry but there are long arrays involved and I cannot 
reproduce all my code here):


#! /usr/bin/env python

import scipy as s
import numpy as n
import pylab as p
#from rpy import r
#import distance_calc as d_calc

# now I try performing a least-square fitting
import scipy.optimize as sopt


#do my stuff here

print "my_n_clus_fit is, ", my_n_clus_fit
print "my_r_sq_fit",my_r_sq_fit
print "n_clu_rep2 is, ", n_clu_rep2
print "R_sq is", R_sq

p.plot(n_clu_rep2,R_sq,"bo",my_n_clus_fit,my_r_sq_fit, "ro")
p.xlabel('particles in cluster')
p.ylabel('R square')
#p.legend(('beta=1e-2,100 part','beta=1e-1, 100 part', 'beta=1e-1, 200 
part'))
p.title('Cluster-size vs average radius of gyration')
p.grid(True)
p.savefig("R_gyr_vs_N_fit.pdf")
p.hold(False)

and the relevant part of the output is:

my_n_clus_fit is,  [  1.73717793   1.80682874   1.87927215   
1.95462012   2.03298911
   2.11450025   2.19927951   2.28745793   2.3791718    2.47456287
   2.57377856   2.67697224   2.78430338   2.89593788   3.01204829
   3.13281405   3.25842182   3.38906574   3.52494773   3.66627779
   3.81327439   3.96616469   4.12518502   4.29058114   4.46260869
   4.64153356   4.82763228   5.02119248   5.22251334   5.43190599
   5.64969409   5.87621423   6.11181652   6.35686511   6.61173873
   6.87683131   7.15255258   7.43932868   7.73760284   8.04783608
   8.37050788   8.70611696   9.05518203   9.41824259   9.79585979
  10.18861726  10.59712204  11.0220055   11.46392434  11.92356157
  12.40162761  12.89886134  13.41603127  13.95393673  14.5134091
  15.09531308  15.70054806  16.33004946  16.98479025  17.66578236
  18.37407832  19.11077287  19.87700462  20.67395784  21.50286429
  22.3650051   23.26171279  24.19437329  25.16442809  26.17337649
  27.22277791  28.31425426  29.44949252  30.63024729  31.85834351
  33.13567931  34.4642289   35.84604567  37.28326532  38.77810918
  40.33288767  41.9500038   43.63195696  45.38134673  47.20087695
  49.09335983  51.06172036  53.10900079  55.23836536  57.45310516
  59.75664325  62.15253993  64.64449825  67.23636972  69.93216028
  72.73603649  75.65233197  78.68555407  81.84039088  85.12171845]
my_r_sq_fit [ -2.44174991  -2.39098053  -2.3384157   -2.28399191  
-2.22764342
  -2.16930217  -2.10889768  -2.04635699  -1.98160454  -1.91456212
  -1.84514875  -1.77328057  -1.69887077  -1.62182947  -1.5420636
  -1.45947681  -1.37396934  -1.2854379   -1.19377555  -1.09887155
  -1.00061127  -0.89887602  -0.7935429   -0.68448467  -0.5715696
  -0.45466128  -0.3336185   -0.20829504  -0.07853952   0.05580481
   0.19490022   0.33891475   0.48802235   0.64240314   0.80224361
   0.96773685   1.13908274   1.31648829   1.50016779   1.69034312
   1.88724399   2.09110827   2.30218221   2.52072078   2.74698797
   2.98125709   3.22381115   3.47494314   3.73495641   4.00416505
   4.28289426   4.57148072   4.87027305   5.17963218   5.49993179
   5.8315588    6.1749138    6.53041155   6.89848148   7.27956821
   7.67413208   8.0826497    8.50561455   8.94353755   9.3969477
   9.86639271  10.35243964  10.85567563  11.37670856  11.91616783
  12.47470507  13.05299499  13.65173614  14.27165177  14.91349073
  15.57802832  16.26606729  16.97843877  17.71600327  18.47965174
  19.27030664  20.08892307  20.93648986  21.81403087  22.72260612
  23.66331314  24.63728827  25.64570804  26.68979058  27.77079711
  28.89003345  30.04885158  31.24865133  32.49088201  33.77704418
  35.10869149  36.48743251  37.91493273  39.3929165   40.92316917]
n_clu_rep2 is,  [   4.    5.    6.    7.    8.   10.   11.   12.   13.   
14.   15.   16.
   17.   18.   19.   20.   21.   22.   23.   24.   25.   27.   28.   30.
   31.   32.   33.   34.   35.   36.   37.   38.   40.   41.   42.   43.
   44.   45.   46.   47.   48.   50.   51.   54.   55.   56.   57.   58.
   61.   62.   63.   67.   68.   72.   74.   77.   85.   86.   89.   91.
   92.   93.   99.  108.  113.  114.  120.  145.  196.]
R_sq is [   0.41290231    0.63219481    0.50921663    0.60545032    
0.71055003
    1.24577182    1.01656939    1.35542652    1.68938719    1.96960734
    1.8587407     1.25335718    3.38501487    1.73960942    2.66786771
    0.78304002    1.9472814     2.59527354    2.82129068    1.95855193
    3.97830788    2.42530912    4.77505413    8.87282622    2.6755995
    3.53707475    1.36507753    3.87191511    6.63215895    3.45373196
    8.22450598    5.15409505    3.28241933   11.51525185    1.11042409
    4.69324094    4.337342      7.0230309     6.98027636    2.10322888
    3.63283609    3.69895425    2.39382279   24.86394803    6.14874073
    6.59253038    7.7958188    20.11261061    9.22805741    1.60984999
    4.08915341   13.37680959   10.7330271     9.19988106   18.86681803
   16.01119253   16.7679522    12.83288125   28.15284186    2.96382532
   28.60613768   10.38346233   24.59404975    3.06332058  120.46780399
   29.27275139   25.00389411   17.40801449   21.23510666]
Traceback (most recent call last):
  File "./r_gyr.py", line 322, in ?
    p.plot(n_clu_rep2,R_sq,"bo",my_n_clus_fit,my_r_sq_fit, "ro")
  File "/usr/lib/python2.4/site-packages/matplotlib/pylab.py", line 
2028, in plot
    ret =  gca().plot(*args, **kwargs)
  File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 2540, 
in plot
    self.autoscale_view(scalex=scalex, scaley=scaley)
  File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 1207, 
in autoscale_view
    self.set_xlim(XL)
  File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 1493, 
in set_xlim
    raise ValueError('Cannot set nonpositive limits with log transform')
ValueError: Cannot set nonpositive limits with log transform


But there is no log transform here! True, before I was plotting 
n_clu_rep2  and R_sq in a loglog plot, but this should not be a problem.
Is there anything wrong with:

p.plot(n_clu_rep2,R_sq,"bo",my_n_clus_fit,my_r_sq_fit, "ro")
p.xlabel('particles in cluster')
p.ylabel('R square')
#p.legend(('beta=1e-2,100 part','beta=1e-1, 100 part', 'beta=1e-1, 200 
part'))
p.title('Cluster-size vs average radius of gyration')
p.grid(True)
p.savefig("R_gyr_vs_N_fit.pdf")
p.hold(False)

?? It looks like pylab is not able to "forget" the previous plots.
Any help here is really appreciated.
Many thanks

Lorenzo

The patch for legends works except for LineCollection. For any call to 
legend(), I get the errors below,

Paul

Traceback (most recent call last):
   File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py", 
line 331, in expose_event
     self._render_figure(self._pixmap, w, h)
   File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 75, in _render_figure
     FigureCanvasAgg.draw(self)
   File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
line 257, in draw
     self.figure.draw(self.renderer)
   File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 
698, in draw
     for a in self.axes: a.draw(renderer)
   File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 
1397, in draw
     a.draw(renderer)
   File "/usr/lib/python2.5/site-packages/matplotlib/legend.py", line 
206, in draw
     h.draw(renderer)
   File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 
480, in draw
     lineFunc(renderer, gc, tpath, affine.frozen())
   File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 
740, in _draw_dashed
     renderer.draw_path(gc, path, trans)
ValueError: Dash sequence must be an even length sequence; found 1
Traceback (most recent call last):
   File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py", 
line 331, in expose_event
     self._render_figure(self._pixmap, w, h)
   File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 75, in _render_figure
     FigureCanvasAgg.draw(self)
   File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
line 257, in draw
     self.figure.draw(self.renderer)
   File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 
698, in draw
     for a in self.axes: a.draw(renderer)
   File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 
1397, in draw
     a.draw(renderer)
   File "/usr/lib/python2.5/site-packages/matplotlib/legend.py", line 
206, in draw
     h.draw(renderer)
   File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 
480, in draw
     lineFunc(renderer, gc, tpath, affine.frozen())
   File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 
740, in _draw_dashed
     renderer.draw_path(gc, path, trans)
ValueError: Dash sequence must be an even length sequence; found 1
Traceback (most recent call last):
   File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py", 
line 331, in expose_event
     self._render_figure(self._pixmap, w, h)
   File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 75, in _render_figure
     FigureCanvasAgg.draw(self)
   File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
line 257, in draw
     self.figure.draw(self.renderer)
   File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 
698, in draw
     for a in self.axes: a.draw(renderer)
   File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 
1397, in draw
     a.draw(renderer)
   File "/usr/lib/python2.5/site-packages/matplotlib/legend.py", line 
206, in draw
     h.draw(renderer)
   File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 
480, in draw
     lineFunc(renderer, gc, tpath, affine.frozen())
   File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 
740, in _draw_dashed
     renderer.draw_path(gc, path, trans)
ValueError: Dash sequence must be an even length sequence; found 1




Michael Droettboom wrote:
> [I'm bringing this back to the list.  Hope you don't mind.]
> 
> I've been doing a lot of non-matplotlib work lately and this fell off my 
> radar.  Thanks for the reminder.
> 
> The patch looks good to me.  I'm not concerned about doing all this in 
> _get_handles as opposed to Legend.__init__.  I actually think it's 
> better in _get_handles because then it's more connected to the creation 
> of the handles themselves.  (And of course _get_handles is only ever 
> called from __init__ anyway, so it really is just an organizational 
> extension of __init__).  I moved all references to _xdata to 
> _get_handles to be consistent.
> 
> The one concern I had is that _xdata is being stored as a member 
> variable, which implicitly assumes that it will be the same for all 
> handles.  After your patch, it can be different for each handle -- for 
> instance a line made of markers vs. dashing.  So I've just made it a 
> local variable to _get_handles and recreate it separately for each 
> handle.  There's no reason to try to share something so small, and it 
> just feels safer (fewer potential side effects) that way.
> 
> I've committed this in r4871.  Please check it out and kick the tires 
> with all the test cases you came up with along the way and let me know 
> how it goes.
> 
> Cheers,
> Mike
> 
> Paul Novak wrote:
>> Mike,
>>
>> Thank you for handling the PS backend issues. Below is an email I sent 
>> earlier about an updated patch for fixing legends with numpoints=1; I 
>> didn't get any response probably because of my delay in responding. If 
>> I should restart this thread on the mailing list, I can.
>>
>> Included below is an updated patch fixing the legend with numpoints=1. 
>> The patch has been made against SVN and works for Line2D, 
>> LineCollection, Patch, and RegularPolyCollection. The patch could be 
>> merged.
>>
>> I also think the patch could be improved. Currently, handle._marker is 
>> examined to determine if the legend should contain lines or symbols, 
>> but this is done in the _get_handles function. It would be better if 
>> that could be moved into the Legend class definition, however, I do 
>> not know how to examine handle._marker in the Legend class definition.
>>
>> Again, I would appreciate any comments or improvements.
>>
>> Thanks,
>>
>> Paul
>>
>> diff -u a/lib/matplotlib/legend.py b/lib/matplotlib/legend.py
>> --- a/lib/matplotlib/legend.py    2008-01-09 13:11:00.000000000 -0600
>> +++ b/lib/matplotlib/legend.py    2008-01-09 13:08:36.000000000 -0600
>> @@ -175,9 +175,7 @@
>>          # make a trial box in the middle of the axes.  relocate it
>>          # based on it's bbox
>>          left, top = 0.5, 0.5
>> -        if self.numpoints == 1:
>> -            self._xdata = npy.array([left + self.handlelen*0.5])
>> -        else:
>> +        if self.numpoints > 1:
>>              self._xdata = npy.linspace(left, left + self.handlelen, 
>> self.numpoints)
>>          textleft = left+ self.handlelen+self.handletextsep
>>          self.texts = self._get_texts(labels, textleft, top)
>> @@ -236,6 +234,7 @@
>>
>>      def _get_handles(self, handles, texts):
>>          HEIGHT = self._approx_text_height()
>> +        left = 0.5
>>
>>          ret = []   # the returned legend lines
>>
>> @@ -243,6 +242,10 @@
>>              x, y = label.get_position()
>>              x -= self.handlelen + self.handletextsep
>>              if isinstance(handle, Line2D):
>> +                if self.numpoints == 1 and handle._marker == 'None':
>> +                    self._xdata = npy.linspace(left, left + 
>> self.handlelen, 2)
>> +                elif self.numpoints == 1:
>> +                    self._xdata = npy.array([left + self.handlelen*0.5])
>>                  ydata = (y-HEIGHT/2)*npy.ones(self._xdata.shape, float)
>>                  legline = Line2D(self._xdata, ydata)
>>                  legline.update_from(handle)
>> @@ -253,7 +256,8 @@
>>
>>                  ret.append(legline)
>>              elif isinstance(handle, Patch):
>> -
>> +                if self.numpoints == 1:
>> +                    self._xdata = npy.linspace(left, left + 
>> self.handlelen, 2)
>>                  p = Rectangle(xy=(min(self._xdata), y-3/4*HEIGHT),
>>                                width = self.handlelen, height=HEIGHT/2,
>>                                )
>> @@ -263,6 +267,8 @@
>>                  p.set_clip_path(None)
>>                  ret.append(p)
>>              elif isinstance(handle, LineCollection):
>> +                if self.numpoints == 1:
>> +                    self._xdata = npy.linspace(left, left + 
>> self.handlelen, 2)
>>                  ydata = (y-HEIGHT/2)*npy.ones(self._xdata.shape, float)
>>                  legline = Line2D(self._xdata, ydata)
>>                  self._set_artist_props(legline)
>> @@ -277,6 +283,8 @@
>>                  ret.append(legline)
>>
>>              elif isinstance(handle, RegularPolyCollection):
>> +                if self.numpoints == 1:
>> +                    self._xdata = npy.array([left])
>>                  p = Rectangle(xy=(min(self._xdata), y-3/4*HEIGHT),
>>                                width = self.handlelen, height=HEIGHT/2,
>>                                )
>>
>>
>>
>> Michael Droettboom wrote:
>>> Thanks for pointing that out -- I didn't even notice.
>>>
>>> There was an ordering problem in how colors were being set.  This 
>>> should be fixed in r4870.
>>>
>>> Cheers,
>>> Mike
>>>
>>> Paul Novak wrote:
>>>> I have another problem after updating to SVN r4869. The ticks take 
>>>> the color of the plotted line without regard to the default. For 
>>>> example,
>>>>
>>>> matplotlib.rc('xtick', color='black')
>>>> matplotlib.rc('ytick', color='black')
>>>> plot(x, y, 'red')
>>>>
>>>> will give red ticks.
>>>>
>>>> Paul
>>>>
>>>> Michael Droettboom wrote:
>>>>> It's a bug.  It's now possible for rgba colors to make their way 
>>>>> all the way down to that level, so the code needs to truncate that 
>>>>> to rgb (Ps can't handle alpha anyway).
>>>>>
>>>>> This is committed in SVN r4869.
>>>>>
>>>>> Cheers,
>>>>> Mike
>>>>>
>>>>> Paul Novak wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I am trying to use the PS backend to make some simple line plots, 
>>>>>> using the following script, but I get the error messages included 
>>>>>> below when I try to plot with usetex=True. I have also included 
>>>>>> the output from --verbose=helpful. I am using the current SVN, and 
>>>>>> I don't recall having this problem when using 0.91.1.
>>>>>>
>>>>>> Thanks,
>>>>>> Paul
>>>>>>
>>>>>> ---
>>>>>> #!/usr/bin/env python
>>>>>>
>>>>>> import matplotlib
>>>>>> matplotlib.use('PS')
>>>>>> matplotlib.rc('text', usetex = 'True')
>>>>>> from pylab import *
>>>>>>
>>>>>> x = arange(0,5)
>>>>>> y = 2 * x
>>>>>> figure(1)
>>>>>> plot(x, y)
>>>>>> savefig('psfig')
>>>>>> show()
>>>>>>
>>>>>> ---
>>>>>> $HOME=/home/pnovak
>>>>>> CONFIGDIR=/home/pnovak/.matplotlib
>>>>>> matplotlib data path 
>>>>>> /usr/lib/python2.5/site-packages/matplotlib/mpl-data
>>>>>> loaded rc file /home/pnovak/.matplotlib/matplotlibrc
>>>>>> matplotlib version 0.98pre
>>>>>> verbose.level helpful
>>>>>> interactive is False
>>>>>> units is False
>>>>>> platform is linux2
>>>>>> numerix numpy 1.0.3.1
>>>>>> Using fontManager instance from 
>>>>>> /home/pnovak/.matplotlib/fontManager.cache
>>>>>> backend PS version Level II
>>>>>> Found dvipng version 1.5
>>>>>>
>>>>>> Traceback (most recent call last):
>>>>>>    File "junk.py", line 15, in <module>
>>>>>>      savefig('psfig')
>>>>>>    File "/usr/lib/python2.5/site-packages/matplotlib/pyplot.py", 
>>>>>> line 271, in savefig
>>>>>>      return fig.savefig(*args, **kwargs)
>>>>>>    File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", 
>>>>>> line 854, in savefig
>>>>>>      self.canvas.print_figure(*args, **kwargs)
>>>>>>    File 
>>>>>> "/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py", 
>>>>>> line 1085, in print_figure
>>>>>>      **kwargs)
>>>>>>    File 
>>>>>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_ps.py", 
>>>>>> line 837, in print_ps
>>>>>>      return self._print_ps(outfile, 'ps', *args, **kwargs)
>>>>>>    File 
>>>>>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_ps.py", 
>>>>>> line 863, in _print_ps
>>>>>>      orientation, isLandscape, papertype)
>>>>>>    File 
>>>>>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_ps.py", 
>>>>>> line 1051, in _print_figure_tex
>>>>>>      self.figure.draw(renderer)
>>>>>>    File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", 
>>>>>> line 698, in draw
>>>>>>      for a in self.axes: a.draw(renderer)
>>>>>>    File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", 
>>>>>> line 1397, in draw
>>>>>>      a.draw(renderer)
>>>>>>    File "/usr/lib/python2.5/site-packages/matplotlib/axis.py", 
>>>>>> line 680, in draw
>>>>>>      tick.draw(renderer)
>>>>>>    File "/usr/lib/python2.5/site-packages/matplotlib/axis.py", 
>>>>>> line 179, in draw
>>>>>>      self.label1.draw(renderer)
>>>>>>    File "/usr/lib/python2.5/site-packages/matplotlib/text.py", 
>>>>>> line 761, in draw
>>>>>>      Text.draw(self, renderer)
>>>>>>    File "/usr/lib/python2.5/site-packages/matplotlib/text.py", 
>>>>>> line 309, in draw
>>>>>>      self._fontproperties, angle)
>>>>>>    File 
>>>>>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_ps.py", 
>>>>>> line 544, in draw_tex
>>>>>>      color = '%1.3f,%1.3f,%1.3f'% gc.get_rgb()
>>>>>> TypeError: not all arguments converted during string formatting
>>>>>>
>>>>>> ------------------------------------------------------------------------- 
>>>>>>
>>>>>> This SF.net email is sponsored by: Microsoft
>>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>>>> _______________________________________________
>>>>>> Matplotlib-users mailing list
>>>>>> Mat...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>>
>>>
> 

[I'm bringing this back to the list.  Hope you don't mind.]

I've been doing a lot of non-matplotlib work lately and this fell off my 
radar.  Thanks for the reminder.

The patch looks good to me.  I'm not concerned about doing all this in 
_get_handles as opposed to Legend.__init__.  I actually think it's 
better in _get_handles because then it's more connected to the creation 
of the handles themselves.  (And of course _get_handles is only ever 
called from __init__ anyway, so it really is just an organizational 
extension of __init__).  I moved all references to _xdata to 
_get_handles to be consistent.

The one concern I had is that _xdata is being stored as a member 
variable, which implicitly assumes that it will be the same for all 
handles.  After your patch, it can be different for each handle -- for 
instance a line made of markers vs. dashing.  So I've just made it a 
local variable to _get_handles and recreate it separately for each 
handle.  There's no reason to try to share something so small, and it 
just feels safer (fewer potential side effects) that way.

I've committed this in r4871.  Please check it out and kick the tires 
with all the test cases you came up with along the way and let me know 
how it goes.

Cheers,
Mike

Paul Novak wrote:
> Mike,
> 
> Thank you for handling the PS backend issues. Below is an email I sent 
> earlier about an updated patch for fixing legends with numpoints=1; I 
> didn't get any response probably because of my delay in responding. If I 
> should restart this thread on the mailing list, I can.
> 
> Included below is an updated patch fixing the legend with numpoints=1. 
> The patch has been made against SVN and works for Line2D, 
> LineCollection, Patch, and RegularPolyCollection. The patch could be 
> merged.
> 
> I also think the patch could be improved. Currently, handle._marker is 
> examined to determine if the legend should contain lines or symbols, but 
> this is done in the _get_handles function. It would be better if that 
> could be moved into the Legend class definition, however, I do not know 
> how to examine handle._marker in the Legend class definition.
> 
> Again, I would appreciate any comments or improvements.
> 
> Thanks,
> 
> Paul
> 
> diff -u a/lib/matplotlib/legend.py b/lib/matplotlib/legend.py
> --- a/lib/matplotlib/legend.py    2008-01-09 13:11:00.000000000 -0600
> +++ b/lib/matplotlib/legend.py    2008-01-09 13:08:36.000000000 -0600
> @@ -175,9 +175,7 @@
>          # make a trial box in the middle of the axes.  relocate it
>          # based on it's bbox
>          left, top = 0.5, 0.5
> -        if self.numpoints == 1:
> -            self._xdata = npy.array([left + self.handlelen*0.5])
> -        else:
> +        if self.numpoints > 1:
>              self._xdata = npy.linspace(left, left + self.handlelen, 
> self.numpoints)
>          textleft = left+ self.handlelen+self.handletextsep
>          self.texts = self._get_texts(labels, textleft, top)
> @@ -236,6 +234,7 @@
> 
>      def _get_handles(self, handles, texts):
>          HEIGHT = self._approx_text_height()
> +        left = 0.5
> 
>          ret = []   # the returned legend lines
> 
> @@ -243,6 +242,10 @@
>              x, y = label.get_position()
>              x -= self.handlelen + self.handletextsep
>              if isinstance(handle, Line2D):
> +                if self.numpoints == 1 and handle._marker == 'None':
> +                    self._xdata = npy.linspace(left, left + 
> self.handlelen, 2)
> +                elif self.numpoints == 1:
> +                    self._xdata = npy.array([left + self.handlelen*0.5])
>                  ydata = (y-HEIGHT/2)*npy.ones(self._xdata.shape, float)
>                  legline = Line2D(self._xdata, ydata)
>                  legline.update_from(handle)
> @@ -253,7 +256,8 @@
> 
>                  ret.append(legline)
>              elif isinstance(handle, Patch):
> -
> +                if self.numpoints == 1:
> +                    self._xdata = npy.linspace(left, left + 
> self.handlelen, 2)
>                  p = Rectangle(xy=(min(self._xdata), y-3/4*HEIGHT),
>                                width = self.handlelen, height=HEIGHT/2,
>                                )
> @@ -263,6 +267,8 @@
>                  p.set_clip_path(None)
>                  ret.append(p)
>              elif isinstance(handle, LineCollection):
> +                if self.numpoints == 1:
> +                    self._xdata = npy.linspace(left, left + 
> self.handlelen, 2)
>                  ydata = (y-HEIGHT/2)*npy.ones(self._xdata.shape, float)
>                  legline = Line2D(self._xdata, ydata)
>                  self._set_artist_props(legline)
> @@ -277,6 +283,8 @@
>                  ret.append(legline)
> 
>              elif isinstance(handle, RegularPolyCollection):
> +                if self.numpoints == 1:
> +                    self._xdata = npy.array([left])
>                  p = Rectangle(xy=(min(self._xdata), y-3/4*HEIGHT),
>                                width = self.handlelen, height=HEIGHT/2,
>                                )
> 
> 
> 
> Michael Droettboom wrote:
>> Thanks for pointing that out -- I didn't even notice.
>>
>> There was an ordering problem in how colors were being set.  This 
>> should be fixed in r4870.
>>
>> Cheers,
>> Mike
>>
>> Paul Novak wrote:
>>> I have another problem after updating to SVN r4869. The ticks take 
>>> the color of the plotted line without regard to the default. For 
>>> example,
>>>
>>> matplotlib.rc('xtick', color='black')
>>> matplotlib.rc('ytick', color='black')
>>> plot(x, y, 'red')
>>>
>>> will give red ticks.
>>>
>>> Paul
>>>
>>> Michael Droettboom wrote:
>>>> It's a bug.  It's now possible for rgba colors to make their way all 
>>>> the way down to that level, so the code needs to truncate that to 
>>>> rgb (Ps can't handle alpha anyway).
>>>>
>>>> This is committed in SVN r4869.
>>>>
>>>> Cheers,
>>>> Mike
>>>>
>>>> Paul Novak wrote:
>>>>> Hello,
>>>>>
>>>>> I am trying to use the PS backend to make some simple line plots, 
>>>>> using the following script, but I get the error messages included 
>>>>> below when I try to plot with usetex=True. I have also included the 
>>>>> output from --verbose=helpful. I am using the current SVN, and I 
>>>>> don't recall having this problem when using 0.91.1.
>>>>>
>>>>> Thanks,
>>>>> Paul
>>>>>
>>>>> ---
>>>>> #!/usr/bin/env python
>>>>>
>>>>> import matplotlib
>>>>> matplotlib.use('PS')
>>>>> matplotlib.rc('text', usetex = 'True')
>>>>> from pylab import *
>>>>>
>>>>> x = arange(0,5)
>>>>> y = 2 * x
>>>>> figure(1)
>>>>> plot(x, y)
>>>>> savefig('psfig')
>>>>> show()
>>>>>
>>>>> ---
>>>>> $HOME=/home/pnovak
>>>>> CONFIGDIR=/home/pnovak/.matplotlib
>>>>> matplotlib data path 
>>>>> /usr/lib/python2.5/site-packages/matplotlib/mpl-data
>>>>> loaded rc file /home/pnovak/.matplotlib/matplotlibrc
>>>>> matplotlib version 0.98pre
>>>>> verbose.level helpful
>>>>> interactive is False
>>>>> units is False
>>>>> platform is linux2
>>>>> numerix numpy 1.0.3.1
>>>>> Using fontManager instance from 
>>>>> /home/pnovak/.matplotlib/fontManager.cache
>>>>> backend PS version Level II
>>>>> Found dvipng version 1.5
>>>>>
>>>>> Traceback (most recent call last):
>>>>>    File "junk.py", line 15, in <module>
>>>>>      savefig('psfig')
>>>>>    File "/usr/lib/python2.5/site-packages/matplotlib/pyplot.py", 
>>>>> line 271, in savefig
>>>>>      return fig.savefig(*args, **kwargs)
>>>>>    File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", 
>>>>> line 854, in savefig
>>>>>      self.canvas.print_figure(*args, **kwargs)
>>>>>    File 
>>>>> "/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py", 
>>>>> line 1085, in print_figure
>>>>>      **kwargs)
>>>>>    File 
>>>>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_ps.py", 
>>>>> line 837, in print_ps
>>>>>      return self._print_ps(outfile, 'ps', *args, **kwargs)
>>>>>    File 
>>>>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_ps.py", 
>>>>> line 863, in _print_ps
>>>>>      orientation, isLandscape, papertype)
>>>>>    File 
>>>>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_ps.py", 
>>>>> line 1051, in _print_figure_tex
>>>>>      self.figure.draw(renderer)
>>>>>    File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", 
>>>>> line 698, in draw
>>>>>      for a in self.axes: a.draw(renderer)
>>>>>    File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 
>>>>> 1397, in draw
>>>>>      a.draw(renderer)
>>>>>    File "/usr/lib/python2.5/site-packages/matplotlib/axis.py", line 
>>>>> 680, in draw
>>>>>      tick.draw(renderer)
>>>>>    File "/usr/lib/python2.5/site-packages/matplotlib/axis.py", line 
>>>>> 179, in draw
>>>>>      self.label1.draw(renderer)
>>>>>    File "/usr/lib/python2.5/site-packages/matplotlib/text.py", line 
>>>>> 761, in draw
>>>>>      Text.draw(self, renderer)
>>>>>    File "/usr/lib/python2.5/site-packages/matplotlib/text.py", line 
>>>>> 309, in draw
>>>>>      self._fontproperties, angle)
>>>>>    File 
>>>>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_ps.py", 
>>>>> line 544, in draw_tex
>>>>>      color = '%1.3f,%1.3f,%1.3f'% gc.get_rgb()
>>>>> TypeError: not all arguments converted during string formatting
>>>>>
>>>>> ------------------------------------------------------------------------- 
>>>>>
>>>>> This SF.net email is sponsored by: Microsoft
>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>>> _______________________________________________
>>>>> Matplotlib-users mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>
>>

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA