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

Issue:
Regression in numpy master: np.ma.median with axis returns wrong result when there is only one non-masked value
### Snippet:

``` py
import numpy as np

masked_arr = np.ma.masked_array([[5.], [0.], [0.]],
                                [[False], [True], [True]])
print('masked_arr\n', masked_arr)
print('median\n', np.ma.median(masked_arr, axis=0))
```
### Output:
#### numpy 1.11.1

``` masked_arr
 [[5.0]
 [--]
 [--]]
median
 [ 5.]
```

The median is 5. as expected since this is the only non-masked value.
#### numpy master

```
masked_arr
 [[5.0]
 [--]
 [--]]
median
 [2.5]
```

The median is 2.5, unexpectedly.

FWIW, the result is fine when not using an `axis` argument.



Discussion:
Looks like the culprit is https://github.com/numpy/numpy/commit/66f313f5762eeecc4171e494a7779c3e247fb584.

`np.copyto(low, high, where=odd)` doesn't unmask the values in contrary to `low[odd] = high[odd]`.


Resolving patch:
diff --git a/numpy/ma/extras.py b/numpy/ma/extras.py
--- a/numpy/ma/extras.py
+++ b/numpy/ma/extras.py
@@ -727,9 +727,8 @@ def _median(a, axis=None, out=None, overwrite_input=False):
     ind = np.meshgrid(*axes_grid, sparse=True, indexing='ij')
 
     # insert indices of low and high median
-    ind.insert(axis, h - 1)
+    ind.insert(axis, np.maximum(0, h - 1))
     low = asorted[tuple(ind)]
-    low._sharedmask = False
     ind[axis] = h
     high = asorted[tuple(ind)]
 


Test patch:
diff --git a/numpy/ma/tests/test_extras.py b/numpy/ma/tests/test_extras.py
--- a/numpy/ma/tests/test_extras.py
+++ b/numpy/ma/tests/test_extras.py
@@ -790,6 +790,15 @@ def test_out(self):
         assert_equal(r, out)
         assert_(type(r) == MaskedArray)
 
+    def test_single_non_masked_value_on_axis(self):
+        data = [[1., 0.],
+                [0., 3.],
+                [0., 0.]]
+        masked_arr = np.ma.masked_equal(data, 0)
+        expected = [1., 3.]
+        assert_array_equal(np.ma.median(masked_arr, axis=0),
+                           expected)
+
 
 class TestCov(TestCase):
Repository: numpy/numpy

Issue:
Minor imprecision in error message from `rollaxis`
```
In [1]: np.rollaxis(np.zeros((2, 2)), 3)
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-1-b401785fc6dd> in <module>()
----> 1 np.rollaxis(np.zeros((2, 2)), 3)

/usr/lib/python3.5/site-packages/numpy/core/numeric.py in rollaxis(a, axis, start)
   1448     msg = 'rollaxis: %s (%d) must be >=0 and < %d'
   1449     if not (0 <= axis < n):
-> 1450         raise ValueError(msg % ('axis', axis, n))
   1451     if not (0 <= start < n + 1):
   1452         raise ValueError(msg % ('start', start, n + 1))

ValueError: rollaxis: axis (3) must be >=0 and < 2
```

but in fact a negative index will work too:

```
In [2]: np.rollaxis(np.zeros((2, 2)), -1)
Out[2]: 
array([[ 0.,  0.],
       [ 0.,  0.]])
```

numpy 1.11.1



Discussion:
Reproducible on `master`.

Is there any reason why negative values `(< n)` are rejected?  Couldn't we just do `mod n` on the value?

This is just a bug in the error message. Negative axes (`-1` through `-ndim`) are already supported.

@shoyer : That's not exactly what I meant.  I mean, why can't we just accept any integer and then readjust it `mod n` i.e. `start = start % (n + 1)` AND `axis = axis % n`?

Fixing the error message would be the immediate fix, but it seems like an enhancement could be possible and would obviate the error message.

Suppose you have a 2D array. What does `np.rollaxis(a, axis=2)` mean? The array has no 3rd axis to roll.

Rather than guess about user intent, NumPy raises errors in ambiguous cases. This helps catch bugs in user code.


