[matplotlib-devel] [Fwd: Nabble - War on trailing whitespace]
All, Trailing whitespace introduces noise--sometimes a *lot* of noise--into svn changesets. I would very much appreciate it if everyone would try to eliminate trailing whitespace before committing any changes to svn. (And also eliminate hard tabs--I haven't seen many new ones creeping in, but continuing vigilence is appreciated.) Thank you. Eric --- Begin Message --- http://www.nabble.com/War-on-trailing-whitespace-tf1745040.html#a4743846 http://www.sicem.biz/pipermail/gazpacho/2006-January/000200.html These are not exactly what I was looking for, but they are a start. Eric --- End Message --- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] rgba formats
Mike (and others), The standard rgba format in mpl has been a sequence of 4 doubles, but these need to be converted to uint8 before they can be used by Agg, at least. Therefore I added the ability for ScalarMappable.to_rgba to generate uint8 initially, avoiding the extra translation. (This can result in a substantial speedup.) I haven't looked into the other backends, but I am wondering whether, at least in the transform branch, it might make sense to do this more uniformly--that is, go straight to uint8. Or are you already doing this, Mike? Does one ever need more than 8-bits per channel of color resolution? Are all the backends in fact having to do this conversion from 4 doubles to 4 uint8 anyway? Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] pcolorfast
Mike (and others interested in speed),
I have committed an experimental Axes method temporarily called
"pcolorfast" that uses one of three methods for rendering a pcolor-type
plot: an image, a nonuniform image (new implementation in
_backend_agg.cpp), and a quadmesh. Based on the calling signature and
the characteristics of the input grid it selects the fastest method.
The image and nonuniform image are very fast; quadmesh, which is used
only if the grid is not obviously rectilinear, is much slower, but still
enormously faster that plain pcolor if the grid is large.
A peculiarity of the method is that what it returns depends on which
method it picks. It always returns a ScalarMappable, though, so I think
the other differences are acceptable.
Another peculiarity is that when image-type rendering is used, writing a
ps file is still fast and efficient, and the file has a reasonable size;
with quadmesh rendering, a ps file is written based on a polygon
collection, so it can easily become huge and horribly slow to write. It
would be better if we could change the default file writing to use an
image method; then all three methods would perform more similarly on all
backends. This could involve moving quadmesh from collections to image,
and changing quadmesh so that it actually returns an image-like entity.
This is probably getting beyond my abilities, though.
Long-term, I suspect we will want to keep two pcolor-like methods: the
original, which does everything with a patch collection, and can draw
edges; and a modification of pcolorfast (maybe renamed pcolorimage) that
does everything in an image-oriented mode, and does not draw lines.
Pcolorfast is for dense grids, and lines simply are not useful with
dense grids. (Yes, if there are strong requests from users the
line-drawing could be added back to pcolorfast.)
Eric
'''
Quick illustration of axes.pcolorfast
'''
from matplotlib.pyplot import figure, show
import numpy as npy
import matplotlib.numerix.npyma as ma
from matplotlib.image import PcolorImage
from matplotlib import cm
x = npy.arange(0, 4.0, 0.005, dtype=float)
y = npy.arange(0, 5.0, 0.005, dtype=float)
print 'Size %d points' % (len(x) * len(y))
z = npy.sqrt(x[npy.newaxis,:-1]**2 + y[:-1,npy.newaxis]**2)
z = ma.masked_where(z < 1, z)
X, Y = npy.meshgrid(x,y)
print z.shape
fig = figure()
ax = fig.add_subplot(111)
im = ax.pcolorfast(z)
fig.colorbar(im)
ax.set_title('Image')
if 1:
fig2 = figure()
ax = fig2.add_subplot(111)
im = ax.pcolorfast(x*x, y, z)
fig2.colorbar(im)
im.set_cmap(cm.cool)
ax.set_title('Non-uniform image')
if 1:
fig3 = figure()
ax = fig3.add_subplot(111)
im = ax.pcolorfast(X*npy.sqrt(Y), Y*Y, z)
fig3.colorbar(im)
im.set_cmap(cm.hot)
ax.set_title('QuadMesh')
show()
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] reformatting
Would anyone be displeased if I were to reformat all the extension code in ansi style? See http://astyle.sourceforge.net/astyle.html. Personally, I find the present hodge-podge of styles, and the usually-but-not-always 2-space indentation, hard to read and work with; I am much more comfortable with the ansi style. Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Nabble - War on trailing whitespace]
On Nov 18, 2007 11:33 AM, Eric Firing <[EMAIL PROTECTED]> wrote: > Trailing whitespace introduces noise--sometimes a *lot* of noise--into > svn changesets. I would very much appreciate it if everyone would try > to eliminate trailing whitespace before committing any changes to svn. > (And also eliminate hard tabs--I haven't seen many new ones creeping in, > but continuing vigilence is appreciated.) Hey Eric, You probably already know about reindent.py; but since I would rather not assume and run the risk that you aren't familiar with it, here it is: http://svn.python.org/view/python/trunk/Tools/scripts/reindent.py?rev=55804&view=markup It is part of the Python developer's tools and cleans up trailing whitespace as well as fixing tabs. Ideally everyone should be mindful as you request, but this is a useful script to occasionally run anyway. Thanks for all the great work, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
