matplotlib-devel Mailing List for matplotlib

On Tuesday 04 April 2006 16:48, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
> Darren> I see a draw_lines_testing in backend_ps. I think it could
> Darren> be a good approach, but it doesnt make it very easy to
> Darren> skip unplottable elements like nans, infs. Could xy_tup
> Darren> accept a kwarg to make it raise an error when it tries to
> Darren> transform an inf or a nan?
>
> I don't see why not. Alternatively, the nan testing could be done in
> "drawone". I was planning on filtering the path in chunks (eg 100
> verts at a time) through drawone using map or listcomps, which should
> be faster and will not violate the max path size of some postscript
> interpreters. But I didn't get that far when my wife made me go to
> bed. So if you want to pick up where I left off, feel free.
Ok, I finished it off, unmasked it, and made similar changes to draw_markers. 
Changes in svn 2257.
Darren

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> I see a draw_lines_testing in backend_ps. I think it could
 Darren> be a good approach, but it doesnt make it very easy to
 Darren> skip unplottable elements like nans, infs. Could xy_tup
 Darren> accept a kwarg to make it raise an error when it tries to
 Darren> transform an inf or a nan?
I don't see why not. Alternatively, the nan testing could be done in
"drawone". I was planning on filtering the path in chunks (eg 100
verts at a time) through drawone using map or listcomps, which should
be faster and will not violate the max path size of some postscript
interpreters. But I didn't get that far when my wife made me go to
bed. So if you want to pick up where I left off, feel free.
JDH

On Monday 03 April 2006 22:16, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
> Darren> Also, if I do the transform in backend_ps, instead of
> Darren> passing it to the postscript interpreter, I see a big
> Darren> speedup at render time. Right now I am doing this
> Darren> transform by hand:
>
> Darren> a,b,c,d,tx,ty=vec6 xo = a*x+c*y +tx yo = b*x+d*y + ty x,y
> Darren> = xo,yo
>
> Darren> Is there a better way to do this? I thought I could simply
> Darren> call numerix_x_y, but that function is not compatible with
> Darren> nonlinear transforms (returns a domain error if one of the
> Darren> axes is log-scaled).
>
> You can transform the xy values point by point. Instead of separating
> them into their nonlinear and affine components as we are currently
> doing in backend_ps, you can call trans.xy_tup which will do both. If
> successful, it will return the transformed xy, if it fails, it will
> raise a ValueError, and you can set the moveto/lineto state
> accordingly.
I see a draw_lines_testing in backend_ps. I think it could be a good approach, 
but it doesnt make it very easy to skip unplottable elements like nans, infs. 
Could xy_tup accept a kwarg to make it raise an error when it tries to 
transform an inf or a nan?
Darren

On 3/31/06, Eric Firing <ef...@ha...> wrote:
> For now, I have added an axis('image') mode, which is not quite the same
> as 'scaled', and I have tried to improve the descriptions of the
> options. Please try out the various axis modes, and see if you think
> both the behavior and the descriptions make sense.
Hi,
from what I see, the axis command now works really well, excellent work!
the descriptions also look fine - I am not a native English speaker/writer
so I fail to see how to make them more precise without beeing much more ver=
bose.
thanks,
Helge

Andrew Straw wrote:
> Anyhow, given that basemap comes with 82 MB
>of Earth-specific data which I don't need all the time, I think it would
>be really great if it would be possible to make the inclusion of such
>data optional.
>
That wasn't particularly clear. What I meant to say was that when
running basemap, it would be nice if the contents in the data path were
optionally not loaded if the user knew she was not going to plot
coastlines, etc. I have no problems with actually installing the data,
although to be fair the reason I'd like this feature is so that I don't
have to have a basemap data path at all.

>>>>> "Pearu" == Pearu Peterson <pe...@sc...> writes:
 Pearu> Hi,
 Pearu> When the mouse cursor is over a figure then pressing
 Pearu> certain key buttons such as Tab, CapsLock, Enter, Backspace
 Pearu> etc will trigger the following exception:
Thanks for the report, Pearu. Checkout svn 2256 for a fix.
JDH

Hi,
When the mouse cursor is over a figure then pressing certain
key buttons such as Tab, CapsLock, Enter, Backspace etc
will trigger the following exception:
Traceback (most recent call last):
 File 
