internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: scipy/scipy

Issue:
scipy.UnivariateSpline smoothing condition documentation inaccuracy
The UnivariateSpline documentation says that the smoothing condition is
```
sum((w[i] * (y[i]-spl(x[i])))**2, axis=0) <= s
```

The actual check according to https://github.com/scipy/scipy/blob/2526df72e5d4ca8bad6e2f4b3cbdfbc33e805865/scipy/interpolate/fitpack/fpcurf.f: (First time I had to read Fortran ...)
```
54: acc = tol*s
[...]
169: fpms = fp - s
170: if(abs(fpms).lt.acc) go to 440
```

https://github.com/scipy/scipy/blob/2526df72e5d4ca8bad6e2f4b3cbdfbc33e805865/scipy/interpolate/src/fitpack.pyf#L270:
```
tol = 0.001
```

So the actual smoothing condition is
```
abs(sum((w[i] * (y[i]-spl(x[i])))**2, axis=0) - s) < 0.001 * s
```
Maybe keep the current one and add the one above with a note saying "because of numerical issues the actual check is ..."?

### Scipy/Numpy/Python version information:
```
('0.18.1', '1.12.1', sys.version_info(major=2, minor=7, micro=13, releaselevel='final', serial=0))
```




Discussion:

Resolving patch:
diff --git a/scipy/interpolate/_fitpack2.py b/scipy/interpolate/_fitpack2.py
--- a/scipy/interpolate/_fitpack2.py
+++ b/scipy/interpolate/_fitpack2.py
@@ -97,6 +97,10 @@ class UnivariateSpline:
 
             sum((w[i] * (y[i]-spl(x[i])))**2, axis=0) <= s
 
+        However, because of numerical issues, the actual condition is::
+
+            abs(sum((w[i] * (y[i]-spl(x[i])))**2, axis=0) - s) < 0.001 * s
+
         If `s` is None, `s` will be set as `len(w)` for a smoothing spline
         that uses all data points.
         If 0, spline will interpolate through all data points. This is


Test patch:
Repository: scipy/scipy

Issue:
BUG:  't_span' is illustrated as 2-tuple of floats in scipy‘s documention, but which is always defined as  array_like in examples
### Describe your issue.

https://docs.scipy.org/doc/scipy/reference/generated/scipy.integrate.solve_ivp.html#scipy.integrate.solve_ivp

We can notice that 't_span' is illustrated as 2-tuple of floats in scipy‘s documention.

> **t_span: _2-tuple of floats_**
> Interval of integration (t0, tf). The solver starts with t=t0 and integrates until it reaches t=tf.

Then, the example is show below.

> from scipy.integrate import solve_ivp
> 
> def exponential_decay(t, y): return -0.5 * y
> 
> sol = solve_ivp(exponential_decay, [0, 10], [2, 4, 8])
> 
> print(sol.t)

However, in third line of the above paragraph ,we use [0, 10] as 't_sapn', which is array_like.


### Reproducing Code Example

```python
from scipy.integrate import solve_ivp
def exponential_decay(t, y): return -0.5 * y
sol = solve_ivp(exponential_decay, [0, 10], [2, 4, 8])
print(sol.t)
```


### Error message

```shell
t_span2-tuple of floats
Interval of integration (t0, tf). The solver starts with t=t0 and integrates until it reaches t=tf.
```


### SciPy/NumPy/Python version information

1.9.1 1.23.1 sys.version_info(major=3, minor=10, micro=4, releaselevel='final', serial=0)


Discussion:
Hi @tsinglinrain, thank you for reporting. We could change this to `array_like (2,)`. Would you like to do a PR?
Firstly thanks to your reply. 

In fact, I don't know anything about document modification on the web, and I'm afraid I can't complete a PR. I am sorry.

