Add wright_bessel function to special

[steppi]

This PR adds the wright_bessel function to special.

I've also made updates to cupy/_core/include/cupy/special/ not strictly necessary for this PR because it's easier just to copy over the working code from SciPy rather than trying to make the minimal set of changes needed to get things working over here.

I also have a quick question. I saw at, https://docs.cupy.dev/en/stable/upgrade.html, that the minimum supported C++ version is C++11 but there's a plan in the near future to upgrade to C++17. Do you have a rough timeline for the upgrade, or is there anything @izaid and I could do to help accelerate the process? We have things we've worked on in SciPy which we won't be able to bring over to CuPy until C++14 and C++17 features can be used here.

[takagi]

/test mini

[takagi]

Do you have a rough timeline for the upgrade

We have already had C++ 17 support in v14 on development, so please do not worry about having C++14 and C++17 features. #8203

cupy/install/cupy_builder/_compiler.py

Lines 205 to 206 in ba8def1

	# Bumping C++ standard from C++14 to C++17 for "if constexpr"
	postargs += ['--std=c++17',

[steppi]

I'll investigate the test failures.

We have already had C++ 17 support in v14 on development, so please do not worry about having C++14 and C++17 features. #8203

That's good to hear, but we're still noticing some C++14 and C++17 features not working. std::decay_t from <type_traits> is not working for instance.

/home/birbir/.virtualenvs/scipy-dev2/lib/python3.12/site-packages/cupy/cuda/compiler.py:696: in compile
    raise CompileException(log, self.src, self.name, options,
E   cupy.cuda.compiler.CompileException: /home/birbir/scipy/build-install/lib/python3.12/site-packages/scipy/special/special/tools.h(15): error: namespace "std" has no member "decay_t"
E         using generator_result_t = std::decay_t<std::invoke_result_t<Generator>>;

We've also seen std::enable_if_t and std::is_floating_point_v not working. These are just helper types/templates and their absence can be worked around, but it gave me the impression that only C++11 features could be used, since they are enabled with guards like this.

#if _LIBCUDACXX_STD_VER > 11
template <class _Tp> using decay_t = typename decay<_Tp>::type;
#endif

https://github.com/cupy/cccl/blob/79ed0e96e35112d171e43f13fa7f324eff7f3de0/libcudacxx/include/cuda/std/detail/libcxx/include/__type_traits/decay.h#L73-L75

Or is the _LIBCUDACXX_STD_VER different from the C++ version?

[leofang]

@steppi could you try to edit this file locally?
https://github.com/cupy/cupy/blob/main/cupy/_core/include/cupy/cuda_workaround.h
or just edit your CUDA C++ strings/files to do the same trick (importing cuda::std:: counterparts into std::)?

What happens is that there's no standard library support in NVRTC, so we've been gradually shifting toward relying on CCCL (in particular libcudacxx) to provide the std:: library support, instead of keeping homegrown std hacks around. However we don't want to include all libcudacxx headers at once because it'd slow down the JIT compilation considerably, we only include what's most commonly used.

[steppi]

Thanks @leofang

or just edit your CUDA C++ strings/files to do the same trick (importing cuda::std:: counterparts into std::)?

We're doing something very similar, but instead of importing we're wrapping cuda::std counterparts and placing the wrappers in std:::

cupy/cupy/_core/include/cupy/special/config.h

Lines 69 to 71 in ce047e3

	namespace std {
	SPECFUN_HOST_DEVICE inline double abs(double num) { return cuda::std::abs(num); }

So it's still not clear why decay_t etc. doesn't work, but for now I'm just going to avoid things like that which aren't working. In SciPy I'm replacing the use of decay_t with this:

using generator_result_t = typename std::decay<typename std::invoke_result<Generator>::type>::type;

https://github.com/scipy/scipy/blob/c009b4d66fce22c646e18fcf025c0cf619dec531/scipy/special/special/tools.h#L15

This doesn't impact this PR, decay_t is currently being used in hyp2f1, which isn't quite ready to PR here yet.

[leofang]

I can no longer see this line

using generator_result_t = std::decay_t<std::invoke_result_t<Generator>>;

in tools.h and how it's used. Generally you want to include <cupy/cuda_workaround.h> or do

#include <cuda/std/type_traits>
namespace std {
  using cuda::std::decay_t;
};

before using std::decay_t. Ping me if similar errors arise next time... :)

[steppi]

Thanks @leofang. I'm removing the use of decay_t in SciPy. I'll ping you if this happens with something that isn't easily worked around.

in tools.h and how it's used. Generally you want to include <cupy/cuda_workaround.h> or do

Just want to comment on this too. Right now we have a header config.h which functions like cuda_workaround.h. @izaid and I are trying to make our special function library independent of any particular array library, so are trying to avoid including headers from CuPy.

So far everything seems to be working, except for these helper templates/types like decay_t. I'm not sure if the following is something we need to worry about:

cupy/cupy/cuda/jitify.pyx

Lines 179 to 183 in ba8def1

	# WAR
	# Jitify's type_traits is problematic with recent CCCL. Here, we populate
	# the cache with a dummy header source, so that Jitify's version wouldn't
	# be used. cupy/cuda_workaround.h is the real place importing type_traits
	# (from libcudacxx).

[takagi]

I'm not sure if the following is something we need to worry about:

I suppose it's yes.

[takagi]

/test mini

[steppi]

Oh good, all tests passed. It looks like it may have been the missing __host__ __device__s that were causing the test failures, since that was the only thing I changed.

I suppose it's yes.

I see. I guess that could be the reason it was some features from type_traits specifically that weren't working. @izaid, I know you don't have much bandwidth, but just pinging you to make you aware of the potential Jitify issue with type_traits, and CuPy's use of cuda_workaround.h.

Thanks @takagi, I'll merge main now.