MAINT: backports/prep for 1.13.1 #20632
Conversation
* Fixes scipygh-20300 by syncing `pocketfft` again, this time to completely disable `aligned_alloc`; see scipy/pocketfft#3 for details, but in short our more conservative shim was not sufficient for `conda-forge`, so let's just do the same thing NumPy did... [skip cirrus] [skip circle]
This was reported to cause test failures under windows + MKL in conda-forge cf scipy#20471
A slight tolerance violation was reported on conda-forge in scipy#20472
A small tolerance violation reported on conda-forge in scipy#20472
An exact equality was reported as flaky on conda-forge in scipy#20472 The tolerance violations are of the order of fp noise (< 2e-16), and I don't think that pickling/unpickling guarantees bit-to-bit compatibility. In principle, this may invoke recalculations and those may be subject to fp noise. So I think it's OK to only require allclose(atol=eps) instead of exact equality.
tol violation observed on conda-forge on win+blis; suggested in scipy#20474 (comment)
f2py check was just too strict; LAPACK docs indicate that for N=1, lwork>=1 is acceptable: * LWORK (input) INTEGER * The dimension of the array WORK. * If N <= 1, LWORK must be at least 1. * If JOBZ = 'N' and N > 1, LWORK must be at least 2*N+1. * If JOBZ = 'V' and N > 1, LWORK must be at least * 1 + 6*N + 2*N**2. https://www.netlib.org/lapack/explore-3.1.1-html/ssyevd.f.html closes scipygh-20512
Co-authored-by: Ralf Gommers <ralf.gommers@gmail.com>
…ith an infinite weight (scipy#20573) * Fix exact rotations at 180 deg, improve near 180 deg Comments * Tests for exact near 180 deg rotations * Fix tests * Code review updates --------- Co-authored-by: Scott Shambaugh <scottshambaugh@users.noreply.github.com>
* Apply "old version" of the patch provided at scipygh-20527
* Update the SciPy `1.13.1` release notes following a series of backports. [skip cirrus]
tylerjereddy
requested review from
larsoner,
rgommers,
person142,
steppi,
peterbell10,
perimosocordiae,
andyfaff and
ev-br
as code owners
lucascolley
removed
scipy.optimize
scipy.interpolate
scipy._lib
scipy.spatial
Documentation
* Deals with the `spatial` part of scipygh-20623 (`Voronoi` was also affected beyond the originally-reported `Delaunay` segfault). * Both classes are documented to accept arrays with two dimensions only, so raise a `ValueError` in cases with other dimensions to avoid the segfault. * Other potential points of confusion here are the differences between arrays with two dimensions and two dimensional arrays that represent generators with more than two dimensions via the number of columns, but this is just how things are for most array programming languages of course. Also, the docs don't explicitly say array-like for the generators I don't think, but this patch only worked if I placed it after the coercion to array type. [skip circle] [skip ci] [ci skip]
|
I added the backport Ralf suggested and the other That said, I'm skipping the CI for now because it is known to fail per the TODO list in the original comment above. I'll try to chip away at that as time permits. |
|
@steppi @czgdp1807 @dschmitz89 what do you think about applying the patch below (similar to the one suggested at: #20208 (comment)) to resolve the first part of #20576 on the release branch here? There's an explanation there about why I'm hesitant to backport gh-20393 -- do you agree with my hesitation? --- a/scipy/stats/_continuous_distns.py
+++ b/scipy/stats/_continuous_distns.py
@@ -692,12 +692,10 @@ class beta_gen(rv_continuous):
return _boost._beta_sf(x, a, b)
def _isf(self, x, a, b):
- with np.errstate(over='ignore'): # see gh-17432
- return _boost._beta_isf(x, a, b)
+ return sc.betaincinv(a, b, 1 - x)
def _ppf(self, q, a, b):
- with np.errstate(over='ignore'): # see gh-17432
- return _boost._beta_ppf(q, a, b)
+ return sc.betaincinv(a, b, q)
def _stats(self, a, b):
return (
diff --git a/scipy/stats/tests/test_distributions.py b/scipy/stats/tests/test_distributions.py
index 6d91bb8a6..de26dc3d8 100644
--- a/scipy/stats/tests/test_distributions.py
+++ b/scipy/stats/tests/test_distributions.py
@@ -4454,7 +4454,7 @@ class TestBeta:
assert_equal(stats.beta.pdf(1, a, b), 5)
assert_equal(stats.beta.pdf(1-1e-310, a, b), 5)
- @pytest.mark.xfail(IS_PYPY, reason="Does not convert boost warning")
+ @pytest.mark.xfail(reason="Does not warn on special codepath")
def test_boost_eval_issue_14606(self):
q, a, b = 0.995, 1.0e11, 1.0e13
with pytest.warns(RuntimeWarning):I was able to confirm failures with |
|
As for the second blocker in gh-20576, the --- a/scipy/linalg/_testutils.py
+++ b/scipy/linalg/_testutils.py
@@ -12,8 +12,6 @@ class _FakeMatrix2:
self._data = data
def __array__(self, dtype=None, copy=None):
- if copy:
- return self._data.copy()
return self._datathat seems like a pretty likely reason to deviate from |
For the inverse survival function |
* MAINT: stats: update boost to fix improve `skewnorm.ppf`
…d tests (scipy#20444) * test 1d input to sparse. Add FutureWarnings and ValueErrors * remove matrix changes. Let them create 2D * correct imports * rebase on main and update to support 1D CSR input
…oords) (scipy#20687) * test and then fix duplicates for CSR/CSC creation from (data,coords) * remove has_canonical_format check when summing duplicates.
[lint only]
Showed up as a linting error in an unrelated PR for me: ``` scipy/interpolate/_interpolate.py:918:30: UP032 [*] Use f-string instead of `format` call scipy/interpolate/_interpolate.py:1972:30: UP032 [*] Use f-string instead of `format` call ``` This should not happen; the old code is fine, so this check needs to be silenced or fixed separately. Similar to scipygh-20601. [skip ci]
* Fixes scipygh-19423 * Add a few more `case` statements to account for the (i.e., Windows) data types that don't have a fixed width, and add a regression test. [skip circle] [skip cirrus]
* attempt to deal with scipygh-20576
* some minor import fixes following a large series of backports
* more import cleanups after backport activity to make the linter happy
|
I've added substantially more backports and a few manual shims--we're back at parity with merged backport-labeled PRs. Let's see where the regular CI lands. I did have to revert and unlabel one PR (gh-20643) based on local testing with clang-16 on Mac, but the rest made it in, so far. I expanded the TODO list above based on known CI failure in Edit: between gh-20727 and gh-20533, I suspect we'll be able to get the regular CI passing today. |
[skip circle]
* We're seeing CI failures related to an undesirable bump to Python `3.12` in this job, when the intention was clearly to respect the Python version specific in the GHA matrix. I didn't check too closely why exactly it suddenly started happening, but some packages weren't ready for `3.12` yet on this job (`scikit-umfpack` in particular) and I don't see too much harm in adding an extra pin to respect the intention for the Python version.
* attempt to fix `M1 test - openblas` MacOS ARM CI job based on some `gfortran` shims applied to a similar job on `main`
We're about 3.5 weeks from the planned branching for SciPy
1.14.x. Since1.13.0was a bit rushed to support NumPy 2.x, and indeed I made a few oversights for backporting, it may make sense to at least assess how much work it would be to deliver1.13.1. I've cleaned up the backport labels a bit too, since there were almost 50 of them. Many were things I could have backported to1.12.x, but I think that would stretch me (and reviewers/support) too thin at this point.Backports included here (so far):
root(method="lm"). #20401spherical_inforn=0andz=0#20527 (danger: I applied the patch manually to the old version of thespecialcode; I did backport the new test though, and it did fail before/pass after my manual application of a slightly different patch){minimum, maximum}_filter#20653__array__(copy=True)#20533Backports already merged to the release branch:
TODO:
mainat time of writing)doc/source/.jupyterlite.doit.dbisn't gitignored on this branch/PR when I do the doc build (which otherwise passes at the time of writing) locallyUP031 Use format specifiers ...maybe?