Re: [pygame] API draft for vector type

[Casey Duncan <casey@xxxxxxxxxxx>]

On Apr 27, 2009, at 6:16 PM, René Dudfield wrote:

> Would be nice if the vectors storage of things could be anything  
> underneath.  This would be useful to allow them to use pygame.Rect  
> or numpy.array underneath.  This means they can refer to a batch of  
> vectors, but also operate only on a single vector at a time.

+1, though there are performance vs. generality tradeoffs to be made.  
On the general side, a vector class could assume the underlying  
storage supports __getitem__, but the performance of this would  
suffer, I think too greatly. On the performance side, it could just  
have a pointer to an array of floats that it wraps with the vector  
api. I used this strategy with Lepton and the performance is great,  
but it is inflexible for the storage, and probably not very practical  
for totally general use across different storages.

> Wondering about why only 3 element vectors?  2,3, and 4 element ones  
> are common?  Is there a way to make a combined 2,3,4 type?

Most operations can assume the higher dimensions are always zero, or  
the length could just be variable. But in either case the code would  
be slower than it would strictly need to be, since many operations  
would do more work than needed or would require loops where they would  
not be required for single purpose 2D, 3D or better vectors.

> What number types are used?  eg, can you have a float vector, a long  
> vector, an int vector?  Any python number?  A uint8 ?

Seems to me like the most general number type would be a double, as it  
could comfortably support a wide range, does not generally have  
resolution issues like a 32-bit float can and performs well on modern  
hardware. It would also give consistent results compared to a python  
float, which is nice.

I'm not sure what the use-case is for ints or (python) longs, the  
latter would probably gain little by being coded in C compared to pure  
python. Even in sprite-based 2D games, I find integers to be far too  
coarse for vector math, and operations like normalize become basically  
impossible.

If you support multiple vector numeric types, than you have to  
confront a combinatorial explosion of type conversions and either  
duplicate, templatize or generalize the code in such a way that you  
trade either performance or maintainability or both.

-Casey