On Tue, Apr 28, 2009 at 2:52 PM, Casey Duncan <ca...@pandora.com> 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. > > 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 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.
