On Tue, Apr 28, 2009 at 2:52 PM, Casey Duncan
<casey@xxxxxxxxxxx> wrote:
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.
ah, that's an interesting point. We could have a few special cases for giving a buffer to use. Then as it's written in C, there will only be one pointer indirection.
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