Dag Sverre Seljebotn wrote: > I'll start with what I consider most important here: > >> - Should this >> """ >> Arithmetic (a + b turned into a loop on the arrays a and b) >> """ >> >> read >> >> """ >> Arithmetic (a + b returns a concatenated copy of a and b) >> """ >> ? >> > Well, that would upset all us numerical users a lot :-) > > Doing arithmetic componentwise is one of the big ideas here. If + means > concatenation you gain perhaps a convenient array type but it becomes > much, *much* less useful for numerical purposes. I can see why one would > argue against it though (not found in Python, array.array does > concatenation etc.) so this is where I can only state what I'd > personally find really useful. I feel pragmatism should win this one but > you've got purism on your side. > > PEP 3118 doesn't allow resizing buffers, which makes concatenation less > natural to me. Though we could always return a new copy... > > Anyway, say we want to make the usecases of both groups possible. Then > the choice seems clear; if we use + for addition, one can make use of > the full set +,-,/,*,** on arrays, while concatenation, being only one > operation, could be moved into "cat(arr1, arr2)" or something. Using + > for concatenation makes -,/,*,** useless...
Tuples support '+' and '*'. My immediate intuition is that an array type should behave exactly like a (mutable, but fixed-size) tuple, except where C dictates otherwise. > I'm convinced that + would be used *a lot* more for componentwise > addition than for concatenation. I agree - at least in numerics. But if you want a mathematical vector type, that's a different thing than a memory managed C array IMHO. BTW, didn't we have this discussion twice already? That shows that at least my intuition keeps clearly dictating otherwise, each time we get here. Stefan _______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
