-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
TST/MAINT: signal.symiirorder2: r, omega, precision are floats; use default dtypes #22783
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
rsq = r * r | ||
a2 = 2 * r * np.cos(omega) | ||
a2 = 2 * r * math.cos(omega) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Despite what the docs say, I wouldn't be surprised if historic usage allows 0D arrays or np.float64
s. This part of the codebase is straight from the multipack era. Let's see if tests complain.
I've slightly extended the scope of this PR; see updated initial post |
@pytest.mark.parametrize('dtyp', ['float32', 'float64']) | ||
def test_symiir2_values(self, dtyp, xp): | ||
rng = np.random.RandomState(1234) | ||
s = rng.uniform(size=16).astype(dtyp) | ||
s = xp.asarray(s) | ||
dtyp = getattr(xp, dtyp) | ||
|
||
# cupy returns f64 for f32 inputs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one is a bit funny: I'm pretty sure CuPy's version was made to follow SciPy's, and now we're adjusting SciPy's to match CuPy's :-).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Changes look reasonable, the resulting code is cleaner, and the test coverage has expanded. Looks like wins all around. Thanks Guido!
scipy.signal.symiirorder2
are floats, as per the documentation.This PR undoes an improper wrapping in
xp.asarray
in the test.This fixes a regression vs. array-api-strict git tip, which has started crashing on
__mul__
and other ops vs. np.float64 types, on the linea2 = 2 * r * np.cos(omega)
because r was anarray_api_strict.Array
.symiirorder1
andsymiirorder2
now return float32 when fed with int inputs, accordingly to the generalxp_promote
policy.