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

Issue:
np.floor and np.ceil should call __floor__ and __ceil__ on object arrays



Discussion:

Resolving patch:
diff --git a/numpy/core/code_generators/generate_umath.py b/numpy/core/code_generators/generate_umath.py
--- a/numpy/core/code_generators/generate_umath.py
+++ b/numpy/core/code_generators/generate_umath.py
@@ -763,14 +763,14 @@ def english_upper(s):
           docstrings.get('numpy.core.umath.ceil'),
           None,
           TD(flts, f='ceil', astype={'e':'f'}),
-          TD(P, f='ceil'),
+          TD(O, f='npy_ObjectCeil'),
           ),
 'trunc':
     Ufunc(1, 1, None,
           docstrings.get('numpy.core.umath.trunc'),
           None,
           TD(flts, f='trunc', astype={'e':'f'}),
-          TD(P, f='trunc'),
+          TD(O, f='npy_ObjectTrunc'),
           ),
 'fabs':
     Ufunc(1, 1, None,
@@ -784,7 +784,7 @@ def english_upper(s):
           docstrings.get('numpy.core.umath.floor'),
           None,
           TD(flts, f='floor', astype={'e':'f'}),
-          TD(P, f='floor'),
+          TD(O, f='npy_ObjectFloor'),
           ),
 'rint':
     Ufunc(1, 1, None,


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
@@ -5,6 +5,7 @@
 import fnmatch
 import itertools
 import pytest
+from fractions import Fraction
 
 import numpy.core.umath as ncu
 from numpy.core import _umath_tests as ncu_tests
@@ -2460,6 +2461,42 @@ def test_builtin_long(self):
         assert_equal(np.gcd(2**100, 3**100), 1)
 
 
+class TestRoundingFunctions(object):
+
+    def test_object_direct(self):
+        """ test direct implementation of these magic methods """
+        class C:
+            def __floor__(self):
+                return 1
+            def __ceil__(self):
+                return 2
+            def __trunc__(self):
+                return 3
+
+        arr = np.array([C(), C()])
+        assert_equal(np.floor(arr), [1, 1])
+        assert_equal(np.ceil(arr),  [2, 2])
+        assert_equal(np.trunc(arr), [3, 3])
+
+    def test_object_indirect(self):
+        """ test implementations via __float__ """
+        class C:
+            def __float__(self):
+                return -2.5
+
+        arr = np.array([C(), C()])
+        assert_equal(np.floor(arr), [-3, -3])
+        assert_equal(np.ceil(arr),  [-2, -2])
+        with pytest.raises(TypeError):
+            np.trunc(arr)  # consistent with math.trunc
+
+    def test_fraction(self):
+        f = Fraction(-4, 3)
+        assert_equal(np.floor(f), -2)
+        assert_equal(np.ceil(f), -1)
+        assert_equal(np.trunc(f), -1)
+
+
 class TestComplexFunctions(object):
     funcs = [np.arcsin,  np.arccos,  np.arctan, np.arcsinh, np.arccosh,
              np.arctanh, np.sin,     np.cos,    np.tan,     np.exp,
Repository: numpy/numpy

Issue:
numpy.angle shouldn't return negative values according to documentation?
I was surprised that numpy.angle returns negative values.

The documentation for [numpy.angle](http://docs.scipy.org/doc/numpy-1.10.0/reference/generated/numpy.angle.html) says:

> The **counterclockwise** angle from the positive real axis on the complex plane ..

This means the values should go from 0 to (2pi).

But that is not what happens. For example: 

> numpy.angle( 1 - 1j )
> **-0.78539816339744828**

I believe this should be that value plus (2pi) or **5.497787143782138**

If I am wrong, I believe the documentation should be clarified to give the intended output range as **(-pi, +pi]**



Discussion:
anyone want to discuss ways to fix this? I don't have the coding skills but could help with the maths side...

The right fix is probably to just change the docs.  The function is just a wrapper around `np.arctan2`.

@eric-wieser @makeyourownneuralnetwork the doc doesn't seem to be fixed yet. I'd recommend reopen the issue until it's actually fixed.

Resolving patch:
diff --git a/numpy/lib/function_base.py b/numpy/lib/function_base.py
--- a/numpy/lib/function_base.py
+++ b/numpy/lib/function_base.py
@@ -1429,8 +1429,8 @@ def angle(z, deg=False):
     Returns
     -------
     angle : ndarray or scalar
-        The counterclockwise angle from the positive real axis on
-        the complex plane, with dtype as numpy.float64.
+        The counterclockwise angle from the positive real axis on the complex
+        plane in the range ``(-pi, pi]``, with dtype as numpy.float64.
 
         ..versionchanged:: 1.16.0
             This function works on subclasses of ndarray like `ma.array`.


Test patch:
Repository: numpy/numpy

Issue:
Azure no longer passes on 32 bit linux.
See https://dev.azure.com/numpy/numpy/_build/results?buildId=3152. Probably related to the failing PR #13336. @mattip Could you take a look?




Discussion:

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -79,7 +79,7 @@ def _minimal_ext_cmd(cmd):
     try:
         out = _minimal_ext_cmd(['git', 'rev-parse', 'HEAD'])
         GIT_REVISION = out.strip().decode('ascii')
-    except subprocess.SubprocessError:
+    except (subprocess.SubprocessError, OSError):
         GIT_REVISION = "Unknown"
 
     return GIT_REVISION


Test patch:
Repository: numpy/numpy

Issue:
"Modulus" refers to normalizing by largest singular value in docs
https://github.com/numpy/numpy/blob/33415905e85c51c3348c1def9dfa306fbd358b5e/numpy/linalg/linalg.py#L1903-L1904

^ This code from master corresponds to the documentation for [numpy.linalg.pinv](https://docs.scipy.org/doc/numpy/reference/generated/numpy.linalg.pinv.html?highlight=modulus):

> Singular values smaller (in modulus) than _rcond * largest_singular_value_ (again, in modulus) are set to zero.

Note that singular values cannot be complex. They are always real and non-negative. And so this is a confusing use of the term "modulus" to me. From what I can see, the singular values are normalized by the largest value. For example, if `s = [2. 1. 0.]` and `rcond = 1e-15`, then `cutoff = 2e-15` and so `s > cutoff` is effectively normalizing `s` by the largest singular value (2) before comparing to `rcond` (i.e., by cross-multiplying).

https://github.com/numpy/numpy/blob/33415905e85c51c3348c1def9dfa306fbd358b5e/numpy/linalg/linalg.py#L1968-L1969

Perhaps I misunderstand the usage of this term, but I think it would be more appropriate to say something like...?

> Singular values smaller than rcond (normalized such that the largest singular value is one) are set to zero.




Discussion:
I think you are correct. Would you like to submit a PR making corrections?
Sure! I realized after that my suggestion isn't perfect because of the degenerate case of all zero singular values, but I'll put something quick together.

Resolving patch:
diff --git a/numpy/linalg/linalg.py b/numpy/linalg/linalg.py
--- a/numpy/linalg/linalg.py
+++ b/numpy/linalg/linalg.py
@@ -1900,9 +1900,9 @@ def pinv(a, rcond=1e-15, hermitian=False):
         Matrix or stack of matrices to be pseudo-inverted.
     rcond : (...) array_like of float
         Cutoff for small singular values.
-        Singular values smaller (in modulus) than
-        `rcond` * largest_singular_value (again, in modulus)
-        are set to zero. Broadcasts against the stack of matrices
+        Singular values less than or equal to
+        ``rcond * largest_singular_value`` are set to zero.
+        Broadcasts against the stack of matrices.
     hermitian : bool, optional
         If True, `a` is assumed to be Hermitian (symmetric if real-valued),
         enabling a more efficient method for finding singular values.


Test patch:
Repository: numpy/numpy

Issue:
Docs are unclear about behavior of `nonzero` on zero-dim arrays.
<!-- Please describe the issue in detail here, and fill in the fields below -->

From the docs, I would expect `nonzero` on a zero-dim array to return an empty tuple:

> Returns a tuple of arrays, one for each dimension of a, containing the indices of the non-zero elements in that dimension.

### Reproducing code example:

```python
>>> np.array(5).ndim
0
>>> len(np.array(5).nonzero())
1
```



Discussion:
cc @mwiebe who (as far as I can tell from git blame) implemented nonzero
You're right that the current behavior is wrong, but I don't think there's a sensible choice to make here.
```python
>>> np.array([[True]]).nonzero()
(array([0], dtype=int64), array([0], dtype=int64))
>>> np.array([[False]]).nonzero()
(array([], dtype=int64), array([], dtype=int64))
```
```python
>>> np.array([True]).nonzero()
(array([0], dtype=int64),)
>>> np.array([False]).nonzero()
(array([], dtype=int64),)
```
```python
>>> np.array(True).nonzero()
(array([0], dtype=int64),)
>>> np.array(False).nonzero()
(array([], dtype=int64),)
```

Perhaps `nonzero` should just throw an exception if called on a 0d array?
One thing to think about is what should `a[a.nonzero()]` return in each case? (`a=np.array(0)` and `a=np.array(5)`)
@umanwizard: The simple answer is "never use `x[y.nonzero()]`, use `x[y.astype(bool)]` instead"
@eric-wieser Should we change the docs informing the above as part of NOTE ?
That sounds like a good idea, although you could probably use more helpful phrasing than I used above.
Got it. @umanwizard Can you please tell the docs location so that I could proceed 
Sorry, I don't work on Numpy, I am not sure where the docs are in the repository.
It lives in the docstring for `nonzero` in `numpy/core/fromnumeric.py`. See also [how to document](http://www.numpy.org/devdocs/docs/index.html)

Resolving patch:
diff --git a/numpy/core/fromnumeric.py b/numpy/core/fromnumeric.py
--- a/numpy/core/fromnumeric.py
+++ b/numpy/core/fromnumeric.py
@@ -1795,6 +1795,11 @@ def nonzero(a):
         Equivalent ndarray method.
     count_nonzero :
         Counts the number of non-zero elements in the input array.
+        
+    Notes
+    -----
+    To obtain the non-zero values, it is recommended to use ``x[x.astype(bool)]`` 
+    which will correctly handle 0-d arrays. 
 
     Examples
     --------


Test patch:
Repository: numpy/numpy

Issue:
DOC: expand_dims returns a view
Hi,

if we apply expand_dims to a numpy array 'a' :
b = numpy.expand_dims(a, axis=0)
the 'b' is not a new array, it will be a link to the objects 'a'

is it correct behavior?
if so, it should be noted in the manual

thanks!


Discussion:
Certainly intended. But the documentation could indeed mention that it returns a view (both in the summery and for the return array probably). Want to create a pull request?

Resolving patch:
diff --git a/numpy/lib/shape_base.py b/numpy/lib/shape_base.py
--- a/numpy/lib/shape_base.py
+++ b/numpy/lib/shape_base.py
@@ -532,8 +532,7 @@ def expand_dims(a, axis):
     Returns
     -------
     res : ndarray
-        Output array. The number of dimensions is one greater than that of
-        the input array.
+        View of `a` with the number of dimensions increased by one.
 
     See Also
     --------


Test patch:
Repository: numpy/numpy

Issue:
Minor documentation error in np.take_along_axis
There is a minor mistake in the documentation of [`np.take_along_axis`](https://docs.scipy.org/doc/numpy/reference/generated/numpy.take_along_axis.html). In the "Notes" section there is a snippet functionally equivalent to the function that begins with:

```python
Ni, M, Nk = a.shape[:axis], a.shape[axis], a.shape[axis+1:]
J = indices.shape[axis]  # Need not equal M
out = np.empty(Nk + (J,) + Nk)
```

As I understand it, the definition of `out` should be:

````python
out = np.empty(Ni + (J,) + Nk)
````

With the initial `Nk` replaced by `Ni`.

### Reproducing code example

NA

### Error message

NA

### Numpy/Python version information:

1.16.1

Minor documentation error in np.take_along_axis
There is a minor mistake in the documentation of [`np.take_along_axis`](https://docs.scipy.org/doc/numpy/reference/generated/numpy.take_along_axis.html). In the "Notes" section there is a snippet functionally equivalent to the function that begins with:

```python
Ni, M, Nk = a.shape[:axis], a.shape[axis], a.shape[axis+1:]
J = indices.shape[axis]  # Need not equal M
out = np.empty(Nk + (J,) + Nk)
```

As I understand it, the definition of `out` should be:

````python
out = np.empty(Ni + (J,) + Nk)
````

With the initial `Nk` replaced by `Ni`.

### Reproducing code example

NA

### Error message

NA

### Numpy/Python version information:

1.16.1



Discussion:
Looks right, thanks. Want to create a PR to fix it? For such small things, the edit button on the file on github is even fine.
Looks right, thanks. Want to create a PR to fix it? For such small things, the edit button on the file on github is even fine.

Resolving patch:
diff --git a/numpy/lib/shape_base.py b/numpy/lib/shape_base.py
--- a/numpy/lib/shape_base.py
+++ b/numpy/lib/shape_base.py
@@ -94,7 +94,7 @@ def take_along_axis(arr, indices, axis):
 
         Ni, M, Nk = a.shape[:axis], a.shape[axis], a.shape[axis+1:]
         J = indices.shape[axis]  # Need not equal M
-        out = np.empty(Nk + (J,) + Nk)
+        out = np.empty(Ni + (J,) + Nk)
 
         for ii in ndindex(Ni):
             for kk in ndindex(Nk):


Test patch:
Repository: numpy/numpy

Issue:
DOC: numpy.random.sample and numpy.random.random_sample
I just noticed in the docs that the page for `numpy.random.sample` indicates that the function should be called as `numpy.random.random_sample`. I understand that this may just indicate that the function may be called as either `sample` or `random_sample`, but it does come across as a mistake when first viewing the page. Perhaps make it more explicit that `random_sample` is an alias of `sample`? Or is this the accepted practice for functions that have aliases?


Discussion:
This is show this way because:
```python
>>> np.random.random_sample
<function RandomState.random_sample>

>>> np.random.sample
<function RandomState.random_sample>
```

I think flipping the alias would be reasonable
`sample` is just an old backwards-compatibility alias for `random_sample`, which is the authoritative name.
@rkern isn't it better to deprecate `random_sample` in favor of `sample` the same way as it is done with `random_integers`? The `random_` prefix seems excessive - they are already live in `random` module. And   this change also allows to achieve greater consistency in the names across `random` module.
IMO it is almost never worth it to remove API to achieve consistency since this will break existing code and documentation (e.g., tutorials).  

If matching `randint` was the goal, the name would have to be something like `randfloat` which isn't very nice. `sample` and even `random_sample` are particularly clear that one will get a uniform random number on [0,1).  `uniform` is the probably the clearest, but already taken.
xref #13163 . This is fixed in the randomgen branch, subject to dropping `sample` and `random` and `ranf`
Also contains docstring pointers for ranf and sample.

Resolving patch:
diff --git a/numpy/random/__init__.py b/numpy/random/__init__.py
--- a/numpy/random/__init__.py
+++ b/numpy/random/__init__.py
@@ -141,9 +141,12 @@
     'rand',
     'randint',
     'randn',
+    'random',
     'random_integers',
     'random_sample',
+    'ranf',
     'rayleigh',
+    'sample',
     'seed',
     'set_state',
     'shuffle',
@@ -176,10 +179,6 @@
 __all__ += ['Generator', 'DSFMT', 'MT19937', 'Philox', 'PCG64', 'PCG32',
             'ThreeFry', 'Xoshiro256', 'Xoshiro512', 'RandomState']
 
-# Some aliases:
-ranf = random = sample = random_sample
-__all__.extend(['ranf', 'random', 'sample'])
-
 
 def __RandomState_ctor():
     """Return a RandomState instance.


Test patch:
Repository: numpy/numpy

Issue:
Dtype.base attribute not documented
dtype instances have a `base` attribute that, I think, is meant to be the "base dtype" for subarrays. It is, however, not documented, leading to hesitation with and confusion about its use.  See
https://stackoverflow.com/questions/52476601/purpose-status-of-the-attribute-numpy-dtype-base and https://github.com/astropy/astropy/pull/8353#issuecomment-454945823

My sense is that it is useful and should just be documented properly.


Discussion:
I've found myself using `.subdtype` instead, which contains the same info
I think base also means something different for structured types, especially weird ones like `dtype((int, [('a', int)]))`
`base` has the advantage over `subdtype` that it is also defined for dtypes, so if one just cares about the type of data and not its shape (as in the astropy issue), then it is easier.

Of course, main point here is that any exposed attribute should be documented (even if we decide one better not use it!)

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
@@ -5621,6 +5621,41 @@
     then the extra dimensions implied by *shape* are tacked on to
     the end of the retrieved array.
 
+    See Also
+    --------
+    dtype.base
+
+    Examples
+    --------
+    >>> x = numpy.dtype('8f')
+    >>> x.subdtype
+    (dtype('float32'), (8,))
+
+    >>> x =  numpy.dtype('i2')
+    >>> x.subdtype
+    >>>
+
+    """))
+
+add_newdoc('numpy.core.multiarray', 'dtype', ('base',
+    """
+    Returns dtype for the base element of the subarrays,
+    regardless of their dimension or shape.
+
+    See Also
+    --------
+    dtype.subdtype
+
+    Examples
+    --------
+    >>> x = numpy.dtype('8f')
+    >>> x.base
+    dtype('float32')
+
+    >>> x =  numpy.dtype('i2')
+    >>> x.base
+    dtype('int16')
+
     """))
 
 add_newdoc('numpy.core.multiarray', 'dtype', ('type',


Test patch:
Repository: numpy/numpy

Issue:
DOC: Merge together DISTUTILS.rst.txt#template-files" and distutils.rst#conversion-of-src-files
A follow-up to #11689.

These two sections describe the same distutils feature, but in different ways. It would be good to unify them.


Discussion:
The two sections are rendered [here](http://www.numpy.org/devdocs/reference/distutils_guide.html#template-files) and [here](http://www.numpy.org/devdocs/reference/distutils.html#other-files)
@mattip Can I start working on this!
@aashuli go for it. Reference this issue in the PR so a link shows up here letting other people know it is underway.

Resolving patch:
diff --git a/doc/source/conf.py b/doc/source/conf.py
--- a/doc/source/conf.py
+++ b/doc/source/conf.py
@@ -364,3 +364,20 @@ def linkcode_resolve(domain, info):
         return "https://github.com/numpy/numpy/blob/v%s/numpy/%s%s" % (
            numpy.__version__, fn, linespec)
 
+from pygments.lexers import CLexer
+from pygments import token
+from sphinx.highlighting import lexers
+import copy
+
+class NumPyLexer(CLexer):
+    name = 'NUMPYLEXER'
+
+    tokens = copy.deepcopy(lexers['c'].tokens)
+    # Extend the regex for valid identifiers with @
+    for k, val in tokens.items():
+        for i, v in enumerate(val):
+            if isinstance(v, tuple):
+                if isinstance(v[0], str):
+                    val[i] =  (v[0].replace('a-zA-Z', 'a-zA-Z@'),) + v[1:]
+
+lexers['NumPyC'] = NumPyLexer(stripnl=False)


Test patch:
Repository: numpy/numpy

Issue:
Do not force 128-bit emulation for PCG64
I noticed that we are [forcing 128-bit arithmetic emulation](https://github.com/numpy/numpy/blob/master/numpy/random/setup.py#L61) even when it could be supported. I assume this was a temporary measure, but `pcg64.h` appears to not be written correctly without emulation for some reason. @bashtage @mattip Can you clarify?


Discussion:

Resolving patch:
diff --git a/numpy/random/setup.py b/numpy/random/setup.py
--- a/numpy/random/setup.py
+++ b/numpy/random/setup.py
@@ -58,9 +58,8 @@ def generate_libraries(ext, build_dir):
     # Use legacy integer variable sizes
     LEGACY_DEFS = [('NP_RANDOM_LEGACY', '1')]
     PCG64_DEFS = []
-    if 1 or sys.maxsize < 2 ** 32 or os.name == 'nt':
-        # Force emulated mode here
-        PCG64_DEFS += [('PCG_FORCE_EMULATED_128BIT_MATH', '1')]
+    # One can force emulated 128-bit arithmetic if one wants.
+    #PCG64_DEFS += [('PCG_FORCE_EMULATED_128BIT_MATH', '1')]
 
     config.add_extension('entropy',
                          sources=['entropy.c', 'src/entropy/entropy.c'] +


Test patch:
Repository: numpy/numpy

Issue:
Quickstart guide recommends np.set_printoptions(threshold=np.nan), which fails
We should update [this guide](https://github.com/eric-wieser/numpy/blob/master/doc/source/user/quickstart.rst#printing-arrays) to use `sys.maxsize`.

@mattip, I'm correct in assuming you prefer that to np.inf?


Discussion:
yes, and it should be mentioned as the preferred `max` value in the [docstring](https://github.com/eric-wieser/numpy/blob/master/numpy/core/arrayprint.py#L106) as well

Resolving patch:
diff --git a/numpy/core/arrayprint.py b/numpy/core/arrayprint.py
--- a/numpy/core/arrayprint.py
+++ b/numpy/core/arrayprint.py
@@ -114,6 +114,7 @@ def set_printoptions(precision=None, threshold=None, edgeitems=None,
     threshold : int, optional
         Total number of array elements which trigger summarization
         rather than full repr (default 1000).
+        To always use the full repr without summarization, pass `sys.maxsize`.
     edgeitems : int, optional
         Number of array items in summary at beginning and end of
         each dimension (default 3).


Test patch:
Repository: numpy/numpy

Issue:
MAINT, TST: bump OpenBLAS for exotic archs
Mostly a reminder to myself to rebuild and generate new link for OpenBLAS binaries on gcc compile farm ppc64le and ARMv8 architectures -- as noted in #14002, currently using `0.3.5` instead of `0.3.7.dev` on those platforms vs. more conventional platforms in our CI.


Discussion:

Resolving patch:
diff --git a/tools/openblas_support.py b/tools/openblas_support.py
--- a/tools/openblas_support.py
+++ b/tools/openblas_support.py
@@ -14,7 +14,7 @@
 import zipfile
 import tarfile
 
-OPENBLAS_V = 'v0.3.5'
+OPENBLAS_V = '6a8b426'
 OPENBLAS_LONG = 'v0.3.5-274-g6a8b4269'
 BASE_LOC = ''
 RACKSPACE = 'https://3f23b170c54c2533c070-1c8a9b3114517dc5fe17b7c3f8c63a43.ssl.cf2.rackcdn.com'
@@ -47,7 +47,7 @@ def download_openblas(target, arch):
         # https://github.com/tylerjereddy/openblas-static-gcc/tree/master/ARMv8
         # build done on GCC compile farm machine named gcc115
         # tarball uploaded manually to an unshared Dropbox location
-        filename = ('https://www.dropbox.com/s/pbqkxzlmih4cky1/'
+        filename = ('https://www.dropbox.com/s/zsp1wb3tq4n9g0b/'
                     'openblas-{}-armv8.tar.gz?dl=1'.format(OPENBLAS_V))
         typ = 'tar.gz'
     elif arch == 'ppc64':
@@ -55,7 +55,7 @@ def download_openblas(target, arch):
         # https://github.com/tylerjereddy/openblas-static-gcc/blob/master/power8
         # built on GCC compile farm machine named gcc112
         # manually uploaded tarball to an unshared Dropbox location
-        filename = ('https://www.dropbox.com/s/zcwhk7c2zptwy0s/'
+        filename = ('https://www.dropbox.com/s/k9uabwoi8bekjwe/'
                     'openblas-{}-ppc64le-power8.tar.gz?dl=1'.format(OPENBLAS_V))
         typ = 'tar.gz'
     elif arch == 'darwin':


Test patch: