Thread: [matplotlib-devel] semilogx and semilogy don't reset linear scale

I noticed that semilogx and semilogy don't check if the linear axis (y- 
axis for semilogx; x-axis for semilogy) is actually linear. Thus, if I  
call semilogx and then call semilogy *on the same plot*, I end up with  
a loglog plot.

Below is a simple patch. I'm not sure how useful this fix is since  
most people wouldn't want to make these calls on the same plot (since  
the second call would override the first)---I was working  
interactively in IPython so it did make a difference.

Cheers,
-Tony


Index: lib/matplotlib/axes.py
===================================================================
--- lib/matplotlib/axes.py	(revision 7557)
+++ lib/matplotlib/axes.py	(working copy)
@@ -3615,6 +3615,7 @@
               }

          self.set_xscale('log', **d)
+        self.set_yscale('linear')
          b =  self._hold
          self._hold = True # we've already processed the hold
          l = self.plot(*args, **kwargs)
@@ -3665,6 +3666,7 @@
               'nonposy': kwargs.pop('nonposy', 'mask'),
               }
          self.set_yscale('log', **d)
+        self.set_xscale('linear')
          b =  self._hold
          self._hold = True # we've already processed the hold
          l = self.plot(*args, **kwargs)

Did this email ever appear on list? I didn't see it after sending my  
original post, but I found it on the Sourceforge mail archives. I'm  
trying a different email address as an experiment.

In any case, any comments on the patch?

-Tony

On Aug 24, 2009, at 5:31 PM, Tony Yu wrote:

> I noticed that semilogx and semilogy don't check if the linear axis  
> (y-axis for semilogx; x-axis for semilogy) is actually linear. Thus,  
> if I call semilogx and then call semilogy *on the same plot*, I end  
> up with a loglog plot.
>
> Below is a simple patch. I'm not sure how useful this fix is since  
> most people wouldn't want to make these calls on the same plot  
> (since the second call would override the first)---I was working  
> interactively in IPython so it did make a difference.
>
> Cheers,
> -Tony
>
>
> Index: lib/matplotlib/axes.py
> ===================================================================
> --- lib/matplotlib/axes.py	(revision 7557)
> +++ lib/matplotlib/axes.py	(working copy)
> @@ -3615,6 +3615,7 @@
>              }
>
>         self.set_xscale('log', **d)
> +        self.set_yscale('linear')
>         b =  self._hold
>         self._hold = True # we've already processed the hold
>         l = self.plot(*args, **kwargs)
> @@ -3665,6 +3666,7 @@
>              'nonposy': kwargs.pop('nonposy', 'mask'),
>              }
>         self.set_yscale('log', **d)
> +        self.set_xscale('linear')
>         b =  self._hold
>         self._hold = True # we've already processed the hold
>         l = self.plot(*args, **kwargs)

Tony S Yu wrote:
> Did this email ever appear on list? I didn't see it after sending my  
> original post, but I found it on the Sourceforge mail archives. I'm  
> trying a different email address as an experiment.

Tony,

It did appear the first time, but I guess everyone who saw it figured 
someone else would deal with it.
> 
> In any case, any comments on the patch?

Looks reasonable to me.  I will apply it.

Eric

