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. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
