On Jun 17, 2009, at 11:23 PM, Stefan Behnel wrote:
>>> So a slice would be a view? Because if it was a copy, you'd need
>>> a separate
>>> memory object to back it. A view would be easiest handled by the
>>> normal
>>> memoryview(), though, right? And I find a copy much less
>>> surprising...
>>
>> Sorry, another NumPy-ism which I forgot wasn't there in core Python.
>> I'll fix the CEP at some point. Yes, slices are views and absolutely
>> have to be. Slices being natural and efficient views to work with is
>> kind of one of the main points.
>
> -1 on slices returning views for a sequence type. That is completely
> unprecedented in Python and would only lead to confusing and buggy
> code.
> What would you do to get a 'real' slice copy then? Requiring a user
> to do
>
> some_array[2:5][:]
>
> looks totally wrong to me (besides not even working if the second
> slice
> returned a view, too).
>
> This *may* make more sense for a SIMD type, but even there I
> suggest not
> using the slicing syntax for this. Make it a method call that
> returns a
> slice view.
This is what numpy does, and what makes slicing so powerful.
sage: import numpy
sage: A = numpy.zeros((2, 4))
sage: B = A[:,2:]
sage: B[1,1] = 100
sage: A
array([[ 0., 0., 0., 0.],
[ 0., 0., 0., 100.]])
> I get the impression by now that CEP 517 and CEP 518 are not
> related. They
> describe completely different types, but only the array type makes
> sense in
> the context of Cython. The SIMD type would introduce semantics that
> exist
> neither in Python nor in C.
>
> The only problem is that a SIMD data type requires Cython compiler
> support,
> otherwise, you could just go and implement it as an external type.
> If you
> see any way to implement this as an add-on rather than a compiler
> feature,
> you'll have my blessing immediately. But I do not see this becoming a
> smooth part of the language.
>
> Yes, I'm being NIMCy here, but I really don't see this fit into the
> language, sorry. I don't like dark corners in a programming
> language that
> "you don't have to care about because you are not an XYZ user".
> That's ok
> for a stdlib, but not for a language.
I see both a native list and vector type as being worthwhile
additions to the language. I also think parallelism needs to be
supported at the language level, and specifying that the vector type
may (in the future) be handled as a SIMD type is useful here.
The current buffer interface allows nice indexing, but we can't go
much further without assuming (at compile time) the semantics of
slicing, etc. In fact, we're already assuming that indexing happens
as proscribed by the buffer interface (a reasonable, but easily
violated, assumption). This new type would allow us to work with
object[:,:] without worrying about what kind of object it was--the
indexing, slicing, and eventually arithmetic would be defined as it
is for ndarrays, also opening the possibilities for CEP 518.
I'd like to say it's syntactic sugar for something, but I'm at a loss
to say what of (implying it's an actual new language feature). I
would like it to be very easy to describe (from a high level), e.g.
"It behaves just like an ndarray, but only supports a subset of
operations."
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
