I can partially answer my own questions here:
1) To avoid figuring out the type underlying npy_complex64 etc, the following
macro seems to work:
#define set_real(X, Y) _Generic((X), \
npy_cfloat: npy_csetrealf, \
npy_cdouble: npy_csetreal, \
npy_clongdouble: npy_csetreall \
)((X), (Y))
#define set_imag(X, Y) _Generic((X), \
npy_cfloat: npy_csetimagf, \
npy_cdouble: npy_csetimag, \
npy_clongdouble: npy_csetimagl \
)((X), (Y))
#define get_real(X) _Generic((X), \
npy_cfloat: npy_crealf, \
npy_cdouble: npy_creal, \
npy_clongdouble: npy_creall \
)(X)
#define get_imag(X) _Generic((X), \
npy_cfloat: npy_cimagf, \
npy_cdouble: npy_cimag, \
npy_clongdouble: npy_cimagl \
)(X)
Since we're using C++ for pytensor, overloading inline functions for get_real,
set_real, etc. would also be an option.
For 2), I realised that scalarmath.c.src already redefines the arithmetic of
complex types. I was assuming that the built in C99 operations were being used
(and if __cplusplus is defined, I guess I was assuming that the structs were
cast to C complex types).
This post suggests this gives better performance than the built in C99
operations:
https://stackoverflow.com/questions/11076924/how-to-use-cx-limited-range-on-off
Using the compiler flag they suggest could mean that numpy doesn't need to
redefine the arithmetic operators for complex numbers, although I don't know if
there is a clang equivalent, and I suppose it isn't much code saved.
_______________________________________________
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com
