[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] API draft for vector type
Hi,
thanks for the feedback and suggestions.
That said, I just realized that I never really introduced myself. So here it goes:
I'm a physics student from germany. I took some programming classes of
questionable quality in school. I really started of with C++ in 2003 and maybe
a year and a half later with python and once I got over the fact that
whitespaces matter it blew my mind!
Now I'm working on my final thesis (german: Diplomarbeit) and teach a beginners
course on C++. That and a few other activities take quite some of my time but
everything else is dedicated to bringing vector types to pygame =)
But don't think I jumped ship if I don't respond instantly. I'm just occupied
with other affairs.
so enough of that. let's get down to business.
René Dudfield wrote:
On Tue, Apr 28, 2009 at 2:52 PM, Casey Duncan <casey@xxxxxxxxxxx
<mailto: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.
+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.
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.
I'm not sure I understand what you#re discussing here. Are you suggesting,
that one should be able to store any python object in the vector components?
For now I only considered numbers either double or int/long.
If I understood you correctly, what would be a use case of a vector class
holding arbitrary objects? Are you thinking in the lines of something like this:
# create in this case a 5-dimensional vector with obj positions
positions = Vector([(1,2,3), (2,3,4), (3,4,5), (4,5,6), (7,8,9)])
# create velocities for each object
velocities = Vector([(2,0,0), (0,3,1), (0,1,0), (-5,0,.5), (1,1,1)])
for timeslice in game.tick():
positions += timeslice * velocities
...this is interesting. As I said, until now I only considered "normal" math
vectors. But as you already pointed out there would definitely be a speed penalty.
Wondering about why only 3 element vectors? 2,3, and 4 element
ones are common?
Yea, 2 and 4 dimensions shouldn't be a problem. I only proposed a API for 3
dimensions because it's usually the richest. for example you don't have a
cross-product in 4 dimensions. and I figured that if I wrote the whole thing
for 2 and 4 dims as well it would have become a bit confusing. but fear not 2
and 4 dimensions are on the list :)
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.
Exactly what Casey wrote.
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
Yeah, indeed. Old numeric used to auto-generate most of its code for
different types. Also there is vectypes written in python that
generates it's code for all of the different types (
http://code.google.com/p/vectypes/ ).
You want to use ints for precision I guess... and other use cases too.
eg, using 8bit uints can mean massive memory savings (a vector can fit
in one word)... and you can also use less instructions to process a vector.
I think double are a must. all other can be argued about. I would be interested
in some use cases for int vectors. I currently cant think of any. And the
memory argument, well I don't like saying that you should waste memory because
everybody has enough but I think python focuses on simplicity and generality
more than on being conservative with memory usage. So I'm -1 on supporting int8
or anything of the sort. If someone knows of use cases for int vectors that's
ok but then I would suggest using signed long int and only that.
yours
//Lorenz