[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] API draft for vector type



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:


[...]
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.
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).

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.

[...]

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 direction
Same 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._epsilon
How am I as user supposed to manipulate _epsilon? It should be made public.
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.

If the normal user does not need it, he won't use it :-).


Ok. I don't mind making it public

[...]

1.10 open questions (in no particular order)
============================================
1.10.1  a) use radians for all angles
         b) use degrees for all angles
Degrees, I'd say. The api should be easy to use and letting users
calculate the rad values before is not that intuitive.
I just checked: unfortunately pygame seems to be inconsistent: transform.rotate use degrees and draw.arc uses radians.

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