You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
from numpy import *
from matplotlib.pyplot import *
x = arange(-10,10)
y = (1.0 - 1.0/(x**2+1))**20
figure()
semilogy(x, y, "-o")
grid(True)
savefig("test.png")
Correct Plot (the value y=0 at x=0 is masked out from y-log plot):
Wrong Plot (spurious point at x=0 with y=1e-1):
A git bisect tells me that:
91725d8665975de9a26d631445ab1448b0391e1a is the first bad commit
commit 91725d8665975de9a26d631445ab1448b0391e1a
Author: Joel B. Mohler <joel@kiwistrawberry.us>
Date: Thu Aug 21 10:43:28 2014 -0400
use _fast_from_codes_and_verts in transform code
The commit diff introduces the use of _fast_from_codes_and_verts,
so the issue is probably somewhere deeper inside this function.
Good, I'm also glad to see this is not on the 1.4.x branch. I looked at this a bit, but it's not obvious to me how the optimized constructor is in-equivalent from the normal Path init relevant to this bug. My general comment is that looking at this reminded me how expensive the transform code is in the drawing. In fact, it appears that the transform is run separately/redundantly for the vertices and the path. It seems there are two performance issues -- this transform could be cached for later screen updates (e.g. resizing the window doesn't require recomputing the log transform) and the redundancy alleged in this paragraph.
It may make sense to revert the change and look at the transform code altogether. Certainly that's a daunting prospect.
Perhaps here is as good as any place to make my next mildly outrageous claim. There's a 4-fold (or more) rendering speed improvement for interactive applications (e.g. qtagg backend) to be had by doing the following 3 things:
Activity
tacaswell commentedon Jan 13, 2015
attn @jbmohler
tacaswell commentedon Jan 17, 2015
Retagged this as 1.5.x as this commit is not on the 1.4.x branch phew.
jbmohler commentedon Jan 17, 2015
Good, I'm also glad to see this is not on the 1.4.x branch. I looked at this a bit, but it's not obvious to me how the optimized constructor is in-equivalent from the normal Path init relevant to this bug. My general comment is that looking at this reminded me how expensive the transform code is in the drawing. In fact, it appears that the transform is run separately/redundantly for the vertices and the path. It seems there are two performance issues -- this transform could be cached for later screen updates (e.g. resizing the window doesn't require recomputing the log transform) and the redundancy alleged in this paragraph.
It may make sense to revert the change and look at the transform code altogether. Certainly that's a daunting prospect.
Perhaps here is as good as any place to make my next mildly outrageous claim. There's a 4-fold (or more) rendering speed improvement for interactive applications (e.g. qtagg backend) to be had by doing the following 3 things:
These things are in order of speed gain so it's difficult for me to get enthusiastic about attacking transform code.
TST : add test for log transform with zero
tacaswell commentedon Jan 17, 2015
@jbmohler I have also been looking at it and am also not seeing what is different. Can you send an email to the devel list re fastaxes?
I am glad some one is looking into ways to make mpl more efficient/better for interactive work!
TST : add test for log transform with zero
BUG : fix optimized path transforms
TST : add test for log transform with zero
jenshnielsen commentedon Jan 31, 2015
Fixed by #4050