Stefan Behnel wrote: > Dag Sverre Seljebotn wrote: > >> 5) But again, the numerical stuff has happened as a byproduct, I realize >> that neither you nor Robert need it, and that Cython's real goal lies >> elsewhere >> > > It's less of a question of "who needs it", since there would be different > types of use cases for an array and vector type. This is about language > design, so the question is: what would users expect? > Thanks again for supplying your thoughts in this thread.
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). So it's also a question of whether one can use Cython at all, or must use Fortran or C++ (the sad thing is that a language as horrible as Fortran will perhaps never be decently replaced, because all other languages consider math vectors a too special usecase.) 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.) > When I see a C array, I think of a memory block with a sequence of > identically typed items. I also think of a Python tuple because that > behaves very similar. I totally do not think of a math vector, because that > is a very (very!) special use case. > Hmm. One can go with two different conclusions though a) You're ok with componentwise, but only given a different syntax b) Math vectors is too special a usecase to warrant native Cython support Resolving this is my primary interest here, and we can deal with syntax later. > 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). Structs: Ideally (for numericans) the arithmetic done field-wise. If you have a pointer in a struct it won't be allowed (unless, perhaps, one of the operands is another struct type with identical fields except that any pointer fields have been replaced with int fields. Yes, such things could be useful!) But really I'm happy even if structs are dropped from this. >> - There's always compiler directives >> > > ;) I actually thought about putting a mention of this with a big fat NO > into my last mail but then just stopped waiting for someone else to bring > this up. > Well, but in reality, the substantial amount of numerical users would not consider putting it to anything but componentwise. Just consider it a nicer alternative to an outright fork NumCython :-) (Rest easy, I will not fork.) Dag Sverre _______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
