You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Say you make an out of the DATA_SAMPLE in test_spectrum.py. Make a copy of it, a deep copy if you like. Call the first one s0 and the second s1. == will return True. Now get a value x with x=s0[500]. Turn right around and replace it with itself with s0[500] = x. Now == between s0 and s1 will return False. This is because somewhere in there we introduced a roughly 5e-17 difference into the original and the restored values of s0[500].
If there were a property of Signal that was a tolerance, then instead of calling np.array_equal for the range and domain, it could call np.allclose with that tolerance. The tolerance defaults to exactly 0.0, so if you don't set the tolerance to something else, the behavior is compatible with today's behavior. (It bears investigation as to whether np.allclose is significantly slower than np.array_equal when the tolerance is 0.0)
Ideally the tolerance value could be set in some sort of with block, with automatic cleanup so you don't need to remember to restore the prior value. But I'm not an experienced-enough designer to suggest a code example for that.
The text was updated successfully, but these errors were encountered:
Say you make an out of the DATA_SAMPLE in test_spectrum.py. Make a copy of it, a deep copy if you like. Call the first one s0 and the second s1. == will return True. Now get a value x with x=s0[500]. Turn right around and replace it with itself with s0[500] = x. Now == between s0 and s1 will return False. This is because somewhere in there we introduced a roughly 5e-17 difference into the original and the restored values of s0[500].
If there were a property of Signal that was a tolerance, then instead of calling np.array_equal for the range and domain, it could call np.allclose with that tolerance. The tolerance defaults to exactly 0.0, so if you don't set the tolerance to something else, the behavior is compatible with today's behavior. (It bears investigation as to whether np.allclose is significantly slower than np.array_equal when the tolerance is 0.0)
Ideally the tolerance value could be set in some sort of with block, with automatic cleanup so you don't need to remember to restore the prior value. But I'm not an experienced-enough designer to suggest a code example for that.
The text was updated successfully, but these errors were encountered: