Bug in pylab?

_Lorenzo_Isella · January 15, 2008, 9:14pm

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

Darren_Dale1 · January 16, 2008, 12:10am

Hi Lorenzo,

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

···

On Tuesday 15 January 2008 4:14:24 pm Lorenzo Isella wrote:

_Lorenzo_Isella · January 16, 2008, 12:23am

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

Michael_Droettboom1 · January 16, 2008, 1:22pm

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
matplotlib-users List Signup and Options

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

Darren_Dale1 · January 16, 2008, 2:20pm

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?

···

On Wednesday 16 January 2008 08:22:45 am Michael Droettboom wrote:

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
> Matplotlib-users@lists.sourceforge.net
> matplotlib-users List Signup and Options

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

darren.dale@...163...
office: (607) 255-3819
fax: (607) 255-9001
http://www.chess.cornell.edu

Michael_Droettboom1 · January 17, 2008, 2:05pm

Darren Dale wrote:

···

On Wednesday 16 January 2008 08:22:45 am Michael Droettboom wrote:

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.

That indeed is a problem. I suspect it has something to do with the extra step that log scales do to "round" to the nearest decade. I can have a look when I get a chance, or let me know if you'd like to tackle it, Darren.

Cheers,
Mike

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

Darren_Dale1 · January 21, 2008, 1:17pm

I don't know when I would have a chance to look into this (my wife and I are
trying to buy a house).

Darren

···

On Thursday 17 January 2008 09:05:53 am Michael Droettboom wrote:

Darren Dale wrote:
> On Wednesday 16 January 2008 08:22:45 am Michael Droettboom wrote:
>> 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.

That indeed is a problem. I suspect it has something to do with the
extra step that log scales do to "round" to the nearest decade. I can
have a look when I get a chance, or let me know if you'd like to tackle
it, Darren.