FIX np.divide undefined behaviour with where in gaussian processes #24245
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Triggered by investigating #24221.
We are using code like:
result[denominator == 0]
values are undefined when using this. For CPython it seems like thenp.empty
allocated for the return value reuses a temporary array created in a previous line that computes(X[:, np.newaxis, :] - X[np.newaxis, :, :]) ** 2
so thatresult[denominator == 0]
only contains 0. For PyPy this is not the case and at one point we get 8000 a 4. rather than a 0. (don't ask me where the 4. comes from ...).A snippet to reproduce a similar behaviour:
Output with CPython (address is the same so the -999. of the
tmp
array is reused):Output with pypy (address is not the same first value is random):