Thanks! Can this vectorization deal with NaN?

In [1]: np.signbit(np.nan)
Out[1]: False

In [2]: np.signbit(-np.nan)
Out[2]: True

It looks a bit like using a comparison in the float case, and I am not sure that is correct there? I think you added signbit also for integers? np.signbit.types does not actually use these (they still work by casting to float, so I am not sure if we may be open to just adding it).

@seiko2plus I have removed the integer implementations. And test cases for ±nan and ± inf have been added too!

Hi @seiko2plus I recently want to finish some of lacking SIMD operations in numpy. However, I am meeting a problem that how can I find the mapping between names in https://github.com/numpy/numpy/blob/main/numpy/core/umath.py and the names under numpy/core/src/common/simd/. I saw some functions have been implemented (e.g. fmax and fmin), but there is no a explicit mapping between them

@seiko2plus Please respond to this comment when you get a chance.

I'm so sorry for taking forever, just get confused between this pr and pr #19770.

However, I am meeting a problem that how can I find the mapping between names in https://github.com/numpy/numpy/blob/main/numpy/core/umath.py and the names under numpy/core/src/common/simd/.

The universal intrinsics are completely independent of universal functions(ufunc) which we use within the umath module. You can follow the SIMD code within dispatch-able sources *.dispatch.c.src to discover how we implement the SIMD kernels of umath's operations.

I saw some functions have been implemented (e.g. fmax and fmin), but there is no a explicit mapping between them

Sometimes for future use or required by other kernels.

Regards to fmax, fmin, we had to implement three kinds of intrinsics for each datatype based on the NaN behavior:

• npyv_max_[f32,f64] maps directly to the equivalent native instruction regardless of the NaN behavior.
• npyv_maxp_[f32,f64] used by np.fmax which precisely respects IEC 60559.
• npyv_maxn_[f32,f64] used by np.maximum for propagating NaNs

Again, I do not see any benefit in implementing a separate universal intrinsic for signbit, same case as copysign(#19770). The following code can fairly extract the signbit of both precision on all supported SIMD extensions:

npyv_shri_u32(npyv_reinterpret_u32_f32(v), 31);
npyv_shri_u64(npyv_reinterpret_u64_f64(v), 63);

@seiko2plus Should we pursue this?

@charris, no, my last comment was clear enough I guess. so it should be closed.