Resolving patch:
diff --git a/numpy/core/numeric.py b/numpy/core/numeric.py
--- a/numpy/core/numeric.py
+++ b/numpy/core/numeric.py
@@ -1531,12 +1531,12 @@ def rollaxis(a, axis, start=0):
         axis += n
     if start < 0:
         start += n
-    msg = 'rollaxis: %s (%d) must be >=0 and < %d'
+    msg = "'%s' arg requires %d <= %s < %d, but %d was passed in"
     if not (0 <= axis < n):
-        raise ValueError(msg % ('axis', axis, n))
+        raise ValueError(msg % ('axis', -n, 'axis', n, axis))
     if not (0 <= start < n + 1):
-        raise ValueError(msg % ('start', start, n + 1))
-    if (axis < start):
+        raise ValueError(msg % ('start', -n, 'start', n + 1, start))
+    if axis < start:
         # it's been removed
         start -= 1
     if axis == start:


Test patch:
Repository: numpy/numpy

Issue:
Configuration.add_subpackage fails on Python 3.4
Using numpy 1.11.2 and Python 3.4, trying to run a `setupy.py` script which uses subpackage using numpy.distutil fails when `importlib.machinery` cannot be found in the `npy_load_module` function.

For example using the following `setup.py` and `foo/setup.py` scripts:

``` Python
# setup.py
from numpy.distutils.misc_util import Configuration
from numpy.distutils.core import setup

def configuration():
    config = Configuration(None, '', None)
    config.add_subpackage('foo')
    return config

setup(configuration=configuration)
```

``` Python
# foo/setup.py
def configuration(parent_package='', top_path=None):
    from numpy.distutils.misc_util import Configuration
    config = Configuration('foo', parent_package, top_path)
    return config
```

Attempting to build the package:

```
$ python setup.py build_ext -i
Traceback (most recent call last):
  File "setup.py", line 10, in <module>
    setup(configuration=configuration)
  File "/Users/jhelmus/anaconda/envs/py34/lib/python3.4/site-packages/numpy/distutils/core.py", line 135, in setup
    config = configuration()
  File "setup.py", line 7, in configuration
    config.add_subpackage('foo')
  File "/Users/jhelmus/anaconda/envs/py34/lib/python3.4/site-packages/numpy/distutils/misc_util.py", line 1000, in add_subpackage
    caller_level = 2)
  File "/Users/jhelmus/anaconda/envs/py34/lib/python3.4/site-packages/numpy/distutils/misc_util.py", line 969, in get_subpackage
    caller_level = caller_level + 1)
  File "/Users/jhelmus/anaconda/envs/py34/lib/python3.4/site-packages/numpy/distutils/misc_util.py", line 882, in _get_configuration_from_setup_py
    ('.py', 'U', 1))
  File "/Users/jhelmus/anaconda/envs/py34/lib/python3.4/site-packages/numpy/compat/py3k.py", line 112, in npy_load_module
    return importlib.machinery.SourceFileLoader(name, fn).load_module()
AttributeError: 'module' object has no attribute 'machinery'
```

This works in Python 3.5 and 2.7 and with earlier versions of NumPy prior to the addition of `npy_load_module`.  

This bug can likely be fixed by adding `import importlib` to the `npy_load_module`.  I will submit a PR shortly.

A workaround is to `import importlib.machinery` somewhere in the root `setup.py` file.



Discussion:

