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