[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