> 
> -Tony
> 
> On Aug 24, 2009, at 5:31 PM, Tony Yu wrote:
> 
>> I noticed that semilogx and semilogy don't check if the linear axis  
>> (y-axis for semilogx; x-axis for semilogy) is actually linear. Thus,  
>> if I call semilogx and then call semilogy *on the same plot*, I end  
>> up with a loglog plot.
>>
>> Below is a simple patch. I'm not sure how useful this fix is since  
>> most people wouldn't want to make these calls on the same plot  
>> (since the second call would override the first)---I was working  
>> interactively in IPython so it did make a difference.
>>
>> Cheers,
>> -Tony
>>
>>
>> Index: lib/matplotlib/axes.py
>> ===================================================================
>> --- lib/matplotlib/axes.py	(revision 7557)
>> +++ lib/matplotlib/axes.py	(working copy)
>> @@ -3615,6 +3615,7 @@
>>              }
>>
>>         self.set_xscale('log', **d)
>> +        self.set_yscale('linear')
>>         b =  self._hold
>>         self._hold = True # we've already processed the hold
>>         l = self.plot(*args, **kwargs)
>> @@ -3665,6 +3666,7 @@
>>              'nonposy': kwargs.pop('nonposy', 'mask'),
>>              }
>>         self.set_yscale('log', **d)
>> +        self.set_xscale('linear')
>>         b =  self._hold
>>         self._hold = True # we've already processed the hold
>>         l = self.plot(*args, **kwargs)
> 
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Eric Firing wrote:
> Tony S Yu wrote:
>   
>> Did this email ever appear on list? I didn't see it after sending my  
>> original post, but I found it on the Sourceforge mail archives. I'm  
>> trying a different email address as an experiment.
>>     
>
> Tony,
>
> It did appear the first time, but I guess everyone who saw it figured 
> someone else would deal with it.
>   
>> In any case, any comments on the patch?
>>     
>
> Looks reasonable to me.  I will apply it.
>   
I think this caused the test_matplotlib.TestAxes.empty_datetime test to
fail. You can see the result at
http://mpl.code.astraw.com/mac-osx-x86-sage/test_matplotlib.TestAxes.empty_datetime/overview.html

Specifically, it looks like the farthest left xticklabel is no longer
getting displayed. Personally, I think it looks better this way, but now
that the test suite is coming online, we will finally start noticing
little things like this.

Eric, if you think the new image is OK, can you download it from
http://mpl.code.astraw.com/mac-osx-x86-sage/test_matplotlib.TestAxes.empty_datetime/actual.gif
and then check it into
test/test_matplotlib/baseline/TestAxes/empty_datetime.png

In fact, I just checked in a KnownFail test decorator heavily based on
numpy's implementation, so once this test starts passing, the Mac OS X
buildslave should have all the tests returning success or knownfail.

Thanks,
Andrew

Eric Firing <ef...@ha...> writes:

> Andrew Straw wrote:
>> Eric Firing wrote:
>>>> Specifically, it looks like the farthest left xticklabel is no longer
>>>> getting displayed. Personally, I think it looks better this way, but now
>>>> that the test suite is coming online, we will finally start noticing
>>>> little things like this.
>>> I agree that the newer version, without the first label, is better--but
>>> I can't imagine how the change to semilogx and semilogy could make a
>>> difference like this.  It must be something else.
>> 
>> Well, if you look at
>> http://mpl-buildbot.code.astraw.com/builders/build%20and%20test%3A%20Mac%20OS%20X%20x86%20(sage%20buildslave)/builds/34/steps/test/logs/stdio
>> versus
>> http://mpl-buildbot.code.astraw.com/builders/build%20and%20test%3A%20Mac%20OS%20X%20x86%20(sage%20buildslave)/builds/35/steps/test/logs/stdio
>> 
>> that's where the difference happened, thus leading to my assertion. What
>> changed between those two builds was r7585. Perhaps something else is
>> responsible, though...
>
> 7584 was the Tony's change on the branch; 7585 was the svnmerge to the 
> trunk, which pulled in earlier changes that had not been merged yet. The 
> others were just documentation, though, so I am still mystified.  Oh, well.

