Raise not-implemented exception on numpy fallback #1201
Conversation
|
Implementation in this PR falls back by default, allows opting out. I should clarify, but I thought we agreed to raises by default, permits opt-in. |
Never mind I misread the code, it works as expected |
antonwolfy
force-pushed
the
exception_on_numpy_fallback
branch
from
9f67cf8 to
001fb25
Compare
dpnp/random/dpnp_random_state.py
Outdated
| raise OverflowError(f"Range of loc={loc} exceeds valid bounds") | ||
|
|
||
| if (scale >= max_double) and dpnp.isfinite(scale): | ||
| if (scale >= max_double) and numpy.isfinite(scale): |
There was a problem hiding this comment.
Perhaps factor out uses of numpy.isfinite into your own routine which can be modified as needed.
If scale always remains a Python or NumPy scalar, than not compute-follows-data violation occurs, but if scale can be an array, then your modular routine can be modified to apply appropriate validation function.
There was a problem hiding this comment.
Added internal functions _is_finite_scalar() and _is_finite_scalar() to dpnp_random_state.py with TODO comment inside to replace with dpnp functionality once availbale.
Previously DPNP fell back on NumPy implementation when a requested functionality isn't available and can't be provided by DPNP.
The PR is indented to raise
Non-implementedexception in that scenario by default, rather than falling back.It will be possible to keep old behavior with falling back on NumPy calls by setting a new environment variable
DPNP_RAISE_EXCEPION_ON_NUMPY_FALLBACK = 0.In all other cases, the fallback is prohibited and lead to the exception.