Stefan Behnel wrote:
> 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.
I'm afraid my example was misleading; I meant np.sin to be a plain,
object-taking (and thus non-SIMD) function. A clearer example is
x = f()
vs.
x = SIMD_TYPE_SPECIFIER(f())
however it hides how inconvenient it would be to use NumPy in this
situation. Take "np.dot" -- it takes two array arguments, and return the
linear algebra product (meaning non-SIMD) operations. Then it is
x = np.dot(y, z)
vs.
x = SIMD_TYPE_SPECIFIER(np.dot(y, z))
My vote is for the former though, just to save keystrokes, as that's
something I do really often. But the latter should be supported as well
and be the "written-out" version.
I don't see that this is much different from e.g. coercing to C types;
constructing a new view is simply how Python objects are coerced to
SIMD_TYPE_SPECIFIER.
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
