Nathaniel Smith <[email protected]> wrote:
>On Thu, Apr 19, 2012 at 2:18 PM, Dag Sverre Seljebotn ><[email protected]> wrote: >> On 04/19/2012 01:20 PM, Nathaniel Smith wrote: >>> @cython.inline >>> def square(x): >>> return x * x >>> >>> # .specialize is an un-standardized Cython interface >>> # square_double is an object implementing the standardized >C-callable >>> interface >>> square_double = square.specialize("d->d") >>> scipy.integrate.quad(square_double) >>> >>> That'd be enough to get started, and doesn't rule out later >extensions >>> that do automatic type selection, once we have more experience. >> >> >> Well, I want np.sin to replace "cdef extern from 'math.h'", and then >this >> seems to be needed... at least the possibility to have both "d->d" >and >> "O->O". > >Except, the C function implementing np.sin on doubles actually has a >signature that's something like "&&t&i&i&t->" >(PyUFuncGenericFunction), not "d->d"... so maybe this is a good >example to work through! It isn't at all obvious to me how this should >be made to work in any of these proposals. > >(Isn't "O->O" just obj->ob_type->tp_call in any case?) I just touched on this on the NumPy list -- the NumPy ufunc object could support the CEP in an optional way (each instance may, but doesn't have to), and then one could plug in fast scalar versions on a case by case basis, mainly using them as a namespace mechanism rather than reusing any implementation. So the C signature of the current implementation is irrelevant. I think you are right about the object case. But there is still float/double/longdouble...with ufuncs a possible target it seems a good idea in general to support multiple specializations. Though I admit that with scalars, double-only gets one pretty far. np.add(1, 2) is a rather contrived example... Dag > >-- Nathaniel >_______________________________________________ >cython-devel mailing list >[email protected] >http://mail.python.org/mailman/listinfo/cython-devel -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. _______________________________________________ cython-devel mailing list [email protected] http://mail.python.org/mailman/listinfo/cython-devel