Resolving patch:
diff --git a/numpy/compat/py3k.py b/numpy/compat/py3k.py
--- a/numpy/compat/py3k.py
+++ b/numpy/compat/py3k.py
@@ -118,7 +118,7 @@ def npy_load_module(name, fn, info=None):
         mod : module
 
         """
-        import importlib
+        import importlib.machinery
         return importlib.machinery.SourceFileLoader(name, fn).load_module()
 else:
     def npy_load_module(name, fn, info=None):


Test patch:
Repository: numpy/numpy

Issue:
small spelling error issue
On this website it says "Mote that" , but it should be "Note that" with a capital "N".

thank you,
Maria

http://docs.scipy.org/doc/numpy/reference/generated/numpy.genfromtxt.html

under source code line 1276



Discussion:

Resolving patch:
diff --git a/numpy/lib/npyio.py b/numpy/lib/npyio.py
--- a/numpy/lib/npyio.py
+++ b/numpy/lib/npyio.py
@@ -1329,7 +1329,7 @@ def genfromtxt(fname, dtype=float, comments='#', delimiter=None,
     ----------
     fname : file, str, pathlib.Path, list of str, generator
         File, filename, list, or generator to read.  If the filename
-        extension is `.gz` or `.bz2`, the file is first decompressed. Mote
+        extension is `.gz` or `.bz2`, the file is first decompressed. Note
         that generators must return byte strings in Python 3k.  The strings
         in a list or produced by a generator are treated as lines.
     dtype : dtype, optional


Test patch:
Repository: numpy/numpy

Issue:
ediff1d performance
ediff1d is unexpectedly slow.  Initially I thought it was due to an unneeded copy operation (I was calling it with to_begin).  Then I noticed that a flat iterator is much slower than a ravel array, which was the main reason for slower than expected performance.  I plan on submitting a pull request to address this.



Discussion:

Resolving patch:
diff --git a/numpy/lib/arraysetops.py b/numpy/lib/arraysetops.py
--- a/numpy/lib/arraysetops.py
+++ b/numpy/lib/arraysetops.py
@@ -78,20 +78,33 @@ def ediff1d(ary, to_end=None, to_begin=None):
     array([ 1,  2, -3,  5, 18])
 
     """
