Re: [matplotlib-devel] Fwd: Source of inaccuracies in the matplotlib library

[Benjamin R. <ben...@ou...>]

On Thursday, April 21, 2011, Konrad Bartkowski <k.b...@fz...>
wrote:
> Dear Ben, dear John,
>
>        Thank You for the emails. Well, we have modified only the part
> influencing the modules, that we need or will need in our projects. I
> admit that apart from the deceptions connected with human perception
> (for example
> http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.151.2303 ) still
> the inaccuracy remains. Nevertheless all the surfaces we have rendered
> were unproblematic. Also the examples from the forum rendered correctly
> even for big stride. If it is unsatisfactory one can control the
> precision with the stride size.

Just to make sure, you never really described exactly what "numerical
inaccuracies" you were talking about.  From the example you posted, I am
assuming that it is the overlapping/z-sorting issue.  If it is something
else, then I am going to need to see some "before / after" images showing
the difference you are talking about.  If it is the overlapping issue, then
the strides are only incidental to the problem.  The problem exists for any
3d object, with or without strides.

The problem is one of dimensionality.  While mplot3d does correctly
calculate the 3d coordinates of each vertex in the perspective coordinate
system, only one value for the depth axis can be reported for each artist.
 If the artist has many vertexes with different depth values, then a single
value will never be sufficient.  It is this reduction of the depth
coordinates from many to one that is the source of the problem.

What your solution does is to not reduce the depth coordinates *as much*.
But it still does a reduction, therefore not solving the problem.  The only
way to properly solve this is with a 3D rendering engine (like OpenGL).

>The modification was written under the
> assumption not to modify too much in the existing system. While writing
> the code we were naturally keeping in mind the ratio of accuracy to the
> computational effort.
>        Since in our projects we didn't need the return value from the
> plot_surface we return the obtained list for the efficiency reasons. But
> if the API should remain unchanged, then one can generate also the
> previous collection and return it instead of the list, while the list is
> added.

This would cause many inconsistencies within the code.  For example, if a
user wants to remove the collection from the axes, it won't work because the
collection doesn't exist in the axes object.  Also, having a collection
object unconnected to any axis might cause unexpected behavior or could even
throw exceptions.

>        I admit, that I didn't consider the changes You mention in the
> consecutive e-mails, since it would mean redesigning Your code. From the
> same reason I also cannot comment them – I simply don't know the
> internal structure of Your code sufficienty. Change on the level of
> Artists would probably imply a lot of other modifications in many, many
> modules.
>

That's ok.  It was actually this problem that pushed me to learn matplotlib
to the point that I could become a developer.  However, it took me another 6
months before I could understand the problem well enough to realize the
source of the issue and what was needed to solve it properly.  If this patch
works well for your purposes, that's great, and I hope it continues to serve
you well.  However, for a broader audience, it introduces too many potential
problems for us.

I hope you continue to use matplotlib and find it useful.  And feel free to
continue commenting on the mplot3d module and how it can be improved!

Cheers,
Ben Root