Dag Sverre Seljebotn wrote:
> The problem here is that the support must be built into the language,
> user-defined types won't do the trick (unless you have meta-programming
> capabilities on the level of LISP).
I'm not arguing that the type shouldn't be a builtin. It's just a
difference if you require new syntax for a type or if you special case a
type in the compiler.
> Anyway, thanks for clarifying the terms. So the question turns into: Is
> it possible to add a *vector* type to Cython? Or is that pulling it too
> far? (Choice of syntax aside.)
I'm for having both. The vector type could become a subtype of an array
that overrides the numeric operations (although I wouldn't care too much if
that's too hard to implement).
We discussed the templating syntax a while ago. Even if that isn't there
yet, that doesn't mean we can't use its syntax.
from cython cimport Vector
cdef Vector[int] some_vector
would be the same as the equivalent "int[:]" array, except for arithmetic.
>> The examples you gave used "int" as a base type, simply because you were
>> thinking of numeric use cases. What about an array of pointers or structs?
>> What should adding two of those do?
>>
> Pointers: C semantics. I.e. you can add a pointer and an int array
> together to get new pointers, and so on. People are already doing
> exactly this with NumPy arrays (casting the pointers to integers and
> back though).
I actually meant adding two arrays of pointers.
> Structs: Ideally (for numericans) the arithmetic done field-wise.
I would expect that when I have a /vector/ of structs (and yes, that would
be a totally cool feature). An /array/ of structs should concatenate instead.
Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
