matplotlib-devel Mailing List for matplotlib

John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> 
> 
> Eric> Based on a quick look, I think it would be easy to make
> Eric> LineCollection and PolyCollection accept a numerix array in
> Eric> place of [(x,y), (x,y), ...] for each line segment or
> Eric> polygon; specifically, this could replaced by an N x 2
> Eric> array, where the first column would be x and the second
> Eric> would be y. Backwards compatibility could be maintained
> Eric> easily. This would eliminate quite a bit of useless
> Eric> conversion back and forth among lists, tuples, and arrays.
> Eric> As it is, each sequence of sequences is converted to a pair
> Eric> of arrays in backend_bases, and typically it started out as
> Eric> either a 2-D numerix array or a pair of 1-D arrays in the
> Eric> code that is calling the collection constructor.
> 
> I think this is a useful enhancement. I would think that representing
> each segment as (x,y) where x and y are 1D arrays, might be slightly
> more natural than using an Nx2 but others may disagree.
John,
I have been working on this and I can probably commit something in the 
next few days. I have been pursuing the Nx2 representation for the 
following reasons:
1) It is highly compatible with the present sequence of tuples, so that 
the two representations can coexist peacefully:
a = [(1,2), (3,4), (5,6)] # present style
aa = numerix.array(a) # new style
In most places, a and aa work the same with no change to the code. The 
exception is where code does something like "a.append(b)". This occurs 
in the contour labelling code. I haven't fixed it yet, but I don't see 
any fundamental problem in doing so.
2) The Nx2 representation streamlines code because it involves one 2-D 
object, "XY", in place of two 1-D objects, X and Y. This also 
eliminates the need to check that the lengths of X and Y match. 
Logically, X and Y must go together, so why not keep them glued together 
in a single array?
Because of the compatibility, there is very little code that actually 
has to be changed to support the numerix array. There is a potential 
for breakage of user code, however. This is a concern. I don't know of 
any way of eliminating it entirely while retaining the efficiency 
benefits of using numerix arrays when possible. One thing that might 
help is to have the transform seq_xy_tups method handle both input 
forms, and return the form corresponding to the input. I can do this; I 
now have a transform method that handles both "a" and "aa", but 
presently it returns a numerix array in either case.
The optimization you describe below sounds good, but I want to finish 
stage 1, above, first.
Eric
> 
> How often does it come up that we want a homogeneous line collection,
> ie a bunch of lines segments with the same properties (color,
> linewidth...)? The most expensive part of the agg line collection
> renderer is probably the multiple calls to render_scanlines, which is
> necessary every time we change the linewidth or color. 
> 
> If all of the lines in a collection shared the same properties, we
> could draw the entire path with a combination of lineto/moveto, and
> just stroke and render it once (agg has an upper limit on path length
> though, since at some point I added the following to draw_lines
> 
> if ((i%10000)==0) {
> //draw the path in chunks
> _render_lines_path(path, gc);
> path.remove_all();
> path.move_to(thisx, thisy);
> }
> 
> Ie I render it every 10000 points. 
> 
> Actually, as I type this I realize the case of homogeneous lines (and
> polys) can be handled by the backend method "draw_path". One
> possibility is for the LineCollection to detect the homogeneous case
> len(linewidths)==1 and len(colors)==1 and call out to draw_path
> instead of draw_line_collection (the same could be done for a regular
> poly collection). Some extra extension code would probably be
> necessary to build the path efficiently from numerix arrays, and to
> handle the "chunking" problem to avoid extra long paths, but for
> certain special cases (scatters and quiver w/o color mapping) it would
> probably be a big win. The downside is that not all backend implement
> draw_paths, but the Collection front-end could detect this and fall
> back on the old approach if draw_paths is not implemented.
> 
> JDH

>>>>> "Martin" == Martin Spacek <sc...@ms...> writes:
 Martin> Don't know if this is the best way, but here's a solution:
 Martin> def bar(self, left, height, width=0.8, bottom=0,
 Martin> color=matplotlib.rcParams['patch.facecolor'], yerr=None,
 Martin> xerr=None, ecolor=matplotlib.rcParams['patch.edgecolor'],
 Martin> capsize=3 ):
Hey Martin, 
We don't put the rc defaults in the function declaration because these
are evaluated only once, at module load time, which prevents users
from being able to change the defaults after the module is loaded. So
we use this idiom
def somefunc(edgecolor=None):
 if edgecolor is None: edgecolor = rcParams['patch.edgecolor']
If you'd like to submit a patch for bar and barh, that'd be great.
Thanks,
JDH

I've noticed that the rcparams settings for patch.facecolor and
patch.endcolor is ignored by bar() and barh() (and therefore hist()),
always displaying as blue and black, respectively. Is this intentional? 
I'm running matplotlib 0.87.3
The culprit:
def bar(self, left, height, width=0.8, bottom=0,
 color='b', yerr=None, xerr=None, ecolor='k', capsize=3
 ):
Don't know if this is the best way, but here's a solution:
def bar(self, left, height, width=0.8, bottom=0,
 color=matplotlib.rcParams['patch.facecolor'],
 yerr=None, xerr=None,
 ecolor=matplotlib.rcParams['patch.edgecolor'], capsize=3
 ):
Similar situation for barh()
Cheers,
Martin

Hi - this is my first post to such a list, so bear with me.=20
=20
I've just installed mpl3d and have had success with the examples shown =
at
http://www.scipy.org/Cookbook/Matplotlib/mplot3D
=20
We currently don't have numpy installed and using the older Numeric, so =
I
used the following instead:
=20
N =3D 100
x =3D zeros((N,N),Float)
y =3D zeros((N,N),Float)
z =3D zeros((N,N),Float)
u =3D arange(0,2*pi,2.*pi/N)
v =3D arange(0,2*pi,2.*pi/N)
=20
for i in range(N):
 for j in range(N):
 x[i,j] =3D cos(u[i])*sin(v[j])
 y[i,j] =3D sin(u[i])*sin(v[j])
 z[i,j] =3D cos(v[j])
=20
fig=3Dp.figure()
ax =3D p3.Axes3D(fig)
ax.plot_surface(x,y,z)
ax.set_xlabel('X')
ax.set_ylabel('Y')
ax.set_zlabel('Z')
fig.add_axes(ax)
p.show()
p.savefig('surfacetest')
p.close()
=20
which worked a treat (apart from the figure not closing on the first =
instance
...).
=20
However, if I change N to 10, I get the following error message:
=20
Traceback (most recent call last):
 File "test.py", line 47, in ?
 ax.plot_surface(x,y,z)
 File "c:\Python24\lib\site-packages\mpl3d\mplot3d.py, line 921, in
plot_surface
 norm =3D normalize(min(shade),max(shade))
ValueError: min() arg is an empty sequence
=20
It seems that if the number of columns or rows is less than 20 than =
rstride
and cstride =3D 0. This means that the boxes required to make the =
polygons in
the surface plot won't be constructed. However, you can get a 3D plot if =
you
use plot_wireframe or plot3D instead with N =3D 10 (but these plots =
aren't
quite as nice as the surface plot would be).
=20
Is there a minimum size of the arrays which plot_surface will work on? =
Is
there a workaround for smaller examples? I'm looking at plotting a =
(smallish)
number of time series solutions as a surface.
=20
Cheers, Jane.
=20
Dr Jane Sexton
Risk Research Group
Geospatial and Earth Monitoring Division
Geoscience Australia