On Mon, Apr 11, 2011 at 4:16 AM, Konrad Bartkowski < k.b...@fz...> wrote: > Ok, forwarding it to the matplotlib-devel list. > > > Best wishes, > > Konrad (on behalf of our workgroup) > > > -------- Original Message -------- Subject: Source of inaccuracies in the > matplotlib library Date: Fri, 8 Apr 2011 18:12:47 +0200 From: Bartkowski, > Konrad <k.b...@fz...> <k.b...@fz...> To: > dd...@co... <dd...@co...> <dd...@co...>, md...@st... > <md...@st...> <md...@st...>, ef...@ha... > <ef...@ha...> <ef...@ha...>, jdh...@ac... > <jdh...@ac...> <jdh...@ac...>, > jd...@gm... <jd...@gm...> <jd...@gm...> CC: Bartkowski, > Konrad <k.b...@fz...> <k.b...@fz...>, > el...@in... <el...@in...> <el...@in...>, Matthias Bolten > <bo...@ma...> <bo...@ma...>, > Grotendorst, Johannes <j.g...@fz...><j.g...@fz...>, > Steffen, Bernhard <b.s...@fz...> <b.s...@fz...> > > Dear Matplotlib developers, > > I am writing about the matplotlib library with the mpl_toolkits. First > of all let me emphasize how great software it is. Recently, in one of > our projects we were rendering big surfaces and encountered the > following problem: > http://www.mail-archive.com/mat...@li.../msg06869.html > > It's not a bug (which all in all is a natural and unavoidable ingredient > of the software, and especially in such a big and complex system like > matplotlib would be fully natural), since the software does exactly the > projection mathematics that it is expected to do, but a source of the > inaccuracies, which is especially visible in the critical examples. For > the profit of the Python community we are sending You a proposition of a > modification of the surface plotting rendering system, in case You find > it interesting enough to include in the consecutive version of the > library. In the source code from the attachment we redesigned a little > bit the computation process – since the computations are especially > sensible to numerical errors, that are for example amplified while > norming or processing the quaterions in the various stages (for example > division over coordinate in the perspective projection). Therefore the > computational focus can be shifted from the Polygon collection to the > polygons itself. In the example from the above forum or the slightly > modified one, one can observe a big difference in the numerical > precision while the speed of the computations does not decrease (at > least visibly). While instead of the surfaces from the forum, the > following surfaces are rendered: > > u = np.linspace(0, 2 * np.pi, 100) > v = np.linspace(0, np.pi, 100) > > x = 10 * np.outer(np.cos(u), np.sin(v)) > y = 10 * np.outer(np.sin(u), np.sin(v)) > z = 10 * np.outer(np.ones(np.size(u)), np.cos(v)) > > ax.plot_surface(x, y, z, rstride=8, cstride=8, color='y', alpha=0.5) > shiftX=28 > shiftY=28 > X,Y=np.meshgrid(range(-20+shiftX,20+shiftX),range(-20+shiftY,20+shiftY)) > Z=np.ones((X.shape[0], Y.shape[1])) > ax.plot_surface(X, Y, Z, color='r', rstride=10, cstride=10, alpha=1.0) > > the issue is visible for example at the azimuth=40 , elevation=70 – with > those parameters the mentioned case is visible on the red surface, while > with elevation=68 not. Moreover, now also the stride is big (in the new > approach the influence of increasing stride on the numerical precision > grows). > So again let me use this opportunity to thank You for empowering the > Python community worldwide in a great, powerful scientific visualization > tool. > > Best wishes, > Konrad Bartkowski > > Konrad, Thank you for this contribution. It seems that I am currently the de facto maintainer of the mplot3d code, but I have been focused on my PhD for the past month. I will take a look at the code in more detail over the weekend. Thanks! Ben Root