Skip to content

Revisit need for our own ufunc type resolver #105

@mhvk

Description

@mhvk

Currently, we override the standard numpy type resolver, because, as seen in this extract:

pyerfa/erfa/ufunc.c.templ

Lines 535 to 545 in e33ee55

* We provide our own type resolver, since the default one,
* PyUFunc_DefaultTypeResolver from
* numpy/core/src/umath/ufunc_type_resolution.c, has problems:
* 1. It only looks for userloops if any of the operands have a user
* type, which does not work if the inputs are normal and no explicit
* output is given (see https://github.com/numpy/numpy/issues/11109).
* 2. It only allows "safe" casting of inputs, which annoyingly prevents
* passing in a python int for int32 input.
* The resolver below solves both, and speeds up the process by
* explicitly assuming that a ufunc has only one function built in,
* either a regular one or a userloop (for structured dtype).

However, as noted in numpy/numpy#11109 (comment), things should now work for us. So, this is a reminder to try removing our work-around.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions