Ok, forwarding it to the matplotlib-devel list.

Best wishes,

Konrad (on behalf of our workgroup)

plotSurfaceUnix.py (6.51 KB)

plotSurfaceUnix.py (6.51 KB)

## ···

Subject:

Source of inaccuracies in the matplotlib library

Date:

Fri, 8 Apr 2011 18:12:47 +0200

From:

Bartkowski, Konrad

To:

,

,

,

,

CC:

Bartkowski, Konrad , , Matthias Bolten , Grotendorst, Johannes , Steffen, Bernhard

<k.bartkowski@…954…>dd55@…143…<dd55@…143…>mdroe@…31…<mdroe@…31…>efiring@…229…<efiring@…229…>jdhunter@…5…<jdhunter@…5…>jdh2358@…149…<jdh2358@…149…>

<k.bartkowski@…954…>

elmod@…955…

<elmod@…955…>

<bolten@…956…>

<j.grotendorst@…954…>

<b.steffen@…954…>

```
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:
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
```

## http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/msg06869.html

Forschungszentrum Juelich GmbH

52425 Juelich

Sitz der Gesellschaft: Juelich

Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498

Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher

Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),

Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,

Prof. Dr. Sebastian M. Schmidt

Besuchen Sie uns auf unserem neuen Webauftritt unter www.fz-juelich.de