-    ary = np.asanyarray(ary).flat
-    ed = ary[1:] - ary[:-1]
-    arrays = [ed]
-    if to_begin is not None:
-        arrays.insert(0, to_begin)
-    if to_end is not None:
-        arrays.append(to_end)
-
-    if len(arrays) != 1:
-        # We'll save ourselves a copy of a potentially large array in
-        # the common case where neither to_begin or to_end was given.
-        ed = np.hstack(arrays)
-
-    return ed
+    # force a 1d array
+    ary = np.asanyarray(ary).ravel()
+
+    # get the length of the diff'd values
+    l = len(ary) - 1
+    if l < 0:
+        # force length to be non negative, match previous API
+        # should this be an warning or deprecated?
+        l = 0
+
+    if to_begin is None:
+        to_begin = np.array([])
+    else:
+        to_begin = np.asanyarray(to_begin).ravel()
+
+    if to_end is None:
+        to_end = np.array([])
+    else:
+        to_end = np.asanyarray(to_end).ravel()
+
+    # do the calculation in place and copy to_begin and to_end
+    result = np.empty(l + len(to_begin) + len(to_end), dtype=ary.dtype)
+    result[:len(to_begin)] = to_begin
+    result[len(to_begin) + l:] = to_end
+    np.subtract(ary[1:], ary[:-1], result[len(to_begin):len(to_begin) + l])
+    return result
+
 
 def unique(ar, return_index=False, return_inverse=False, return_counts=False):
     """


Test patch:
diff --git a/numpy/lib/tests/test_arraysetops.py b/numpy/lib/tests/test_arraysetops.py
--- a/numpy/lib/tests/test_arraysetops.py
+++ b/numpy/lib/tests/test_arraysetops.py
@@ -169,6 +169,12 @@ def test_ediff1d(self):
         assert_array_equal([-1, 0], ediff1d(zero_elem, to_begin=-1, to_end=0))
         assert_array_equal([], ediff1d(one_elem))
         assert_array_equal([1], ediff1d(two_elem))
+        assert_array_equal([7,1,9], ediff1d(two_elem, to_begin=7, to_end=9))
+        assert_array_equal([5,6,1,7,8], ediff1d(two_elem, to_begin=[5,6], to_end=[7,8]))
+        assert_array_equal([1,9], ediff1d(two_elem, to_end=9))
+        assert_array_equal([1,7,8], ediff1d(two_elem, to_end=[7,8]))
+        assert_array_equal([7,1], ediff1d(two_elem, to_begin=7))
+        assert_array_equal([5,6,1], ediff1d(two_elem, to_begin=[5,6]))
 
     def test_in1d(self):
         # we use two different sizes for the b array here to test the
Repository: numpy/numpy

Issue:
numpy.frombuffer documentation
Clarify in the documentation that the offset parameter is in bytes (not samples)



Discussion:

Resolving patch:
diff --git a/numpy/add_newdocs.py b/numpy/add_newdocs.py
--- a/numpy/add_newdocs.py
+++ b/numpy/add_newdocs.py
@@ -1126,7 +1126,7 @@ def luf(lamdaexpr, *args, **kwargs):
     count : int, optional
         Number of items to read. ``-1`` means all data in the buffer.
     offset : int, optional
-        Start reading the buffer from this offset; default: 0.
+        Start reading the buffer from this offset (in bytes); default: 0.
 
     Notes
     -----
diff --git a/numpy/core/shape_base.py b/numpy/core/shape_base.py
--- a/numpy/core/shape_base.py
+++ b/numpy/core/shape_base.py
@@ -21,7 +21,7 @@ def atleast_1d(*arys):
     Returns
     -------
     ret : ndarray
-        An array, or sequence of arrays, each with ``a.ndim >= 1``.
+        An array, or list of arrays, each with ``a.ndim >= 1``.
         Copies are made only if necessary.
 
     See Also
@@ -72,7 +72,7 @@ def atleast_2d(*arys):
     Returns
     -------
     res, res2, ... : ndarray
-        An array, or tuple of arrays, each with ``a.ndim >= 2``.
+        An array, or list of arrays, each with ``a.ndim >= 2``.
         Copies are avoided where possible, and views with two or more
         dimensions are returned.
 
@@ -124,7 +124,7 @@ def atleast_3d(*arys):
     Returns
     -------
     res1, res2, ... : ndarray
-        An array, or tuple of arrays, each with ``a.ndim >= 3``.  Copies are
+        An array, or list of arrays, each with ``a.ndim >= 3``.  Copies are
         avoided where possible, and views with three or more dimensions are
         returned.  For example, a 1-D array of shape ``(N,)`` becomes a view
         of shape ``(1, N, 1)``, and a 2-D array of shape ``(M, N)`` becomes a


Test patch:
Repository: numpy/numpy

Issue:
doc: dead links
As mentioned in https://github.com/numpy/numpy/issues/5811#issuecomment-97124230 the page http://docs.scipy.org/doc/numpy/reference/generated/numpy.random.vonmises.html has some dead links.



Discussion:
@argriffing Those links are broken for all the distributions and probably don't belong there at all.

@charris Does this mean that the broken links to the scipy stats module should be removed for all the numpy stats distributions in the documentation?

Hmm, I think the links to scipy.stats distributions with the same name do have value. I'd rather see them fixed up. Can't be too hard.


Resolving patch:
diff --git a/doc/source/conf.py b/doc/source/conf.py
--- a/doc/source/conf.py
+++ b/doc/source/conf.py
@@ -201,6 +201,7 @@
 # -----------------------------------------------------------------------------
 intersphinx_mapping = {
     'python': ('https://docs.python.org/dev', None),
+    'scipy': ('https://docs.scipy.org/doc/scipy/reference', None),
     'matplotlib': ('http://matplotlib.org', None)
 }
 


Test patch:
Repository: numpy/numpy

Issue:
ENH: frompyfunc set user specified identity attribute
frompyfunc does not allow the ufunc's identity to be specified, and that attribute of the returned object is not writable, so it is always None.  Please add a kwarg to set the function's identity.  This is especially valuable if the ufunc will be used with the reduce family of methods.  Thank you.

It looks straightforward [here](https://github.com/numpy/numpy/blob/master/numpy/core/src/umath/umathmodule.c#L86).  If this sounds reasonable I'll try and do it


Discussion:

Resolving patch:
diff --git a/numpy/core/_add_newdocs.py b/numpy/core/_add_newdocs.py
--- a/numpy/core/_add_newdocs.py
+++ b/numpy/core/_add_newdocs.py
@@ -4230,7 +4230,7 @@
 
 add_newdoc('numpy.core.umath', 'frompyfunc',
     """
-    frompyfunc(func, nin, nout)
+    frompyfunc(func, nin, nout, *[, identity])
 
     Takes an arbitrary Python function and returns a NumPy ufunc.
 
