Repository navigation
Make erfa functions ufuncs instead of using custom wrappers? #6865
Description
In some of the work on distributions @eteq and I have been discussing, a bottleneck is the assumptions the current erfa wrappers make about the inputs; it would be great if those could be overridden. One possible way, which I note here mostly as a reminder, is to make all the erfa functions ufunc (or perhaps gufunc where reductions over axes take place). That way, any array can in principle override them using __array_ufunc__ and we could have Quantity helpers that take care of units. An advantage would be that broadcasting and iteration would be taken care of by the ufunc machinery (now a lot of duplicated code).
Activity
jwoillez commentedon Dec 7, 2017
The documentation for
gufunc(PyUFunc_FromFuncAndDataAndSignatureathttps://docs.scipy.org/doc/numpy-dev/reference/c-api.ufunc.html) states that the machinery only supports built-in data types. But we have to support the
eraASTROManderaLDBODYstructures (see https://github.com/liberfa/erfa/blob/master/src/erfam.h). Is the idea/solution, to split the structures into built-in components?Example: the
eraASTROM *astrominvoid eraAticq(double ri, double di, eraASTROM *astrom, double *rc, double *dc)would be expanded.mhvk commentedon Dec 7, 2017
@jwoillez - just goes to show how much I thought about it so far... I think the situation can be saved either by breaking up into built-in pieces, as you suggest; with
PyUFunc_RegisterLoopForType(which allows one to use a user type, though it still has to be defined); or by casting the structures as Object arrays (surely not the most efficient, but perhaps not horrific since the structure is quite large, so the additional indirection may not cost that much in speed).More generally, do you think this is a good idea at all? I'm slightly worried about performance so had been thinking about testing it on one of the simpler erfa functions.
jwoillez commentedon Dec 8, 2017
I take back what I said earlier. There seems to be a way to work with structured array.
See the description of
PyUFunc_RegisterLoopForDescrat https://docs.scipy.org/doc/numpy-dev/reference/c-api.ufunc.html. An example is given there: https://docs.scipy.org/doc/numpy/user/c-info.ufunc-tutorial.html#example-numpy-ufunc-with-structured-array-dtype-arguments.On the question ArrayIterator versus GUFunc I would not know. From reading the doc (https://docs.scipy.org/doc/numpy/reference/c-api.html), it feels like they are equivalent, except maybe for type casting, which is supported by
ufuncbut not needed forerfa. Inerfa, the types are already set to floats most of the time (no need to compute the earth attitude with integers).mhvk commentedon Dec 8, 2017
Ah, nice, so that would make it easier at least. My guess is also that for large arrays the ufuncs would likely be equivalent in speed to the current implementation, since they use the same iterator (assuming that cython is not that much slower than C). But for small arrays the overhead might be larger. But the possibility to override is nice...
mhvk commentedon Jul 2, 2018
implemented in #7502