If I'm reading the waterfall display correctly, it looks like my commit
7597 changed the result again. I only touched documentation and
docstrings... have you tried running the buildbot several times on the
same sources?

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Andrew Straw wrote:
> Eric Firing wrote:
>> Tony S Yu wrote:
>>   
>>> Did this email ever appear on list? I didn't see it after sending my  
>>> original post, but I found it on the Sourceforge mail archives. I'm  
>>> trying a different email address as an experiment.
>>>     
>> Tony,
>>
>> It did appear the first time, but I guess everyone who saw it figured 
>> someone else would deal with it.
>>   
>>> In any case, any comments on the patch?
>>>     
>> Looks reasonable to me.  I will apply it.
>>   
> I think this caused the test_matplotlib.TestAxes.empty_datetime test to
> fail. You can see the result at
> http://mpl.code.astraw.com/mac-osx-x86-sage/test_matplotlib.TestAxes.empty_datetime/overview.html
> 
> Specifically, it looks like the farthest left xticklabel is no longer
> getting displayed. Personally, I think it looks better this way, but now
> that the test suite is coming online, we will finally start noticing
> little things like this.

I agree that the newer version, without the first label, is better--but 
I can't imagine how the change to semilogx and semilogy could make a 
difference like this.  It must be something else.

> 
> Eric, if you think the new image is OK, can you download it from
> http://mpl.code.astraw.com/mac-osx-x86-sage/test_matplotlib.TestAxes.empty_datetime/actual.gif
> and then check it into
> test/test_matplotlib/baseline/TestAxes/empty_datetime.png

Done (with *.png, not actual.gif).

Eric

> 
> In fact, I just checked in a KnownFail test decorator heavily based on
> numpy's implementation, so once this test starts passing, the Mac OS X
> buildslave should have all the tests returning success or knownfail.
> 
> Thanks,
> Andrew
> 
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Eric Firing wrote:
>> Specifically, it looks like the farthest left xticklabel is no longer
>> getting displayed. Personally, I think it looks better this way, but now
>> that the test suite is coming online, we will finally start noticing
>> little things like this.
> 
> I agree that the newer version, without the first label, is better--but
> I can't imagine how the change to semilogx and semilogy could make a
> difference like this.  It must be something else.

Well, if you look at

http://mpl-buildbot.code.astraw.com/builders/build%20and%20test%3A%20Mac%20OS%20X%20x86%20(sage%20buildslave)/builds/34/steps/test/logs/stdio

versus

http://mpl-buildbot.code.astraw.com/builders/build%20and%20test%3A%20Mac%20OS%20X%20x86%20(sage%20buildslave)/builds/35/steps/test/logs/stdio

that's where the difference happened, thus leading to my assertion. What
changed between those two builds was r7585. Perhaps something else is
responsible, though...

>>
>> Eric, if you think the new image is OK, can you download it from
>> http://mpl.code.astraw.com/mac-osx-x86-sage/test_matplotlib.TestAxes.empty_datetime/actual.gif
>>
>> and then check it into
>> test/test_matplotlib/baseline/TestAxes/empty_datetime.png
> 
> Done (with *.png, not actual.gif).

Ahh yes, good catch. Thanks for correcting this.

> 
> Eric
> 
>>
>> In fact, I just checked in a KnownFail test decorator heavily based on
>> numpy's implementation, so once this test starts passing, the Mac OS X
>> buildslave should have all the tests returning success or knownfail.

And look -- a buildslave is not failing!
http://mpl-buildbot.code.astraw.com/waterfall

-Andrew

Andrew Straw wrote:
> Eric Firing wrote:
>>> Specifically, it looks like the farthest left xticklabel is no longer
>>> getting displayed. Personally, I think it looks better this way, but now
>>> that the test suite is coming online, we will finally start noticing
>>> little things like this.
>> I agree that the newer version, without the first label, is better--but
>> I can't imagine how the change to semilogx and semilogy could make a
>> difference like this.  It must be something else.
> 
> Well, if you look at
> 
> http://mpl-buildbot.code.astraw.com/builders/build%20and%20test%3A%20Mac%20OS%20X%20x86%20(sage%20buildslave)/builds/34/steps/test/logs/stdio
> 
> versus
> 
> http://mpl-buildbot.code.astraw.com/builders/build%20and%20test%3A%20Mac%20OS%20X%20x86%20(sage%20buildslave)/builds/35/steps/test/logs/stdio
> 
> that's where the difference happened, thus leading to my assertion. What
> changed between those two builds was r7585. Perhaps something else is
> responsible, though...

