Dag Sverre Seljebotn wrote:
>> Just for clarification (I looked up your earlier post but didn't find
>> it): Would the non-SIMD view type (your 2)) support more than one
>> dimension? How would +, +=, append semantics be defined if there's more
>> than one dimension?
>
> Or...I suppose +, +=, append are only for the array, and the non-SIMD
> view can only do item indexing/slicing and has no arithmetic operators
> at all?
That's also an option. However, given that a view can consist of any
subset of items in the underlying container, it would be nice to support
it at least for one dimension, so that you could do (for example)
new_array = view_a[::2] + view_b[1::2]
efficiently (i.e. sort the odd elements behind the even ones).
I'm also not sure what type such a view should return when it needs to
create a new container. It cannot always be smart enough to create the
correct container type (e.g. for a view on a buffer). That might count as
an argument for not allowing any arithmetic at all. OTOH, there's a
similar case in PEP 3132 (extended iterable unpacking), and the decision
was to always return a list for the starred variable. If you really
require something different than a plain array, you can do the less
efficient
new_array = EXPECTED_TYPE(view_a[::2]) + view_b[1::2]
assuming that the EXPECTED_TYPE supports this.
On a similar note, should adding views return a plain container, or should
the result get wrapped in the view type? I think that's what would happen
for SIMD operations, so I guess it would be right also for the typed
memory view to transform this:
result = view_a[::2] + view_b[1::2]
into
result = NEW_VIEW(NEW_ARRAY(view_a[::2] CONCAT view_b[1::2]))
But I think we're getting back into details before their time here. I'm
fine with disallowing this completely at the beginning, and to come up
with sensible semantics when we see what common use cases are.
Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
