matplotlib-users Mailing List for matplotlib

On Jan 13, 2008 7:26 PM, Christopher Fonnesbeck <fon...@ma...> wrote:
> On some OSX systems, pylab is failing on importing pylab because of
> lack of GTK. This appears to be a bug; if the system doesnt have gtk,
> it should simply not import that backend to begin with.
matplotlib does not do runtime checking to see if a backend is
available (arguably it should, but it does not_. It does do compile
time checking, and if gtk was available at compile time it will spit
out a default matplotlib rc file which uses gtkagg. If you ship this
to your users who do not have gtk, it can cause problems (you can
tweak this with setup.cfg).
You may want to make tkagg the default backend if you are distributing
binaries, since it is most likely to work on the user side.
JDH

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