#595 adds a workaround for #593's original CuPy issue - cupy/cupy#9143. The workaround includes using where instead of nan_to_num in specific compute functions.
Using where is okay for numerical backends, but it is an issue for the SymPy backend. The shim _lib.where function is not a generic replacement for np.where, instead, it works only for this particular case (return the second argument (first value) as we know that the "normal" values are in the second argument and the "exceptional" ones are in the third argument). Therefore, this occurrence of where is safe to use, but should not be used out of "context" / as a drop-in replacement for np.where. It would be nice to remove the occurrences of where from compute functions (revert #595) once the CuPy issue is fixed (so that the compute functions stay generic).
#595 adds a workaround for #593's original CuPy issue - cupy/cupy#9143. The workaround includes using
whereinstead ofnan_to_numin specific compute functions.Using
whereis okay for numerical backends, but it is an issue for the SymPy backend. The shim_lib.wherefunction is not a generic replacement fornp.where, instead, it works only for this particular case (return the second argument (first value) as we know that the "normal" values are in the second argument and the "exceptional" ones are in the third argument). Therefore, this occurrence ofwhereis safe to use, but should not be used out of "context" / as a drop-in replacement fornp.where. It would be nice to remove the occurrences ofwherefrom compute functions (revert #595) once the CuPy issue is fixed (so that the compute functions stay generic).