7584 was the Tony's change on the branch; 7585 was the svnmerge to the 
trunk, which pulled in earlier changes that had not been merged yet. The 
others were just documentation, though, so I am still mystified.  Oh, well.

Eric

Jouni K. Seppänen wrote:
> Eric Firing <ef...@ha...> writes:
>
>   
>> Andrew Straw wrote:
>>     
>>> Eric Firing wrote:
>>>       
>>>>> Specifically, it looks like the farthest left xticklabel is no longer
>>>>> getting displayed. Personally, I think it looks better this way, but now
>>>>> that the test suite is coming online, we will finally start noticing
>>>>> little things like this.
>>>>>           
>>>> I agree that the newer version, without the first label, is better--but
>>>> I can't imagine how the change to semilogx and semilogy could make a
>>>> difference like this.  It must be something else.
>>>>         
>>> Well, if you look at
>>> http://mpl-buildbot.code.astraw.com/builders/build%20and%20test%3A%20Mac%20OS%20X%20x86%20(sage%20buildslave)/builds/34/steps/test/logs/stdio
>>> versus
>>> http://mpl-buildbot.code.astraw.com/builders/build%20and%20test%3A%20Mac%20OS%20X%20x86%20(sage%20buildslave)/builds/35/steps/test/logs/stdio
>>>
>>> that's where the difference happened, thus leading to my assertion. What
>>> changed between those two builds was r7585. Perhaps something else is
>>> responsible, though...
>>>       
>> 7584 was the Tony's change on the branch; 7585 was the svnmerge to the 
>> trunk, which pulled in earlier changes that had not been merged yet. The 
>> others were just documentation, though, so I am still mystified.  Oh, well.
>>     
>
> If I'm reading the waterfall display correctly, it looks like my commit
> 7597 changed the result again. I only touched documentation and
> docstrings... have you tried running the buildbot several times on the
> same sources?
>   

Curiouser and curiouser...

No, I hadn't considered that it might be non-deterministic. However,
looking at the absdiff image of test_matplotlib.TestAxes.empty_datetime,
this is a totally different failure than we were seeing with Eric's
patch. I should probably start archiving the results of the failed
images so we can go back in time looking at these things.

I'm going to ponder this for a while.

-Andrew

On Sun, Aug 30, 2009 at 10:24 AM, Andrew Straw<str...@as...> wrote:

> No, I hadn't considered that it might be non-deterministic. However,
> looking at the absdiff image of test_matplotlib.TestAxes.empty_datetime,
> this is a totally different failure than we were seeing with Eric's
> patch. I should probably start archiving the results of the failed
> images so we can go back in time looking at these things.
>
> I'm going to ponder this for a while.

So now I am getting what looks like a font error on the sage buildbot,
even though I wasn't getting one before on this image.  Is this
because the new good was generated on linux with a different font
config, you think?  It would be really nice if we could crack this
font issue.

I tracked down and fixed the unitized tick formatter, and removed the
known failure decorator from that test, so we hopefully will see that
error drop out of the next build.

JDH

On Sun, Aug 30, 2009 at 11:42 AM, John Hunter<jd...@gm...> wrote:

> So now I am getting what looks like a font error on the sage buildbot,
> even though I wasn't getting one before on this image.  Is this
> because the new good was generated on linux with a different font
> config, you think?  It would be really nice if we could crack this
> font issue.
>
> I tracked down and fixed the unitized tick formatter, and removed the
> known failure decorator from that test, so we hopefully will see that
> error drop out of the next build.


Hey this is strage now the baseline image is wrong (it has one line
and should have two).  Earlier didn't the baseline have two and the
actual have one?  Did someone upload the broken one line version as
the new baseline.  I can fix the baseline with the new actual, but I
am curious how this baseline image got in there.

JDH

