[Cython] CEP1000: Native dispatch through callables
Dag Sverre Seljebotn
d.s.seljebotn at astro.uio.no
Thu Apr 19 19:01:07 CEST 2012
Nathaniel Smith <njs at pobox.com> wrote:
>On Thu, Apr 19, 2012 at 2:18 PM, Dag Sverre Seljebotn
><d.s.seljebotn at astro.uio.no> wrote:
>> On 04/19/2012 01:20 PM, Nathaniel Smith wrote:
>>> def square(x):
>>> return x * x
>>> # .specialize is an un-standardized Cython interface
>>> # square_double is an object implementing the standardized
>>> square_double = square.specialize("d->d")
>>> That'd be enough to get started, and doesn't rule out later
>>> that do automatic type selection, once we have more experience.
>> Well, I want np.sin to replace "cdef extern from 'math.h'", and then
>> seems to be needed... at least the possibility to have both "d->d"
>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...
>cython-devel mailing list
>cython-devel at python.org
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
More information about the cython-devel