float / double support in Python?

[Mike C. Fletcher]

Brandon Van Every wrote:

>Mike C. Fletcher wrote:
>  
>
>>However, the Numeric Python extensions
>>provide _multi-dimensional_ arrays of various data-types, so you can
>>easily represent arrays of vectors efficiently.
>>    
>>
>
>So you're saying the Python overhead occurs only once per array?
>  
>

Precisely, Numeric Python arrays are single objects containing 
multi-dimensional arrays of homogenous data values.  Python object 
overhead is therefore quite minimal as a percentage when you have large 
arrays.

>>What Python is going to be slow on is your classic low-level 3D
>>operations (e.g. tessellation, generating sub-division-surface levels,
>>representing individual polygons/vertices).
>>    
>>
>
>Which is exactly the kind of job I'm more likely to prefer Python for.  If I
>know how to bake things into an array, what do I need a flexible language
>for?  Well, maybe there's something, but I do see a design tendency here.
>  
>

I find the flexible language quite useful when _developing_ the 
algorithms necessary to do the baking.  Keep in mind that Python is 
perfectly capable of doing the low-level work (and it's often very easy 
and straightforward to do the work in Python), just that Python's not 
run-time efficient at doing it (i.e. there is a considerable amount of 
overhead, both processor and memory involved in making it convenient and 
easy).  You can code and experiment with various "recipes" quite easily 
to come up with a functional and debugged algorithm for "baking" objects 
into arrays before you start replacing pieces with C++.

>>BTW, another area where Python trails C/C++ is access to
>>parallelisation mechanisms.  AFAIK there's nothing in Numeric Python
>>that takes
>>advantage of SIMD, so even on large matrices (where Python is normally
>>OK) you could find a significant advantage for C/C++ coded nodes which
>>use SIMD instructions.
>>    
>>
>
>Hrm.  Again, if I can make it into an array, I'm probably going to want to
>move on to C++.  Well, I suppose there's a prototyping path here:
>
>    Python Junk --> Python Numarray --> C++ array --> ASM SIMD array
>
>I don't see merit in always starting from Python.  If I understand and can
>predict the stability of the design, I'd skip straight to C++.
>
...

Perfectly valid approach, though I think you would normally start 
somewhere between "Junk" and "Numarray", as most 3-D Python programmers 
use Numeric as a matter of course.  Also consider that you can often 
leave the "hairy" logic up in the Python layer (if you are including a 
run-time Pythons system), generating a Numeric array which is processed 
by your C++/assembly mechanism.  In other words, it's often not 
necessary to do a full recode.

The approach I would normally suggest, however, particularly for people 
who are possibly not quite so versed in C++, but are able to program in 
it, would be something along these lines (this model is hardly my 
invention, it is probably the most common Python development model):

Experimental phase:
    Code the entire application in Python, including low-level 
functionality (but not re-implementing already available functionality, 
such as Numeric or low-level libraries), make sure the entire thing 
works properly, code with an eye to potentially replacing individual 
classes with C++ equivalents.  Most of the time you only need to replace 
a small number of classes and/or methods.  Concentrate primarily on 
correct operation and fixing corner cases.

Optimization phase:
    With the profiler, determine which methods/classes are too slow, and 
rewrite those, either as array-based methods, or as C++ classes.  These 
will almost certainly wind up being the low-level representations, and a 
few hairy functions.  After just a few projects, this library of 
low-level representations will almost certainly grow into a generic 
extension library for your projects.
    The low-level representations will likely be things such as 
"vertex", "quaternion", "triangle" and "vector".  With some other 
mechanisms for, for instance, doing subdivision surfaces or 
interpolations.  The stuff left in Python will be the "softer" code 
dealing with particular exigencies of a particular project.


Another model:
    The above is not a traditional game-development code-to-the-metal 
approach, and I would be surprised if you find it attractive for console 
development.  There you would be more likely follow the "code the engine 
entirely in C++ and use Python only as a top-level organizational 
mechanism" approach.  If the engine is, in the large, readily understood 
and doesn't need any of the flexibility and easy experimentation of 
Python for development, and has performance as its primary objective, 
using Python to develop that engine would be... a very interesting 
choice at least :) .

Anyway, have fun, and enjoy yourself,
Mike