Resolving patch:
diff --git a/scipy/integrate/_ivp/ivp.py b/scipy/integrate/_ivp/ivp.py
--- a/scipy/integrate/_ivp/ivp.py
+++ b/scipy/integrate/_ivp/ivp.py
@@ -188,9 +188,10 @@ def solve_ivp(fun, t_span, y0, method='RK45', t_eval=None, dense_output=False,
         options is determined by `vectorized` argument (see below). The
         vectorized implementation allows a faster approximation of the Jacobian
         by finite differences (required for stiff solvers).
-    t_span : 2-tuple of floats
+    t_span : 2-member sequence
         Interval of integration (t0, tf). The solver starts with t=t0 and
-        integrates until it reaches t=tf.
+        integrates until it reaches t=tf. Both t0 and tf must be floats
+        or values interpretable by the float conversion function.
     y0 : array_like, shape (n,)
         Initial state. For problems in the complex domain, pass `y0` with a
         complex data type (even if the initial value is purely real).


Test patch:
Repository: scipy/scipy

Issue:
BUG: Small oversight in sparse.linalg.lsmr?
### Describe your issue.

While reading the scipy LSMR implementation, this line (https://github.com/scipy/scipy/blob/06da9ee65cdee4a8aa036767489bfc5a030527f4/scipy/sparse/linalg/_isolve/lsmr.py#L305) caught my eye.

How can `x=b` ever be valid in this kind of routine? Both have different shapes in the general case, or am I missing something?

The test case below shows that the shape of the returned array changes depending on the values in `b`. I think this is wrong...


### Reproducing Code Example

```python
import numpy as np
import scipy.sparse.linalg

A=np.ones((10,1))
x0=np.ones(1)

x=scipy.sparse.linalg.lsmr(A, b=np.ones(10), x0=x0)[0]
print(x.shape)
# (1,)


x=scipy.sparse.linalg.lsmr(A, b=np.zeros(10), x0=x0)[0]
print(x.shape)
# (10,)
```


### Error message

```shell
No error message, but the shape of the result is different depending on the provided RHS.
```


### SciPy/NumPy/Python version information

1.8.1 1.21.5 sys.version_info(major=3, minor=10, micro=6, releaselevel='final', serial=0)


Discussion:
Thanks for the report @mreineck. Yes, that does look wrong. Perhaps the author meant something like `x[:] = b`, because if the norm of `b` is zero then `x` all zeros should be a valid solution.
Yes, that should work.
(It's an extreme corner case, and I'm not surprised that this hasn't caused problems so far ... if `b[:]==0` you typically don't need a solver :-)

Resolving patch:
diff --git a/scipy/sparse/linalg/_isolve/lsmr.py b/scipy/sparse/linalg/_isolve/lsmr.py
--- a/scipy/sparse/linalg/_isolve/lsmr.py
+++ b/scipy/sparse/linalg/_isolve/lsmr.py
@@ -302,7 +302,7 @@ def lsmr(A, b, damp=0.0, atol=1e-6, btol=1e-6, conlim=1e8,
         return x, istop, itn, normr, normar, normA, condA, normx
 
     if normb == 0:
-        x = b
+        x[()] = 0
         return x, istop, itn, normr, normar, normA, condA, normx
 
     if show:


Test patch:
diff --git a/scipy/sparse/linalg/tests/test_pydata_sparse.py b/scipy/sparse/linalg/tests/test_pydata_sparse.py
--- a/scipy/sparse/linalg/tests/test_pydata_sparse.py
+++ b/scipy/sparse/linalg/tests/test_pydata_sparse.py
@@ -4,7 +4,7 @@
 import scipy.sparse as sp
 import scipy.sparse.linalg as splin
 
-from numpy.testing import assert_allclose
+from numpy.testing import assert_allclose, assert_equal
 
 try:
     import sparse
@@ -75,6 +75,12 @@ def test_lsmr(matrices):
     assert_allclose(res[0], res0[0], atol=1.8e-5)
 
 
+# test issue 17012
+def test_lsmr_output_shape():
+    x = splin.lsmr(A=np.ones((10, 1)), b=np.zeros(10), x0=np.ones(1))[0]
+    assert_equal(x.shape, (1,))
+
+
 def test_lsqr(matrices):
     A_dense, A_sparse, b = matrices
     res0 = splin.lsqr(A_dense, b)
Repository: scipy/scipy

Issue:
BUG: minimize(method=’L-BFGS-B’) documentation is contradictory
### Describe your issue.

Documentation of the method L-BFGS-B ([minimize(method='L-BFGS-B')](https://docs.scipy.org/doc/scipy/reference/optimize.minimize-lbfgsb.html))seems not accurate and can lead to errors. The `maxfun` parameter is described as the "Maximum number of function evaluations.". Nevertheless, this function is a wrapper of [fmin_l_bfgs_b](https://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.fmin_l_bfgs_b.html#scipy.optimize.fmin_l_bfgs_b), which specifies that the maximum number of function evaluations can be violated.

I think it would be clearer to include the full description of the `maxfun` parameter in [fmin_l_bfgs_b](https://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.fmin_l_bfgs_b.html#scipy.optimize.fmin_l_bfgs_b) to [minimize(method='L-BFGS-B')](https://docs.scipy.org/doc/scipy/reference/optimize.minimize-lbfgsb.html). From the users perspective, they could miss the [fmin_l_bfgs_b](https://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.fmin_l_bfgs_b.html#scipy.optimize.fmin_l_bfgs_b)  docs page and perform experiments trusting that the maximum number of function evaluations is going to be respected.

### Reproducing Code Example

```python
-
```


### Error message

```shell
-
```


### SciPy/NumPy/Python version information

1.9.1 (stable)


Discussion:
Thanks @naharrosp for reporting. It would indeed be good to have matching documentation.

Resolving patch:
diff --git a/scipy/optimize/_lbfgsb_py.py b/scipy/optimize/_lbfgsb_py.py
--- a/scipy/optimize/_lbfgsb_py.py
+++ b/scipy/optimize/_lbfgsb_py.py
@@ -240,7 +240,9 @@ def _minimize_lbfgsb(fun, x0, args=(), jac=None, bounds=None,
         If `jac is None` the absolute step size used for numerical
         approximation of the jacobian via forward differences.
     maxfun : int
-        Maximum number of function evaluations.
+        Maximum number of function evaluations. Note that this function
+        may violate the limit because of evaluating gradients by numerical
+        differentiation.
     maxiter : int
         Maximum number of iterations.
     iprint : int, optional


Test patch:
Repository: scipy/scipy

Issue:
ENH: Clarify that ndimage.find_objects returns slices ordered by indices
### Is your feature request related to a problem? Please describe.

The docstring of find_objects does not specify the order in which the slices are returned, but (per #277 and https://github.com/scipy/scipy/issues/13648#issuecomment-791853680) it seems that it returns them "in order", i.e. first the slices corresponding to label 1, then the slice corresponding to label 2, etc.  This is nice, but not obvious given the current docstring:
```
    Find objects in a labeled array.

    Parameters
    ----------
    input : ndarray of ints
        Array containing objects defined by different labels. Labels with
        value 0 are ignored.
    max_label : int, optional
        Maximum label to be searched for in `input`. If max_label is not
        given, the positions of all objects are returned.

    Returns
    -------
    object_slices : list of tuples
        A list of tuples, with each tuple containing N slices (with N the
        dimension of the input array). Slices correspond to the minimal
        parallelepiped that contains the object.

        Each tuple If a number is missing,
        None is returned instead of a slice.
```
e.g. it could easily have been the case that slices are simply returned in the order in which objects are seen when raster scanning through the image.  (The remark about None and missing numbers hints at the actual behavior, but is quite implicit.)

### Describe the solution you'd like.

Clarify that label `l` corresponds to index `l - 1` in the returned array.

### Describe alternatives you've considered.

N/A

### Additional context (e.g. screenshots, GIFs)

N/A


Discussion:

Resolving patch:
diff --git a/scipy/ndimage/_measurements.py b/scipy/ndimage/_measurements.py
--- a/scipy/ndimage/_measurements.py
+++ b/scipy/ndimage/_measurements.py
@@ -256,7 +256,8 @@ def find_objects(input, max_label=0):
         A list of tuples, with each tuple containing N slices (with N the
         dimension of the input array). Slices correspond to the minimal
         parallelepiped that contains the object. If a number is missing,
-        None is returned instead of a slice.
+        None is returned instead of a slice. The label ``l`` corresponds to
+        the index ``l-1`` in the returned list.
 
     See Also
     --------


Test patch:
Repository: scipy/scipy

Issue:
BUG/DOC: optimize: `minimize` doc should reflect tnc's deprecation of `maxiter`.
The description of the `options` parameter in the docstring for `minimize` says

```
options : dict, optional
    A dictionary of solver options. All methods accept the following
    generic options:

        maxiter : int
            Maximum number of iterations to perform. Depending on the
            method each iteration may use several function evaluations.
        disp : bool
            Set to True to print convergence messages.
```

But for the `tnc` solver, `maxiter` is deprecated:

```
In [3]: minimize(lambda x: (x - 1)**2, x0=3, method='tnc', options=dict(maxiter=100))
<ipython-input-3-2433b45c9cf0>:1: DeprecationWarning: 'maxiter' has been deprecated in favor of 'maxfun' and will be removed in SciPy 1.11.0.
  minimize(lambda x: (x - 1)**2, x0=3, method='tnc', options=dict(maxiter=100))
Out[3]: 
 message: Local minimum reached (|pg| ~= 0)
 success: True
  status: 0
     fun: 2.4999875351303067e-17
       x: [ 1.000e+00]
     nit: 2
     jac: [ 2.000e-08]
    nfev: 10
```

The docstring for `minimize` should be updated to reflect this deprecation, and recommend `maxfun` instead of `maxiter` for the `tnc` solver.  Something like "All methods except `'tnc'` accept [...]  For `'tnc'`, use `maxfun` instead of `maxiter`."



Discussion:

Resolving patch:
diff --git a/scipy/optimize/_minimize.py b/scipy/optimize/_minimize.py
--- a/scipy/optimize/_minimize.py
+++ b/scipy/optimize/_minimize.py
@@ -177,12 +177,14 @@ def minimize(fun, x0, args=(), method=None, jac=None, hess=None,
         equal to `tol`. For detailed control, use solver-specific
         options.
     options : dict, optional
-        A dictionary of solver options. All methods accept the following
-        generic options:
+        A dictionary of solver options. All methods except `TNC` accept the
+        following generic options:
 
             maxiter : int
                 Maximum number of iterations to perform. Depending on the
                 method each iteration may use several function evaluations.
+
+                For `TNC` use `maxfun` instead of `maxiter`.
             disp : bool
                 Set to True to print convergence messages.
 
diff --git a/scipy/optimize/_tnc.py b/scipy/optimize/_tnc.py
--- a/scipy/optimize/_tnc.py
+++ b/scipy/optimize/_tnc.py
@@ -313,9 +313,13 @@ def _minimize_tnc(fun, x0, args=(), jac=None, bounds=None,
         -gradient if maxCGit < 0, maxCGit is set to
         max(1,min(50,n/2)). Defaults to -1.
     maxiter : int, optional
-        Maximum number of function evaluations. This keyword is deprecated
-        in favor of `maxfun` and will removed in SciPy 1.11.0.
+        Maximum number of function evaluations. If `maxfun` is also provided
+        then `maxiter` is ignored.
         Default is None.
+
+        .. deprecated :: 1.9.0
+            `maxiter` is deprecated in favor of `maxfun` and will removed in
+            SciPy 1.11.0.
     eta : float
         Severity of the line search. If < 0 or > 1, set to 0.25.
         Defaults to -1.


Test patch:
Repository: scipy/scipy

Issue:
Typo: on page https://docs.scipy.org/doc/scipy/reference/generated/scipy.integrate.dblquad.html#scipy.integrate.dblquad
### Describe your issue.

There is a typo on the page https://docs.scipy.org/doc/scipy/reference/generated/scipy.integrate.dblquad.html#scipy.integrate.dblquad
On the very last example, the code examples integrate from x to 2-x, but the displayed integral integrates from 2-x to x.

![typo_on_dblquad](https://user-images.githubusercontent.com/12072431/202865288-bca0c976-a2c3-4698-8fe6-8a113d3d6fd7.PNG)



### Reproducing Code Example

```python
NA
```


### Error message

```shell
NA
```


### SciPy/NumPy/Python version information

1.9.3


Discussion:
Would you like to submit a pr @davidjabon?

Resolving patch:
diff --git a/scipy/integrate/_quadpack_py.py b/scipy/integrate/_quadpack_py.py
--- a/scipy/integrate/_quadpack_py.py
+++ b/scipy/integrate/_quadpack_py.py
@@ -693,7 +693,7 @@ def dblquad(func, a, b, gfun, hfun, args=(), epsabs=1.49e-8, epsrel=1.49e-8):
     >>> integrate.dblquad(f, 0, np.pi/4, np.sin, np.cos)
         (0.41421356237309503, 1.1083280054755938e-14)
 
-    Calculate :math:`\\int^{x=1}_{x=0} \\int^{y=x}_{y=2-x} a x y \\,dy \\,dx`
+    Calculate :math:`\\int^{x=1}_{x=0} \\int^{y=2-x}_{y=x} a x y \\,dy \\,dx`
     for :math:`a=1, 3`.
 
     >>> f = lambda y, x, a: a*x*y


Test patch:
Repository: scipy/scipy

Issue:
BUG: `[source]` button in the docs sending to the wrong place
### Describe your issue.

The button `[source]` in the doc page of `scipy.stats.wilcoxon`  is pointing to its decorator `scipy.stats._axis_nan_policy`.

Extracted bit of code:

```python
@_axis_nan_policy_factory(
    wilcoxon_result_object, paired=True,
    n_samples=lambda kwds: 2 if kwds.get('y', None) is not None else 1,
    result_to_tuple=wilcoxon_result_unpacker, n_outputs=wilcoxon_outputs,
)
def wilcoxon(x, y=None, zero_method="wilcox", correction=False,
             alternative="two-sided", method='auto'):
```

Links: 
- `scipy.stats.wilcoxon`: [docs.scipy.org/doc/scipy/reference/generated/scipy.stats.wilcoxon.html](https://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.wilcoxon.html): 
- `scipy.stats._axis_nan_policy` : [github.com/scipy/scipy/blob/v1.9.3/scipy/stats/_axis_nan_policy.py](https://github.com/scipy/scipy/blob/v1.9.3/scipy/stats/_axis_nan_policy.py#L3131-L3433)

![image](https://user-images.githubusercontent.com/24547377/205274762-dcb2cadf-c4e0-481b-beb2-e0f7ab5a9d18.png)

### Reproducing Code Example

```python
Go to the website and click on the button : )
```


### Error message

```shell
N/A
```


### SciPy/NumPy/Python version information

1.9.3 (stable) [doc]


Discussion:
@tirthasheshpatel you've fixed some Sphinx "Source" linking issues before. Do you know how to tell Sphinx to link to the location of the wrapped function rather than the wrapper?
The low-tech solution is to separate the function with the documentation from a private function with the implementation. The latter would be wrapped and the former would call the wrapped private function. 

Resolving patch:
diff --git a/doc/source/conf.py b/doc/source/conf.py
--- a/doc/source/conf.py
+++ b/doc/source/conf.py
@@ -375,7 +375,8 @@ def linkcode_resolve(domain, info):
             return None
 
     # Use the original function object if it is wrapped.
-    obj = getattr(obj, "__wrapped__", obj)
+    while hasattr(obj, "__wrapped__"):
+        obj = obj.__wrapped__
     # SciPy's distributions are instances of *_gen. Point to this
     # class since it contains the implementation of all the methods.
     if isinstance(obj, (rv_generic, multi_rv_generic)):


Test patch:
Repository: scipy/scipy

Issue:
ENH: Expose DisjointSet._sizes
### Is your feature request related to a problem? Please describe.

Currently, `scipy.cluster.hierarchy.DisjointSet` internally keeps track of the size of each subset in the `_sizes` dict, making it available in O(1) (well, one needs to canonicalize keys first, in O(alpha(n)) ~ O(1)), but does not expose that info; the only way to access it publically is to reconstruct the actual subset (`.subset()`) and compute its size (`len()`), which is much slower (that's proportional to the size of the subset).

An example of algorithm that benefits from this info is "An efficient algorithm for exact evaluation of stochastic watersheds", Malmberg & Luengo 2014 (algorithm 2 relies on the disjoint-set, and equation 3 is the one where the size of the subset is needed).

### Describe the solution you'd like.

Add a `DisjointSet().size(x)` API (perhaps `size_of_subset` if one wants to be super clear), which is `return self._sizes[self[x]]` (where `self[x]` canonicalizes the key).

### Describe alternatives you've considered.

N/A

### Additional context (e.g. screenshots, GIFs)

N/A


Discussion:

Resolving patch:
diff --git a/scipy/_lib/_disjoint_set.py b/scipy/_lib/_disjoint_set.py
--- a/scipy/_lib/_disjoint_set.py
+++ b/scipy/_lib/_disjoint_set.py
@@ -19,6 +19,7 @@ class DisjointSet:
     merge
     connected
     subset
+    subset_size
     subsets
     __getitem__
 
@@ -76,6 +77,12 @@ class DisjointSet:
     >>> disjoint_set.subset('a')
     {'a', 3, 'b'}
 
+    Get the size of the subset containing 'a' (without actually instantiating
+    the subset):
+
+    >>> disjoint_set.subset_size('a')
+    3
+
     Get all subsets in the disjoint set:
 
     >>> disjoint_set.subsets()
@@ -210,6 +217,25 @@ def subset(self, x):
             nxt = self._nbrs[nxt]
         return set(result)
 
+    def subset_size(self, x):
+        """Get the size of the subset containing `x`.
+
+        Note that this method is faster than ``len(self.subset(x))`` because
+        the size is directly read off an internal field, without the need to
+        instantiate the full subset.
+
+        Parameters
+        ----------
+        x : hashable object
+            Input element.
+
+        Returns
+        -------
+        result : int
+            Size of the subset containing `x`.
+        """
+        return self._sizes[self[x]]
+
     def subsets(self):
         """Get all the subsets in the disjoint set.
 


Test patch:
diff --git a/scipy/cluster/tests/test_disjoint_set.py b/scipy/cluster/tests/test_disjoint_set.py
--- a/scipy/cluster/tests/test_disjoint_set.py
+++ b/scipy/cluster/tests/test_disjoint_set.py
@@ -189,6 +189,7 @@ def test_subsets(n):
         y = elements[j]
 
         expected = {element for element in dis if {dis[element]} == {dis[x]}}
+        assert dis.subset_size(x) == len(dis.subset(x))
         assert expected == dis.subset(x)
 
         expected = {dis[element]: set() for element in dis}
Repository: scipy/scipy

Issue:
DOC: dimension clarification in `directed_hausdorff `
### Describe your issue.

the `directed_hausdorff` method in the spatial/distance.py module says:
"Compute the directed Hausdorff distance between two 2-D arrays."
The two examples given are both also for 2-D arrays. However, from a few tests I ran and from my understanding of the code, it looks like there are no limits on the dimensionality.

It would be helpful to modify that line at the top of the method, and perhaps one of the examples to clarify that `directed_hausdorff` works for 3 or even higher dimensions.

### Reproducing Code Example

```python
import numpy as np
from scipy.spatial.distance import directed_hausdorff
x = np.array([[0, 0, 0]])
y = np.array([[1, 1, 0], [1, 1, 1]])
directed_hausdorff(y, x)
```


### Error message

```shell
N/A
```


### SciPy/NumPy/Python version information

1.9.1


Discussion:

Resolving patch:
diff --git a/scipy/spatial/distance.py b/scipy/spatial/distance.py
--- a/scipy/spatial/distance.py
+++ b/scipy/spatial/distance.py
@@ -315,9 +315,9 @@ def directed_hausdorff(u, v, seed=0):
     Parameters
     ----------
     u : (M,N) array_like
-        Input array.
+        Input array with M points in N dimensions.
     v : (O,N) array_like
-        Input array.
+        Input array with O points in N dimensions.
     seed : int or None
         Local `numpy.random.RandomState` seed. Default is 0, a random
         shuffling of u and v that guarantees reproducibility.


Test patch: