* 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]

…`. (scipy#20401)

[doc only]

[doc only]

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]

* 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]

…ubset

* 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.

…20264

[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

…0643)"

This reverts commit ee6203d.

* more import cleanups after backport activity
to make the linter happy

[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`

* This is an empty commit to test the wheel
building in the above PR.

[wheel build]

* Changes needed to get MacOS ARM wheels building
again, based on debug work on my fork.

[wheel build]

* Need to pin `pythran` version in a CI job
because of a recent new release.

[wheel build]

* Increase the Cirrus CI Linux aarch64
job timeout to 72 minutes; it timed
out twice in a row via manual restarts.

…o' (scipy#20592)

…) [wheel build]

* BUG: fix zipf.pmf for integer k

* ENH: increase range for zipfian.pmf for integer k

---------

Co-authored-by: Tyler Reddy <tyler.je.reddy@gmail.com>

[wheel build]

* Update the SciPy `1.13.1` release notes following substantial
backport activity.

[skip cirrus]