Dag Sverre Seljebotn wrote:
> I'll let you and Robert go on with the syntax discussion without me.
>
> However I have my doubts on whether you'll get anywhere, I maintain that
> this is likely a matter of taste in the end, with no objectively "right"
> or "wrong" decision.
>
> Are you OK with leaving the issue to popular vote?
You mean as in the case of decorator support for Python? ;)
I think what this would mean is that all listening numerics people would
go "yes, I want a short syntax as in NumPy" and everyone else would go
"hmmm, I don't care, so I don't vote". I don't think that would give us a
meaningfull poll result.
> To recap, there's two decisions:
> a) Whether a view must be explicitly requested or is "coerced", i.e.
> whether one can do
>
> x = np.sin(x) # get view on result
>
> or has to do
>
> x = SIMD_TYPE_SPECIFIER(np.sin(x))
Right, that's open (as I replied to your other mail). I think it depends
on how easy it is to get to the container when you have the view in your
hands. If you can easily unpack the container then there's not much of a
difference, but my assumption is that it's more convenient to get the type
back that you passed in, rather than a type that might behave different.
So my vote is for transforming
x = np.sin(x) # get view on result
into
x = SIMD_TYPE_SPECIFIER(np.sin(x))
internally. We might allow an exception when x is typed as a known
container result type of the operation, i.e.
cdef array['some spec'] x = np.sin(x)
would not create an intermediate view, but write the result directly into
a newly created array. But that's an optimisation, not a requirement.
> b) SIMD view type syntax
>
> I strongly maintain that some information must be present per dimension
> -- I can post more details if you wish, but for clarity I will use
> "stridespec" as a placeholder below.
>
> Furthermore there's the question of allowing per-dimension wraparound
> disabling.
>
> Then, some options:
>
> OPTION A:
> int[::stridespec,::stridespec]
> int[0::stridespec,::stridespec] -- default stridespec, but do not
> wraparound on first dim
>
> Default stridespec possible.
>
> OPTION B:
> SomeWord[int, ::stridespec, ::stridespec]
> SomeWord[int, 0::stridespec, ::stridespec]
>
> Default stridespec possible. Looks odd to me with the type on the "first
> dimension".
>
> OPTION C:
> SomeWord[int, (stridespec, stridespec)]
> SomeWord[int, (stridespec, stridespec), (False, True)]
>
> Default stridespec not possible (unless perhaps on all strides at the
> same time: SomeWord[int])
I can't really comment on that, as I never needed this option. I do agree
that this information is required, though. Maybe keyword arguments fix
this?
SimdType[int, strides=[::stridespec,::stridespec]]
or something like that. Note that we need to smarten up the parser anyway
if we want to support templated types.
Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
