Stefan Behnel wrote: > Dag Sverre Seljebotn wrote: >> Stefan Behnel wrote: >>> 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. > > I understood that. The question was if the result of a compiler-generated > SIMD operation on a SIMD type should return a view or a container. My > answer was that it should return a SIMD view for consistency, but could > return a container on request, depending on the target type. So we'd > optimise away the coercion, in a way. That's more or less the same as the > optimisation that a calculation can be done in-place if you assign the > result to a participating object.
Thanks for explaining further. Sounds good! -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