@@ -4245,6 +4245,13 @@
         The number of input arguments.
     nout : int
         The number of objects returned by `func`.
+    identity : object, optional
+        The value to use for the `~numpy.ufunc.identity` attribute of the resulting
+        object. If specified, this is equivalent to setting the underlying
+        C ``identity`` field to ``PyUFunc_IdentityValue``.
+        If omitted, the identity is set to ``PyUFunc_None``. Note that this is
+        _not_ equivalent to setting the identity to ``None``, which implies the
+        operation is reorderable.
 
     Returns
     -------


Test patch:
diff --git a/numpy/core/tests/test_umath.py b/numpy/core/tests/test_umath.py
--- a/numpy/core/tests/test_umath.py
+++ b/numpy/core/tests/test_umath.py
@@ -2876,6 +2876,32 @@ def __new__(subtype, shape):
         a = simple((3, 4))
         assert_equal(a+a, a)
 
+
+class TestFrompyfunc(object):
+
+    def test_identity(self):
+        def mul(a, b):
+            return a * b
+
+        # with identity=value
+        mul_ufunc = np.frompyfunc(mul, nin=2, nout=1, identity=1)
+        assert_equal(mul_ufunc.reduce([2, 3, 4]), 24)
+        assert_equal(mul_ufunc.reduce(np.ones((2, 2)), axis=(0, 1)), 1)
+        assert_equal(mul_ufunc.reduce([]), 1)
+
+        # with identity=None (reorderable)
+        mul_ufunc = np.frompyfunc(mul, nin=2, nout=1, identity=None)
+        assert_equal(mul_ufunc.reduce([2, 3, 4]), 24)
+        assert_equal(mul_ufunc.reduce(np.ones((2, 2)), axis=(0, 1)), 1)
+        assert_raises(ValueError, lambda: mul_ufunc.reduce([]))
+
+        # with no identity (not reorderable)
+        mul_ufunc = np.frompyfunc(mul, nin=2, nout=1)
+        assert_equal(mul_ufunc.reduce([2, 3, 4]), 24)
+        assert_raises(ValueError, lambda: mul_ufunc.reduce(np.ones((2, 2)), axis=(0, 1)))
+        assert_raises(ValueError, lambda: mul_ufunc.reduce([]))
+
+
 def _check_branch_cut(f, x0, dx, re_sign=1, im_sign=-1, sig_zero_ok=False,
                       dtype=complex):
     """
Repository: numpy/numpy

Issue:
numpy.loadtxt returns string repr of bytestring instead of string in Python 3
Numpy version 1.11.1
Python version 2.7.12/3.5.1

When reading strings from a data file with numpy.loadtxt() in Python 3 the returned strings are string representations of bytestrings. In Python 2 normal strings are returned.

MWE:

``` python
from __future__ import print_function
import numpy as n

strings = ['str1', 'str2']
parsed = n.loadtxt(strings, dtype='str')
print('Result:', parsed)

```

which, when executed, gives different results for Py2 and Py3.

```
$> python2 mwe.py 
Result: ['str1' 'str2']
$> python3 mwe.py 
Result: ["b'str1'" "b'str2'"]
```

Python 2 gives strings as expected, Python 3 gives strings containing the string representation of bytestrings.

Workarounds have been suggested at http://stackoverflow.com/q/39371467/912307



Discussion:
Having this issue as well, where something like parsed[0][0] == "b" and parsed[0][1] == "'" is happening across all entries returned by loadtxt

Resolving patch:
diff --git a/numpy/lib/npyio.py b/numpy/lib/npyio.py
--- a/numpy/lib/npyio.py
+++ b/numpy/lib/npyio.py
@@ -702,9 +702,9 @@ def floatconv(x):
     elif issubclass(typ, np.complex):
         return lambda x: complex(asstr(x))
     elif issubclass(typ, np.bytes_):
-        return bytes
+        return asbytes
     else:
-        return str
+        return asstr
 
 
 def loadtxt(fname, dtype=float, comments='#', delimiter=None,


Test patch:
diff --git a/numpy/lib/tests/test_io.py b/numpy/lib/tests/test_io.py
--- a/numpy/lib/tests/test_io.py
+++ b/numpy/lib/tests/test_io.py
@@ -686,6 +686,15 @@ def test_3d_shaped_dtype(self):
                      dtype=dt)
         assert_array_equal(x, a)
 
+    def test_str_dtype(self):
+        # see gh-8033
+        c = ["str1", "str2"]
+
+        for dt in (str, np.bytes_):
+            a = np.array(["str1", "str2"], dtype=dt)
+            x = np.loadtxt(c, dtype=dt)
+            assert_array_equal(x, a)
+
     def test_empty_file(self):
         with suppress_warnings() as sup:
             sup.filter(message="loadtxt: Empty input file:")
Repository: numpy/numpy

Issue:
fftpack: bug in `norm='ortho'`for real-valued FFT and non-default size
The scaling in `np.fft.rfft` appears to be incorrect if `norm='ortho'` and the size argument, `n`, is not equal to the array size (or None).

For example:
```python
np.fft.irfft(np.fft.rfft([1, 1], n=4, norm='ortho'), n=4, norm='ortho')
```
gives
```
array([ 1.41421356,  1.41421356,  0.        ,  0.        ])
```
while one would expect
```
array([ 1.,  1.,  0.,  0.])
```

This bug affects the `rfft*` routines.  `fft*` and `hfft` are correct as-is.

I will submit a PR with a test and fix shortly



Discussion:

Resolving patch:
diff --git a/numpy/fft/fftpack.py b/numpy/fft/fftpack.py
--- a/numpy/fft/fftpack.py
+++ b/numpy/fft/fftpack.py
@@ -371,7 +371,9 @@ def rfft(a, n=None, axis=-1, norm=None):
     output = _raw_fft(a, n, axis, fftpack.rffti, fftpack.rfftf,
                       _real_fft_cache)
     if _unitary(norm):
-        output *= 1 / sqrt(a.shape[axis])
+        if n is None:
+            n = a.shape[axis]
+        output *= 1 / sqrt(n)
     return output
 
 


Test patch:
diff --git a/numpy/fft/tests/test_fftpack.py b/numpy/fft/tests/test_fftpack.py
--- a/numpy/fft/tests/test_fftpack.py
+++ b/numpy/fft/tests/test_fftpack.py
@@ -71,9 +71,13 @@ def test_ifftn(self):
 
     def test_rfft(self):
         x = random(30)
-        assert_array_almost_equal(np.fft.fft(x)[:16], np.fft.rfft(x))
-        assert_array_almost_equal(np.fft.rfft(x) / np.sqrt(30),
-                                  np.fft.rfft(x, norm="ortho"))
+        for n in [x.size, 2*x.size]:
+            for norm in [None, 'ortho']:
+                assert_array_almost_equal(
+                    np.fft.fft(x, n=n, norm=norm)[:(n//2 + 1)],
+                    np.fft.rfft(x, n=n, norm=norm))
+            assert_array_almost_equal(np.fft.rfft(x, n=n) / np.sqrt(n),
+                                      np.fft.rfft(x, n=n, norm="ortho"))
 
     def test_irfft(self):
         x = random(30)
@@ -122,6 +126,24 @@ def test_ihttf(self):
             x_herm, np.fft.ihfft(np.fft.hfft(x_herm, norm="ortho"),
                                  norm="ortho"))
 
+    def test_all_1d_norm_preserving(self):
+        # verify that round-trip transforms are norm-preserving
+        x = random(30)
+        x_norm = np.linalg.norm(x)
+        n = x.size * 2
+        func_pairs = [(np.fft.fft, np.fft.ifft),
+                      (np.fft.rfft, np.fft.irfft),
+                      # hfft: order so the first function takes x.size samples
+                      #       (necessary for comparison to x_norm above)
+                      (np.fft.ihfft, np.fft.hfft),
+                      ]
+        for forw, back in func_pairs:
+            for n in [x.size, 2*x.size]:
+                for norm in [None, 'ortho']:
+                    tmp = forw(x, n=n, norm=norm)
+                    tmp = back(tmp, n=n, norm=norm)
+                    assert_array_almost_equal(x_norm,
+                                              np.linalg.norm(tmp))
 
 class TestFFTThreadSafe(TestCase):
     threads = 16