float / double support in Python?

Andrew Dalke adalke at mindspring.com
Sat Feb 8 01:01:47 CET 2003

Brandon Van Every:
> 3D graphics programmers are going to knock Python
> for this until it's fixed.  That's the facts of life.  If you don't care
> about my problem domain, fine.

You generalize too much.  Once upon a time I was a "3D graphics
programmer" doing structural biology.  Problems in that domain
are somewhat interesting because they don't get larger and larger
as fast as computers do.

In 1994, we loaded a 1 million atom system, which really stressed
our 128MB SGI.  In wireframe mode it was about 4 seconds per
frame.  This was in C++ with prebuilt display lists.

The problems people work on these days are *still* under 1 million
atoms.  It's almost 9 years since the above, and modern desktop
machines are a least ten times more powerful than that highish-end
SGI we had.

(As an interesting note, scientific graphics programming tends to be
different from games programming.  For example, we almost never
use textures for anything and instead use a lot of triangles.  Most
consumer graphics cards suffer because they are optimized for
texture based games.  Also note that PyOpenGL can take float
Numeric arrays, as for making tmeshes, so the performance can
be quite good.  Finally note that most structure displays are static,
allowing extra performance by building up OpenGL display lists.)

The problems in this subdomain of 3D graphics programming are
not double/float size/performance but flexibility and being able
to get a visualization system which handles the specific needs of the
specific subdomain.  (Eg, crystallographers use different techniques
than dockers, who use different techniques than folders.)

And so you find that many of the larger, flexible graphics packages
(PyMol, PMV, VMD, Chimera) are pushing more and more Python
scriptability over low-level C++ coding, using C++ only judiciously.

You state that "3D graphics programmers are going to knock Python
for this until it's fixed."  That is incorrect, as there are many 3D
programmers who have decided Python is worth changing over, perhaps
with some C/C++ code for the more intense parts.

I suggest, therefore, that "You are foolish thinking the world revolves
around your perception of the situation."

                    dalke at dalkescientific.com

More information about the Python-list mailing list