"/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_gtk.py", 
line 160, in key_press_event
 FigureCanvasBase.key_press_event(self, key)
 File 
"/usr/local/lib/python2.3/site-packages/matplotlib/backend_bases.py", line 
806, in key_press_event
 func(event)
 File 
"/usr/local/lib/python2.3/site-packages/matplotlib/backend_bases.py", line 
987, in key_press
 elif (event.key.isdigit() and event.key!='0') or event.key=='a':
AttributeError: 'NoneType' object has no attribute 'isdigit'
I am using matplotlib from svn (0.88).
Pearu

Hi Jeff!
I've been using your basemap package as a way to skip the thinking step
when plotting stuff on spheres, which I often do in relation to my
studies of flies' eyes... Anyhow, given that basemap comes with 82 MB
of Earth-specific data which I don't need all the time, I think it would
be really great if it would be possible to make the inclusion of such
data optional. I attach a patch which suffices for my extremely limited
needs (I simply call the __call__ method of the Basemap.Basemap class),
but doubtless causes breakage elsewhere. So, I haven't checked it in,
hoping that you might take the idea and make it a little less brittle.
I suspect there are lots of people who would like to plot things on
spheres, but wouldn't necessarily want the inclusion of coastlines,
rivers, and such. ;) So, I think this is a general purpose improvement
and ask you to consider completing the job.
Unrelated note 1: I committed a patch to setup.py and setupegg.py to
make the thing respect setuptools even if setupegg.py wasn't run.
Unrelated note 2: The setuptools/.egg approach to data is to include it
with the .py files. Initially I thought about modifying the basemap data
path scheme to support this, but in the case of 82M, though, I'd say
that's stretching it a bit, especially with the tendancy for people
(well, me, at least), to have the last 5-100 versions of the .eggs I
built lying in site-packages.
Cheers!
Andrew

Darren,
> I suppose it could be an issue with my gs, a few weeks ago I upgraded to 
> gcc-4.1 and have since recompiled gs. Would you run this script:
> 
> from pylab import *
> x=rand(1000)
> y=rand(1000)
> plot(x,y)
> savefig('apitest.eps')
> 
> and then open the file in ggv? If it opens quickly, maybe you could also try 
> rand(10000).
About 25 seconds on a 1.6G Pentium M, ESP Ghostscript 8.15.1 (2005年09月22日)
Eric

Hi John,
On Monday 03 April 2006 10:16 pm, you wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
> Darren> I think there are two issues here. The postscript
> Darren> interpreter doesnt like to stroke long paths. If I break
> Darren> the path into 50 point chunks instead of 1000 point
> Darren> chunks, I see an improvement.
>
> That's odd, because we never saw an issue stroking long pats before.
> Or at least noone has ever reported it.
I suppose it could be an issue with my gs, a few weeks ago I upgraded to 
gcc-4.1 and have since recompiled gs. Would you run this script:
from pylab import *
x=rand(1000)
y=rand(1000)
plot(x,y)
savefig('apitest.eps')
and then open the file in ggv? If it opens quickly, maybe you could also try 
rand(10000).
> Darren> Also, if I do the transform in backend_ps, instead of
> Darren> passing it to the postscript interpreter, I see a big
> Darren> speedup at render time. Right now I am doing this
> Darren> transform by hand:
>
> Darren> a,b,c,d,tx,ty=vec6 xo = a*x+c*y +tx yo = b*x+d*y + ty x,y
> Darren> = xo,yo
>
> Darren> Is there a better way to do this? I thought I could simply
> Darren> call numerix_x_y, but that function is not compatible with
> Darren> nonlinear transforms (returns a domain error if one of the
> Darren> axes is log-scaled).
>
> You can transform the xy values point by point. Instead of separating
> them into their nonlinear and affine components as we are currently
> doing in backend_ps, you can call trans.xy_tup which will do both. If
> successful, it will return the transformed xy, if it fails, it will
> raise a ValueError, and you can set the moveto/lineto state
> accordingly.
I see. But can that be done in a list comprehension? I think it will require a 
regular for loop. I think doing the transforms as I described above is a 
better solution. It fixed the render times on my machine and my 
backend_driver tests looked fine. I'll wait for feedback, and test a little 
more tomorrow before committing.
> But I am still confused by your previous post: you said that when you
> tried to load the simple plot example PS file in gs, the line rendered
> quickly, and then there was the interminable pause. This suggests
> that it is not the transformation in gs that is the bottleneck, but
> something that happens after it.
It was axes_demo.py. I discovered the reason: a 10,000 pt line is written to 
the postscript file, but only 1000 points are drawn because of the x-axis 
limits. So it was churning away, processing points that dont get drawn. I 
confirmed this was the case: by commenting out the other 9000 points in 
axes_demo_PS.ps, the render time improved.
Darren

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> I think there are two issues here. The postscript
 Darren> interpreter doesnt like to stroke long paths. If I break
 Darren> the path into 50 point chunks instead of 1000 point
 Darren> chunks, I see an improvement.
