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
> Matplotlib-users@lists.sourceforge.net
> 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
-------------------------------------------------------------------------
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
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