On Sun, Aug 30, 2009 at 11:47 AM, John Hunter<jd...@gm...> wrote:

> Hey this is strage now the baseline image is wrong (it has one line
> and should have two).  Earlier didn't the baseline have two and the
> actual have one?  Did someone upload the broken one line version as
> the new baseline.  I can fix the baseline with the new actual, but I
> am curious how this baseline image got in there.

OK, I figured this out.  The new failure was on formatter4, not
formatter5.  I didn't see that when I posted earlier.  It turns out
when we were working at scipy and I wrote that script to move new
saved-results into baseline, I inadvertently moved a bad formatter4
image into the baseline, so the baseline image was broken.  When I
fixed the bug, the unit test caught the difference.  I've updated the
baseline so now everything should be good for that particular test.

JDH

On Sun, Aug 30, 2009 at 12:57 PM, John Hunter<jd...@gm...> wrote:

> OK, I figured this out.  The new failure was on formatter4, not
> formatter5.  I didn't see that when I posted earlier.  It turns out
> when we were working at scipy and I wrote that script to move new
> saved-results into baseline, I inadvertently moved a bad formatter4
> image into the baseline, so the baseline image was broken.  When I
> fixed the bug, the unit test caught the difference.  I've updated the
> baseline so now everything should be good for that particular test.

The empty_datetime continues to mystefy me.  The actual had ticks from
1..23 and the baseline had ticks from 2..00.  The current behavior on
my box is 1..23 and that seems fine to me, so I re-updated the
baseline with that file.  I'm attaching the actual and baseline from
the last buildbot before my update.  The sage box *should* pass on the
next build test because I've corrected the two known failures.  If
there is anything I am missing about this empty datetime test, let me
know

John Hunter wrote:
> On Sun, Aug 30, 2009 at 12:57 PM, John Hunter<jd...@gm...> wrote:
> 
>> OK, I figured this out.  The new failure was on formatter4, not
>> formatter5.  I didn't see that when I posted earlier.  It turns out
>> when we were working at scipy and I wrote that script to move new
>> saved-results into baseline, I inadvertently moved a bad formatter4
>> image into the baseline, so the baseline image was broken.  When I
>> fixed the bug, the unit test caught the difference.  I've updated the
>> baseline so now everything should be good for that particular test.
> 
> The empty_datetime continues to mystefy me.  The actual had ticks from
> 1..23 and the baseline had ticks from 2..00.  The current behavior on
> my box is 1..23 and that seems fine to me, so I re-updated the
> baseline with that file.  I'm attaching the actual and baseline from
> the last buildbot before my update.  The sage box *should* pass on the
> next build test because I've corrected the two known failures.  If
> there is anything I am missing about this empty datetime test, let me
> know

So it sounds like there have been three different behaviors: 0 to 24, 1 
to 23, and 2 to 24.  I think what we are seeing here is differences in 
floating point behavior among different platforms, and/or differences in 
datetime implementation from one python version to another.  The 
standard python library datetime is being used to generate the floating 
point xlim in days.  It looks like (2009, 1, 20) and (2009, 1, 21) can 
end up as floating point numbers a hair above or a hair below the target 
integers, and that difference of a hair is enough to determine whether a 
tick is generated or not.

A side point here is that the precision of the floating point numbers is 
lousy for most applications, because of the choice of "year 1" as the 
origin.  This is a case of mpl following a bad choice by Matlab.

One way to get around the first problem--the datetime tick dependence on 
platform--would be to put fudge factors into the autoscaling so that the 
limits would be expanded some small amount.  More generally, the 
autoscaling could have margins, which might default to the tiny amount 
necessary to prevent the datetime indeterminacy, but might be put to 
other good uses by the user.  Often one really wants the  xlim and ylim 
to be a little wider than the data range, so that symbols are plotted 
entirely within the axes, for example.  This was suggested a very long 
time ago, and it has resurfaced many times in my mind, but obviously I 
never did anything about it.

Eric