That's odd, because we never saw an issue stroking long pats before.
Or at least noone has ever reported it.
 Darren> Also, if I do the transform in backend_ps, instead of
 Darren> passing it to the postscript interpreter, I see a big
 Darren> speedup at render time. Right now I am doing this
 Darren> transform by hand:
 Darren> a,b,c,d,tx,ty=vec6 xo = a*x+c*y +tx yo = b*x+d*y + ty x,y
 Darren> = xo,yo
 Darren> Is there a better way to do this? I thought I could simply
 Darren> call numerix_x_y, but that function is not compatible with
 Darren> nonlinear transforms (returns a domain error if one of the
 Darren> axes is log-scaled).
You can transform the xy values point by point. Instead of separating
them into their nonlinear and affine components as we are currently
doing in backend_ps, you can call trans.xy_tup which will do both. If
successful, it will return the transformed xy, if it fails, it will
raise a ValueError, and you can set the moveto/lineto state
accordingly.
But I am still confused by your previous post: you said that when you
tried to load the simple plot example PS file in gs, the line rendered
quickly, and then there was the interminable pause. This suggests
that it is not the transformation in gs that is the bottleneck, but
something that happens after it.
In any case, here is an example script creating a semilogx transform.
The first transformation succeeds, the second raises a ValueError
from matplotlib.transforms import SeparableTransformation, \
 Point, Value, Bbox, LOG10, IDENTITY, Func
import matplotlib.numerix as nx
# make some random bbox transforms 
def rand_point():
 x,y = nx.mlab.rand(2)
 return Point( Value(x), Value(y) )
def rand_bbox():
 ll = rand_point()
 ur = rand_point()
 return Bbox(ll, ur)
b1 = rand_bbox()
b2 = rand_bbox()
funcx = Func(LOG10)
funcy = Func(IDENTITY)
# semilogx
trans = SeparableTransformation(b1, b2, funcx, funcy) 
print trans.xy_tup((1,2)) #ok
print trans.xy_tup((-1,2)) #raises

On Monday 03 April 2006 11:16 am, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
> Darren> I'm having second thoughts about the wisdom of having
> Darren> postscript handle the transforms. With the new API, I run
> Darren> backend_driver.py and get a file called
> Darren> axes_demo_PS.ps. On my machine, it takes about 10 seconds
> Darren> to open this file if it was created with the new API. If I
> Darren> mask draw_markers and recreate the postscript file, it
> Darren> loads instantly.
>
> So you think the performance hit is caused by gs (or whatever viewer
> you are using) by the postscript engine doing the transformations? It
> surprises me that this would be so inefficient.
>
> We have the option of doing the transformations in the ps backend...
I think there are two issues here. The postscript interpreter doesnt like to 
stroke long paths. If I break the path into 50 point chunks instead of 1000 
point chunks, I see an improvement.
Also, if I do the transform in backend_ps, instead of passing it to the 
postscript interpreter, I see a big speedup at render time. Right now I am 
doing this transform by hand:
a,b,c,d,tx,ty=vec6
xo = a*x+c*y +tx
yo = b*x+d*y + ty
x,y = xo,yo
Is there a better way to do this? I thought I could simply call numerix_x_y, 
but that function is not compatible with nonlinear transforms (returns a 
domain error if one of the axes is log-scaled).
Thanks,
Darren