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

Issue:
nmax in scipy.integrate warning message should be nsteps instead
When using scipy.integrate.ode, sometimes I encounter a warning that says

```
dopri5: larger nmax is needed
```
However, there is no `nmax` argument in the module. I believe the correct argument here is `nsteps` instead of `nmax`. 

I think the relevant part of the code is [here](https://github.com/scipy/scipy/blob/master/scipy/integrate/_ode.py#L1033). I also found [this stackoverflow question](https://stackoverflow.com/questions/26096209/python-scipy-ode-dopri5-larger-nmax-needed) that discusses this. 

### Scipy/Numpy/Python version information:
```
0.19.1 1.13.1 sys.version_info(major=3, minor=6, micro=2, releaselevel='final', serial=0)
```




Discussion:

Resolving patch:
diff --git a/scipy/integrate/_ode.py b/scipy/integrate/_ode.py
--- a/scipy/integrate/_ode.py
+++ b/scipy/integrate/_ode.py
@@ -1030,7 +1030,7 @@ class dopri5(IntegratorBase):
     messages = {1: 'computation successful',
                 2: 'comput. successful (interrupted by solout)',
                 -1: 'input is not consistent',
-                -2: 'larger nmax is needed',
+                -2: 'larger nsteps is needed',
                 -3: 'step size becomes too small',
                 -4: 'problem is probably stiff (interrupted)',
                 }


Test patch:
Repository: scipy/scipy

Issue:
Documentation should discourage odeint
odeint is not the recommended way to solve an IVP, but that's not mentioned in the documentation. I am not suggesting that odeint be removed, but we should discourage users from using it.


Discussion:

Resolving patch:
diff --git a/scipy/integrate/odepack.py b/scipy/integrate/odepack.py
--- a/scipy/integrate/odepack.py
+++ b/scipy/integrate/odepack.py
@@ -28,6 +28,9 @@ def odeint(func, y0, t, args=(), Dfun=None, col_deriv=0, full_output=0,
            mxords=5, printmessg=0):
     """
     Integrate a system of ordinary differential equations.
+    
+    .. note:: For new code, use `scipy.integrate.solve_ivp` to solve a
+              differential equation.
 
     Solve a system of ordinary differential equations using lsoda from the
     FORTRAN library odepack.
@@ -39,9 +42,9 @@ def odeint(func, y0, t, args=(), Dfun=None, col_deriv=0, full_output=0,
 
     where y can be a vector.
 
-    *Note*: The first two arguments of ``func(y, t, ...)`` are in the
-    opposite order of the arguments in the system definition function used
-    by the `scipy.integrate.ode` class.
+    .. note:: The first two arguments of ``func(y, t, ...)`` are in the
+              opposite order of the arguments in the system definition
+              function used by the `scipy.integrate.ode` class.
 
     Parameters
     ----------


Test patch:
Repository: scipy/scipy

Issue:
local variable used before assignment in NeutonCG local terminate function
https://github.com/scipy/scipy/blob/11509c4a98edded6c59423ac44ca1b7f28fba1fd/scipy/optimize/optimize.py#L1519-L1522

Can you please explain where should that function get "gfk" variable from? Running Neuton-CG method calls that code while internally calling local terminate() function
 and returns

> NameError: free variable 'gfk' referenced before assignment in enclosing scope




Discussion:

Resolving patch:
diff --git a/scipy/optimize/optimize.py b/scipy/optimize/optimize.py
--- a/scipy/optimize/optimize.py
+++ b/scipy/optimize/optimize.py
@@ -1557,6 +1557,7 @@ def terminate(warnflag, msg):
     if retall:
         allvecs = [xk]
     k = 0
+    gfk = None
     old_fval = f(x0)
     old_old_fval = None
     float64eps = numpy.finfo(numpy.float64).eps


Test patch:
diff --git a/scipy/optimize/tests/test_optimize.py b/scipy/optimize/tests/test_optimize.py
--- a/scipy/optimize/tests/test_optimize.py
+++ b/scipy/optimize/tests/test_optimize.py
@@ -321,6 +321,14 @@ def test_neldermead_initial_simplex_bad(self):
                               full_output=True, disp=False, retall=False,
                               initial_simplex=simplex)
 
+    def test_ncg_negative_maxiter(self):
+        # Regression test for gh-8241
+        opts = {'maxiter': -1}
+        result = optimize.minimize(self.func, self.startparams,
+                                   method='Newton-CG', jac=self.grad,
+                                   args=(), options=opts)
+        assert_(result.status == 1)
+
     def test_ncg(self):
         # line-search Newton conjugate gradient optimization routine
         if self.use_wrapper:
Repository: scipy/scipy

Issue:
DOC: Explain constraints on `blas` module functions with ovewrite option
Turns out the overwrite option, when provided, does not work in all cases. So, it would be nice to clarify that this requires a Fortran array of the right type.



Discussion:
It only means the arrays may be overwritten (usually if memory order and data type allows it).

I guess a warning with some explanation as to why would be helpful as well.
Should we include a hard coded explanation in the main documentation page for these keyword usage? 
I guess here:

https://docs.scipy.org/doc/scipy/reference/linalg.blas.html
https://docs.scipy.org/doc/scipy/reference/linalg.lapack.html

Yes. That's what I had in mind.

Resolving patch:
diff --git a/scipy/linalg/blas.py b/scipy/linalg/blas.py
--- a/scipy/linalg/blas.py
+++ b/scipy/linalg/blas.py
@@ -6,6 +6,24 @@
 
 .. versionadded:: 0.12.0
 
+.. note::
+
+   The common ``overwrite_<>`` option in many routines, allows the
+   input arrays to be overwritten to avoid extra memory allocation.
+   However this requires the array to satisfy two conditions
+   which are memory order and the data type to match exactly the
+   order and the type expected by the routine.
+
+   As an example, if you pass a double precision float array to any
+   ``S....`` routine which expects single precision arguments, f2py
+   will create an intermediate array to match the argument types and
+   overwriting will be performed on that intermediate array.
+
+   Similarly, if a C-contiguous array is passed, f2py will pass a
+   FORTRAN-contiguous array internally. Please make sure that these
+   details are satisfied. More information can be found in the f2py
+   documentation.
+
 .. warning::
 
    These functions do little to no error checking.
diff --git a/scipy/linalg/lapack.py b/scipy/linalg/lapack.py
--- a/scipy/linalg/lapack.py
+++ b/scipy/linalg/lapack.py
@@ -10,6 +10,24 @@
 
 .. versionadded:: 0.12.0
 
+.. note::
+
+    The common ``overwrite_<>`` option in many routines, allows the
+    input arrays to be overwritten to avoid extra memory allocation.
+    However this requires the array to satisfy two conditions
+    which are memory order and the data type to match exactly the
+    order and the type expected by the routine.
+
+    As an example, if you pass a double precision float array to any
+    ``S....`` routine which expects single precision arguments, f2py
+    will create an intermediate array to match the argument types and
+    overwriting will be performed on that intermediate array.
+
+    Similarly, if a C-contiguous array is passed, f2py will pass a
+    FORTRAN-contiguous array internally. Please make sure that these
+    details are satisfied. More information can be found in the f2py
+    documentation.
+
 .. warning::
 
    These functions do little to no error checking.


Test patch:
Repository: scipy/scipy

Issue:
loadmat() raises TypeError instead of FileNotFound when reading non-existing mat file
I tried to load non-existing file, scipy.io.loadmat() raises TypeError for scipy version 1.0.0.
In version 0.19.1, the same code returns FileNotFoundError, which should look more preferable.

### Reproducing code example:
```
import scipy.io
scipy.io.loadmat('a.mat')   # a.mat is not existing
```

### Error message:
```
1.0.0
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-1-09dae49b6da5> in <module>()
      2 print(scipy.__version__)
      3 import scipy.io
----> 4 scipy.io.loadmat('a.mat')   # a.mat is not existing

/home/futaana/anaconda3/envs/irfpy.aspera-f/lib/python3.6/site-packages/scipy/io/matlab/mio.py in loadmat(file_name, mdict, appendmat, **kwargs)
    139     """
    140     variable_names = kwargs.pop('variable_names', None)
--> 141     MR, file_opened = mat_reader_factory(file_name, appendmat, **kwargs)
    142     matfile_dict = MR.get_variables(variable_names)
    143     if mdict is not None:

/home/futaana/anaconda3/envs/irfpy.aspera-f/lib/python3.6/site-packages/scipy/io/matlab/mio.py in mat_reader_factory(file_name, appendmat, **kwargs)
     62 
     63     """
---> 64     byte_stream, file_opened = _open_file(file_name, appendmat)
     65     mjv, mnv = get_matfile_version(byte_stream)
     66     if mjv == 0:

TypeError: 'NoneType' object is not iterable
```

### Scipy/Numpy/Python version information:
```
<<Output from 'import sys, scipy, numpy; print(scipy.__version__, numpy.__version__, sys.version_info)'>>
1.0.0 1.12.1 sys.version_info(major=3, minor=6, micro=1, releaselevel='final', serial=0)
```




Discussion:
This is a bug. `loadmat("asd.mat")` throws `TypeError` as OP says. However, `loadmat("asd")` throws `FileNotFoundError`. Considering the default is `appendmat=True`, I don't see how this could be desirable.

Resolving patch:
diff --git a/scipy/io/matlab/mio.py b/scipy/io/matlab/mio.py
--- a/scipy/io/matlab/mio.py
+++ b/scipy/io/matlab/mio.py
@@ -36,7 +36,7 @@ def _open_file(file_like, appendmat):
         if isinstance(file_like, string_types):
             if appendmat and not file_like.endswith('.mat'):
                 file_like += '.mat'
-                return open(file_like, 'rb'), True
+            return open(file_like, 'rb'), True
         else:
             raise IOError('Reader needs file name or open file-like object')
 


Test patch:
diff --git a/scipy/io/matlab/tests/test_mio.py b/scipy/io/matlab/tests/test_mio.py
--- a/scipy/io/matlab/tests/test_mio.py
+++ b/scipy/io/matlab/tests/test_mio.py
@@ -1234,3 +1234,9 @@ def test_save_unicode_field(tmpdir):
     filename = os.path.join(str(tmpdir), 'test.mat')
     test_dict = {u'a':{u'b':1,u'c':'test_str'}}
     savemat(filename, test_dict)
+
+
+def test_filenotfound():
+    # Check the correct error is thrown
+    assert_raises(IOError, loadmat, "NotExistentFile00.mat")
+    assert_raises(IOError, loadmat, "NotExistentFile00")
Repository: scipy/scipy

Issue:
BUG: romb print output requires correction
The option `show=True` results into a wrongly formatted output


### Reproducing code example:
```
x9v, h9v = np.linspace(1, 2, 9, retstep=True)  # korak h9v = 0.125 (9 vozlišč)
y9v = x9v * np.sin(x9v)
romb(y9v, dx=h9v, show=True)
```
See figure:
![image](https://user-images.githubusercontent.com/5072664/32768516-66150cbc-c918-11e7-872e-fe282592e94e.png)

### Scipy/Numpy/Python version information:
```
1.0.0 1.13.3 sys.version_info(major=3, minor=6, micro=3, releaselevel='final', serial=0)
```




Discussion:
@ilayn I know how to solve it(adding "\n" in one place ;p). Can I PR this?
@Tokixix Sure, if there is noone explicitly claimed to work on it, you can freely pick up on any issue. Make sure to create a new branch though 😃 

Also if you place[ one of these words ](https://help.github.com/articles/closing-issues-using-keywords/) in your PR description, then your PR will close this issue once merged. For example, I've just edited #8296 description to link to the issue. 
@ilayn Will do, thanks!

Resolving patch:
diff --git a/scipy/integrate/quadrature.py b/scipy/integrate/quadrature.py
--- a/scipy/integrate/quadrature.py
+++ b/scipy/integrate/quadrature.py
@@ -537,7 +537,7 @@ def romb(y, dx=1.0, axis=-1, show=False):
             formstr = "%%%d.%df" % (width, precis)
 
             title = "Richardson Extrapolation Table for Romberg Integration"
-            print("", title.center(68), "=" * 68, sep="\n", end="")
+            print("", title.center(68), "=" * 68, sep="\n", end="\n")
             for i in xrange(k+1):
                 for j in xrange(i+1):
                     print(formstr % R[(i, j)], end=" ")


Test patch:
Repository: scipy/scipy

Issue:
mstats.winsorize documentation needs clarification
stats.mstats.winsorize documentation needs some clarification:

From https://github.com/scipy/scipy/pull/7717#issuecomment-322436936:
<quote>
This shows the difference (look at the number of values at start/end that are identical):

    In [11]: data
    Out[11]: 
    masked_array(data = [77 87 88 114 151 -- 219 246 253 262 296 299 306 376 428 515 666 1310 2611],
                 mask = [False False False False False  True False False False False False False
     False False False False False False False],
           fill_value = 999999)

    In [12]: mstats.winsorize(data, (0.2, 0.2))
    Out[12]: 
    masked_array(data = [114 114 114 114 151 515 219 246 253 262 296 299 306 376 428 515 515 515
     515],
                 mask = [False False False False False False False False False False False False
     False False False False False False False],
           fill_value = 999999)

    In [13]: mstats.winsorize(data, (0.2, 0.2), inclusive=(False, False))
    Out[13]: 
    masked_array(data = [151 151 151 151 151 428 219 246 253 262 296 299 306 376 428 428 428 428
     428],
                 mask = [False False False False False False False False False False False False
     False False False False False False False],
           fill_value = 999999)

I think it's the description of ``inclusive`` in the docstring that's a little confusing, it talks about number of data being masked while the truncation is about indices used to construct the ``lowidx-upidx`` interval of data to *keep*. Can you try to reformulate that description?
</quote>


Discussion:
According to the documentation, if inclusive is True then the number of data being masked on each side should be rounded and if False, then it should be truncated. But the code in _scipy/scipystats/mstats_basic.py_ line 1763 

```
if low_include:          #low_include is the first entry of the inclusive tuple
       lowidx = int(low_limit * n)
else:
       lowidx = np.round(low_limit * n).astype(int)
```

does the opposite.

So, either the documentation has to be changed or the if clause. Shall I make a PR?

Resolving patch:
diff --git a/scipy/stats/mstats_basic.py b/scipy/stats/mstats_basic.py
--- a/scipy/stats/mstats_basic.py
+++ b/scipy/stats/mstats_basic.py
@@ -1747,7 +1747,7 @@ def winsorize(a, limits=None, inclusive=(True, True), inplace=False,
         indicate an open interval.
     inclusive : {(True, True) tuple}, optional
         Tuple indicating whether the number of data being masked on each side
-        should be rounded (True) or truncated (False).
+        should be truncated (True) or rounded (False).
     inplace : {False, True}, optional
         Whether to winsorize in place (True) or to use a copy (False)
     axis : {None, int}, optional


Test patch:
Repository: scipy/scipy

Issue:
Have eigh check for hermitian/symmetric
A colleague had a bug in her program that we finally traced down to her call of `linalg.eigh`. If your input is not symmetric/Hermitian, `eigh` will return incorrect eigenstuff.

I'd suggest having `eigh` check that the input is symmetric/Hermitian.  Seems easy to accomplish, here's a suggestion for the beginning of `eigh`:

`if not numpy.allclose(a, numpy.asmatrix(a).H):`
`    raise ValueError('expected symmetric or Hermitian matrix,\`
`                         try using numpy.linalg.eig instead')`

(sorry about the indentation!)

I tried contributing but got bogged down in installing Fortran, missing packages, etc.  Would greatly appreciate if someone would take this up. Thanks!


Discussion:
If not an error, it would be nice if it threw a warning at least. I faced the same problem a few months ago. I could take it up, if there is an agreement that this needs addressing.
This might be a documentation issue but the behavior is consistent. It is standard LAPACK behavior and the `lower` keyword is actually used to pick up the part of interest. As an example, you can pack two symmetric matrices in one array by just selecting upper/lower parts.
Okay, but at first glance (and for a novice user), the documentation says 

> Solve an ordinary or generalized eigenvalue problem for a complex Hermitian or real symmetric matrix

I think there should be something in the documentation that explains what happens when anything other than Hermitian Matrix is passed.
I agree that this should be a documentation fix. Most users aren't very familiar with LAPACK.

Resolving patch:
diff --git a/scipy/linalg/decomp.py b/scipy/linalg/decomp.py
--- a/scipy/linalg/decomp.py
+++ b/scipy/linalg/decomp.py
@@ -343,6 +343,12 @@ def eigh(a, b=None, lower=True, eigvals_only=False, overwrite_a=False,
     eigh_tridiagonal : eigenvalues and right eiegenvectors for
         symmetric/Hermitian tridiagonal matrices
 
+    Notes
+    -----
+    This function does not check the input array for being hermitian/symmetric
+    in order to allow for representing arrays with only their upper/lower
+    triangular parts.
+
     Examples
     --------
     >>> from scipy.linalg import eigh
@@ -820,6 +826,12 @@ def eigvalsh(a, b=None, lower=True, overwrite_a=False,
     eigvalsh_tridiagonal : eigenvalues of symmetric/Hermitian tridiagonal
         matrices
 
+    Notes
+    -----
+    This function does not check the input array for being hermitian/symmetric
+    in order to allow for representing arrays with only their upper/lower
+    triangular parts.
+
     Examples
     --------
     >>> from scipy.linalg import eigvalsh


Test patch:
Repository: scipy/scipy

Issue:
leastsq needlessly appends extra dimension for scalar problems
When treating a scalar problem, leastsq needlessly appends an extra dimension to the argument of the function to be minimized as well as the result. MCVE:
```python
from scipy.optimize import leastsq

def f(x):
    print(x.shape)
    return x


out = leastsq(f, 0.0)
print(out)
print()
leastsq(f, [0.0])
print(out)
```
Output:
```
(1,)
(1,)
(1,)
(1,)
(array([0.]), 4)

(1,)
(1,)
(1,)
(1,)
(array([0.]), 4)
```
Expected output:
```
()
()
()
()
(array(0.), 4)

(1,)
(1,)
(1,)
(1,)
(array([0.]), 4)
```
As a consequence of this, many codes have to select the "first" element in a scalar problem
```python
out, _ = leastsq(f, 0.0)
theta = out[0]  # this should be unnecessary
```
I personally ran into this when trying to clean up my `f(x)` which involves `dot`s and such, and wondered why things like
```python
array = something()

def f(theta):
    sc = numpy.array([numpy.sin(theta), numpy.cos(theta)])
    return numpy.dot(sc, array)
```
wouldn't work. (It was the superfluous dimension in `theta` that had the dot product fail.)


Discussion:
I think this is due to the conversion of `x0` i.e (The starting estimate for the minimization) into a `numpy.array` in method `leastsq`, should this be handled if `x0` has only one value or add appropriate documentation for inputs of `func` in method [leastsq](https://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.leastsq.html)
At this point, I would favor simply documentation-only fix as no doubt there is code out there relying on the current behavior, so it cannot just be changed.

The issue is that in general these routines work only on 1D vectors and don't preserve the input shape, so the current behavior is not immediately considered a bug. If they generally preserved the input shape one could argue differently, but this is not the case.
Ah, you're right: It's the flatten() at https://github.com/scipy/scipy/blob/master/scipy/optimize/minpack.py#L377.


Resolving patch:
diff --git a/scipy/optimize/minpack.py b/scipy/optimize/minpack.py
--- a/scipy/optimize/minpack.py
+++ b/scipy/optimize/minpack.py
@@ -373,6 +373,8 @@ def leastsq(func, x0, args=(), Dfun=None, full_output=0,
            min   sum((ydata - f(xdata, params))**2, axis=0)
          params
 
+    The solution, `x`, is always a 1D array, regardless of the shape of `x0`,
+    or whether `x0` is a scalar.
     """
     x0 = asarray(x0).flatten()
     n = len(x0)


Test patch:
Repository: scipy/scipy

Issue:
BENCH: Benchmarks for find_peaks, peak_prominences & peak_widths
As suggested in #8594 it might be worthwhile to add asv benchmarks for the recently added functions

- [x] [find_peaks](https://scipy.github.io/devdocs/generated/scipy.signal.find_peaks.html)
- [x] [peak_prominences](https://scipy.github.io/devdocs/generated/scipy.signal.peak_prominences.html)
- [x] [peak_widths](https://scipy.github.io/devdocs/generated/scipy.signal.peak_widths.html)

introduced with #8264. This may act as a reminder and place of discussion until I or someone else takes this up in a PR or it is resolved by other means.

See also: #8541, #8523


Discussion:
Ping @tylerjereddy (I don't now if GitHub informes about references automatically)
@lagru Thanks!

Resolving patch:
diff --git a/benchmarks/benchmarks/peak_finding.py b/benchmarks/benchmarks/peak_finding.py
new file mode 100644
--- /dev/null
+++ b/benchmarks/benchmarks/peak_finding.py
@@ -0,0 +1,59 @@
+"""Benchmarks for peak finding related functions."""
+
+from __future__ import division, print_function, absolute_import
+
+try:
+    from scipy.signal import find_peaks, peak_prominences, peak_widths
+    from scipy.misc import electrocardiogram
+except ImportError:
+    pass
+
+from .common import Benchmark
+
+
+class FindPeaks(Benchmark):
+    """Benchmark `scipy.signal.find_peaks`.
+
+    Notes
+    -----
+    The first value of `distance` is None in which case the benchmark shows
+    the actual speed of the underlying maxima finding function.
+    """
+
+    param_names = ['distance']
+    params = [[None, 8, 64, 512, 4096]]
+
+    def setup(self, distance):
+        self.x = electrocardiogram()
+
+    def time_find_peaks(self, distance):
+        find_peaks(self.x, distance=distance)
+
+
+class PeakProminences(Benchmark):
+    """Benchmark `scipy.signal.peak_prominences`."""
+
+    param_names = ['wlen']
+    params = [[None, 8, 64, 512, 4096]]
+
+    def setup(self, wlen):
+        self.x = electrocardiogram()
+        self.peaks = find_peaks(self.x)[0]
+
+    def time_peak_prominences(self, wlen):
+        peak_prominences(self.x, self.peaks, wlen)
+
+
+class PeakWidths(Benchmark):
+    """Benchmark `scipy.signal.peak_widths`."""
+
+    param_names = ['rel_height']
+    params = [[0, 0.25, 0.5, 0.75, 1]]
+
+    def setup(self, rel_height):
+        self.x = electrocardiogram()
+        self.peaks = find_peaks(self.x)[0]
+        self.prominence_data = peak_prominences(self.x, self.peaks)
+
+    def time_peak_widths(self, rel_height):
+        peak_widths(self.x, self.peaks, rel_height, self.prominence_data)


Test patch: