Hi again. Marcus von Appen wrote:
On, Tue Apr 28, 2009, Lorenz Quack wrote: [...]Marcus von Appen wrote:On, Mon Apr 27, 2009, Lorenz Quack wrote:[...]seems like you already have this worked out in your head. but module-level batch functions sound like a good idea (even though I don't know how to actually implement that, yet).Daniel Jo <ostsol@xxxxxxxxx>:Vector classes work well for convenience and code readability, but from a performance standpoint they aren't very useful.Right, that's what batch operations are suitable for. Lorenz' proposal mentions e.g. creating vectors from sequence types. If we add a set of helper functions to the module (pygame.math.do_stuff (many_vectors)), we can easily get around that issue. This only requires us to keep the internally optimised methods separated well enough.Here's a short snippet: static PyMethodDef _audio_methods[] = { { "init", (PyCFunction) _sdl_audioinit, METH_NOARGS, DOC_AUDIO_INIT }, .... }; static PyObject* _sdl_audioinit (PyObject *self) { /* self resolves to the module, usually */ ... } PyMODINIT_FUNC initaudio (void) { PyObject *mod = Py_InitModule3 ("audio", _audio_methods, DOC_AUDIO); ... } It's fairly easy as you see. Instead of binding methods to the object, you bind them to the module.
thanks for the snippet!even though I wasn't referring to the module-level functions when I said I don't know how to implement it but the batch processing itself. But I have to admit I didn't express myself very clear, sorry. Anyway I think I also figured the batch processing out by now. You just do the normal C stuff in an additional for loop and thus save the overhead of calling python functions several times. of course you have to do appropriate type checks and so forth.
[...]
Rene Dudfield <renesd@xxxxxxxxx>What number types are used? eg, can you have a float vector, a long vector, an int vector? Any python number? A uint8 ?I'd vote for two major types here: long/int and float. Depending on what the passed values are. If we argue to use 'any python number', we'll have to refer to the number protocol anytime an arithmetic function occurs. This makes anything painfully slow. If the passed values are all int or long, the vector might be handled as long/int vector with matching optimised functions. if the numbers are all float, other matching optimised functions might be used. However, those considerations should be handled later on. To implement such hooks is a bit complex due to the behaviour specification. For now I'd vote for using either float (double) as internal representation (for being exact enough) and/or two vector types: FVector (floating point) LVector (long/int)+1 on floating point vectors (though using double precision). +0 on int/long. I would like to see some use cases of int vectors.-1 on the names. I think floating point is the thing users normally want so I would call that Vector, Vector3d or whatever. The int vector is a special case and therefore wait in second line with a name like IVector (in python3 we only have int so I would go for the "I" instead of the "L")Those were just examples. Personally I'd favour Vector and IntVector (IVector sounds like an interface to me). IntVector however is something to be considered later on.
I agree. [...]
well. I thought you rarely want to twiddle with this so I marked it private. I thought the normal user doesn't want to be bothered with this and the pro can access it.1.6.2.1 a) v.lengthSquared -> a b) v.length2 -> a # gets the squared length of the vector. same as v.dot(v) or v * v 1.6.2.1 a) v.lengthSquared = a b) v.length2 = a # sets the squared length of the vector. preserving its directionSame as above.1.7 comparison operations ========================= 1.7.0 the "==" and "!=" and "bool" operater compare the differences against the attribute v._epsilon. this way the user can adjust the accuracy. 1.7.1.1 v == s -> bool # true if all component differ at most by v._epsilonHow am I as user supposed to manipulate _epsilon? It should be made public.If the normal user does not need it, he won't use it :-).
Ok. I don't mind making it public [...]
I just checked: unfortunately pygame seems to be inconsistent: transform.rotate use degrees and draw.arc uses radians.1.10 open questions (in no particular order) ============================================ 1.10.1 a) use radians for all angles b) use degrees for all anglesDegrees, I'd say. The api should be easy to use and letting users calculate the rad values before is not that intuitive.Which is a problem to get solved. Thus we should stick to degrees.
I guess this is as so often a trade-off between performance and usability. but since the conversion is fast as you point out in a different email I would also go with usability and use degrees.
//Lorenz