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

Issue:
NumPy 1.17 RC fails to compile with Intel C Compile 2016
<!-- Please describe the issue in detail here, and fill in the fields below -->

Compiling NumPy 1.17.0rc2 sources with Intel C Compiler 2016, which does not yet implement `__builtin_cpu_supports("avx512f")` fails with compilation error:

```
icc: numpy/core/src/umath/cpuid.c
numpy/core/src/umath/cpuid.c(63): catastrophic error: invalid use of '__builtin_cpu_supports'
compilation aborted for numpy/core/src/umath/cpuid.c (code 1)
```

Recent Intel C compiler (2019) proceeds just fine.

There is config test to probe compiler for support of `__builtin_cpu_supports`, but the the test does not discriminate between supported arguments.



Discussion:
@mattip This is the issue with 1.17 sources and older compiler that I mentioned at the sprint.

To reproduce I did:
    1. `conda create -n b_np117 -c defaults --override-channels python setuptools cython pip pytest mkl-devel`
    2. `git clone http://github.com/numpy/numpy.git --branch maintenance/1.17.x numpy_src`
    3. `conda activate b_np117`
    4. Edit `site.cfg`. So that
```
(b_np117) [16:15:03 vmlin numpy_src_tmp]$ cat site.cfg
[mkl]
library_dirs = /tmp/miniconda/envs/b_np117/lib
include_dirs = /tmp/miniconda/envs/b_np117/include
lapack_libs = mkl_rt
mkl_libs = mkl_rt
```
5. Check compiler version:
```
(b_np117) [17:02:25 vmlin numpy_src_tmp]$ icc --version
icc (ICC) 16.0.3 20160415
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.
``` 
6. Execute `CFLAGS="-DNDEBUG -I$PREFIX/include $CFLAGS" python setup.py config_cc --compiler=intelem config_fc --fcompiler=intelem build --force build_ext --inplace`
It seems we need someone with that compiler to test and fix this.
I definitely volunteer for testing and fixing it, but I would appreciate some guidance as what to try tweaking and where. 
Pinging @r-devulap, maybe you can have a look/know something? It seems he wrote (or modified it and is also at Intel – albeit a very different part).
@oleksandr-pavlyk could you try this fix from my branch https://github.com/r-devulap/numpy/tree/avx512-cpuid and let me know if that fixes your problem. If it does, I can submit a PR. 
never mind, created a PR with a simpler fix. 

Resolving patch:
diff --git a/numpy/core/setup_common.py b/numpy/core/setup_common.py
--- a/numpy/core/setup_common.py
+++ b/numpy/core/setup_common.py
@@ -138,6 +138,8 @@ def check_api_version(apiversion, codegen_dir):
                        # broken on OSX 10.11, make sure its not optimized away
                        ("volatile int r = __builtin_cpu_supports", '"sse"',
                         "stdio.h", "__BUILTIN_CPU_SUPPORTS"),
+                       ("volatile int r = __builtin_cpu_supports", '"avx512f"',
+                        "stdio.h", "__BUILTIN_CPU_SUPPORTS_AVX512F"),
                        # MMX only needed for icc, but some clangs don't have it
                        ("_m_from_int64", '0', "emmintrin.h"),
                        ("_mm_load_ps", '(float*)0', "xmmintrin.h"),  # SSE


Test patch:
Repository: numpy/numpy

Issue:
SyntaxWarning with Python 3.8
```
>>> import sys, numpy; print(numpy.__version__, sys.version)
C:\Program Files\Python38\lib\site-packages\numpy\ma\core.py:4466: SyntaxWarning: "is" with a literal. Did you mean "=="?
  if self.shape is ():
1.16.4 3.8.0b2 (tags/v3.8.0b2:21dd01d, Jul  4 2019, 16:00:09) [MSC v.1916 64 bit (AMD64)]
```

[Python 3.8](https://docs.python.org/3.8/whatsnew/3.8.html):
> now produces a [SyntaxWarning](https://docs.python.org/3.8/library/exceptions.html#SyntaxWarning) when identity checks (`is` and `is not`) are used with certain types of literals (e.g. strings, ints). These can often work by accident in CPython, but are not guaranteed by the language spec. The warning advises users to use equality tests (`==` and `!=`) instead.

https://bugs.python.org/issue34850, https://github.com/python/cpython/pull/9642, https://github.com/python/cpython/commit/3bcbedc9f1471d957a30a90f9d1251516b422416


Discussion:

Resolving patch:
diff --git a/numpy/ma/core.py b/numpy/ma/core.py
--- a/numpy/ma/core.py
+++ b/numpy/ma/core.py
@@ -4455,7 +4455,7 @@ def count(self, axis=None, keepdims=np._NoValue):
         if m is nomask:
             # compare to _count_reduce_items in _methods.py
 
-            if self.shape is ():
+            if self.shape == ():
                 if axis not in (None, 0):
                     raise np.AxisError(axis=axis, ndim=self.ndim)
                 return 1


Test patch:
Repository: numpy/numpy

Issue:
SyntaxWarning with Python 3.8
```
>>> import sys, numpy; print(numpy.__version__, sys.version)
C:\Program Files\Python38\lib\site-packages\numpy\ma\core.py:4466: SyntaxWarning: "is" with a literal. Did you mean "=="?
  if self.shape is ():
1.16.4 3.8.0b2 (tags/v3.8.0b2:21dd01d, Jul  4 2019, 16:00:09) [MSC v.1916 64 bit (AMD64)]
```

[Python 3.8](https://docs.python.org/3.8/whatsnew/3.8.html):
> now produces a [SyntaxWarning](https://docs.python.org/3.8/library/exceptions.html#SyntaxWarning) when identity checks (`is` and `is not`) are used with certain types of literals (e.g. strings, ints). These can often work by accident in CPython, but are not guaranteed by the language spec. The warning advises users to use equality tests (`==` and `!=`) instead.

https://bugs.python.org/issue34850, https://github.com/python/cpython/pull/9642, https://github.com/python/cpython/commit/3bcbedc9f1471d957a30a90f9d1251516b422416


Discussion:

Resolving patch:
diff --git a/numpy/ma/core.py b/numpy/ma/core.py
--- a/numpy/ma/core.py
+++ b/numpy/ma/core.py
@@ -4450,7 +4450,7 @@ def count(self, axis=None, keepdims=np._NoValue):
         if m is nomask:
             # compare to _count_reduce_items in _methods.py
 
-            if self.shape is ():
+            if self.shape == ():
                 if axis not in (None, 0):
                     raise np.AxisError(axis=axis, ndim=self.ndim)
                 return 1


Test patch:
Repository: numpy/numpy

Issue:
Wrong capitalization on bitgenerator MT19937
Wrong capitalization of MT19937 in default argument values of functions in numpy.random._pickle.py

### Reproducing code example:

```python
import numpy as np
np.random._pickle.__randomstate_ctor() # => error
np.random._pickle.__randomstate_ctor('mt19937') # => error
np.random._pickle.__randomstate_ctor('MT19937') # => works
```

### Error message:

*** ValueError: mt19937 is not a known BitGenerator module.

### Numpy/Python version information:

1.17.0 3.6.8 (default, Jan 14 2019, 11:02:34) 
[GCC 8.0.1 20180414 (experimental) [trunk revision 259383]]



Discussion:

Resolving patch:
diff --git a/numpy/random/_pickle.py b/numpy/random/_pickle.py
--- a/numpy/random/_pickle.py
+++ b/numpy/random/_pickle.py
@@ -13,7 +13,7 @@
                  }
 
 
-def __generator_ctor(bit_generator_name='mt19937'):
+def __generator_ctor(bit_generator_name='MT19937'):
     """
     Pickling helper function that returns a Generator object
 
@@ -36,7 +36,7 @@ def __generator_ctor(bit_generator_name='mt19937'):
     return Generator(bit_generator())
 
 
-def __bit_generator_ctor(bit_generator_name='mt19937'):
+def __bit_generator_ctor(bit_generator_name='MT19937'):
     """
     Pickling helper function that returns a bit generator object
 
@@ -59,7 +59,7 @@ def __bit_generator_ctor(bit_generator_name='mt19937'):
     return bit_generator()
 
 
-def __randomstate_ctor(bit_generator_name='mt19937'):
+def __randomstate_ctor(bit_generator_name='MT19937'):
     """
     Pickling helper function that returns a legacy RandomState-like object
 


Test patch:
Repository: numpy/numpy

Issue:
Document whether numpy.split() works in place
It should be documented whether `numpy.split()` works in place or not. I think it does not, but in general that information is probably easy to add for you maintainers.

### Numpy/Python version information:

1.17.0 3.6.8 (default, Jan 14 2019, 11:02:34) 
[GCC 8.0.1 20180414 (experimental) [trunk revision 259383]]


Discussion:
It returns views into the original array, the documentation could indeed spell that out a bit more clearly, by mentioning the word `view` somewhere probably, `sub-arrray` is not a well defined term in this regard, I guess.
Do you want to make a PR with a suggestion?

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
@@ -782,7 +782,7 @@ def _split_dispatcher(ary, indices_or_sections, axis=None):
 @array_function_dispatch(_split_dispatcher)
 def split(ary, indices_or_sections, axis=0):
     """
-    Split an array into multiple sub-arrays.
+    Split an array into multiple sub-arrays as views into `ary`.
 
     Parameters
     ----------
@@ -809,7 +809,7 @@ def split(ary, indices_or_sections, axis=0):
     Returns
     -------
     sub-arrays : list of ndarrays
-        A list of sub-arrays.
+        A list of sub-arrays as views into `ary`.
 
     Raises
     ------
@@ -854,8 +854,7 @@ def split(ary, indices_or_sections, axis=0):
         if N % sections:
             raise ValueError(
                 'array split does not result in an equal division')
-    res = array_split(ary, indices_or_sections, axis)
-    return res
+    return array_split(ary, indices_or_sections, axis)
 
 
 def _hvdsplit_dispatcher(ary, indices_or_sections):


Test patch:
Repository: numpy/numpy

Issue:
doc: obsolete reference to NPY_OWNDATA
In `numpy/doc/source/reference/c-api.array.rst`, shouldn't it be `NPY_ARRAY_OWNDATA` instead?


Discussion:
It would be nice to go through all the `NPY_*` in `numpy/core/include/numpy/old_defines.h` and make sure none of them are still in the documentation
```
cat ./numpy/core/include/numpy/old_defines.h | grep '^#define [a-zA-Z0-9_-]*' | awk '{print $2}' | xargs -I {} sh -c 'echo {}; echo; grep --exclude old_defines.h -r "\b{}\b" .'
```

```
# Omitting all symbols with no matches

OLD_DEFINES_H
./numpy/core/include/numpy/npy_no_deprecated_api.h:    defined(OLD_DEFINES_H)

NDARRAY_VERSION
./numpy/core/_add_newdocs.py:    Return the compile time NDARRAY_VERSION number.

PyArray_VOID
./doc/records.rst.txt:  This will be converted to a ``PyArray_VOID`` type with corresponding
./doc/records.rst.txt:  typeobject (and ``PyArray_VOID``) typenumber.  If the type is
./doc/records.rst.txt:  Otherwise a new ``PyArray_VOID PyArray_Descr*`` structure is created
```



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
@@ -1342,7 +1342,7 @@
 add_newdoc('numpy.core.multiarray', '_get_ndarray_c_version',
     """_get_ndarray_c_version()
 
-    Return the compile time NDARRAY_VERSION number.
+    Return the compile time NPY_VERSION (formerly called NDARRAY_VERSION) number.
 
     """)
 


Test patch:
Repository: numpy/numpy

Issue:
Missing .. versionadded in `prepend` parameter of np.diff
There is no versionadded tag for prepend on https://docs.scipy.org/doc/numpy/reference/generated/numpy.diff.html. This is not a huge problem, but I've started using that argument quite a bit more, so it would be nice to know what versions break my code.

I would be happy to submit a PR, but am not sure what the correct version is (I think it's 1.16.0, but would prefer to have an expert verify).


Discussion:
Yes, it is in the 1.16 release notes.
@seberg. I apologize for the laziness. My corporate firewall gets all weird with GitHub. I could have waited til I got home. Thanks for the check.

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
@@ -1167,11 +1167,13 @@ def diff(a, n=1, axis=-1, prepend=np._NoValue, append=np._NoValue):
         The axis along which the difference is taken, default is the
         last axis.
     prepend, append : array_like, optional
-        Values to prepend or append to "a" along axis prior to
+        Values to prepend or append to `a` along axis prior to
         performing the difference.  Scalar values are expanded to
         arrays with length 1 in the direction of axis and the shape
         of the input array in along all other axes.  Otherwise the
-        dimension and shape must match "a" except along axis.
+        dimension and shape must match `a` except along axis.
+
+        .. versionadded:: 1.16.0
 
     Returns
     -------


Test patch:
Repository: numpy/numpy

Issue:
Minor typo in documentation for np.logical_and()
<!-- Please describe the issue in detail here, and fill in the fields below -->

The documentation for numpy.logical_and() has a minor typo. The 'return' field says 

> Boolean result of the logical OR operation applied to the elements of x1 and x2...

Whereas it should say 

> Boolean result of the logical __AND__ operation applied to the elements of x1 and x2...

(emphasis mine)

### Numpy/Python version information:

<!-- Output from 'import sys, numpy; print(numpy.__version__, sys.version)' -->
[numpy v1.17 online documentation](https://docs.scipy.org/doc/numpy/reference/generated/numpy.logical_and.html)




Discussion:

Resolving patch:
diff --git a/numpy/core/code_generators/ufunc_docstrings.py b/numpy/core/code_generators/ufunc_docstrings.py
--- a/numpy/core/code_generators/ufunc_docstrings.py
+++ b/numpy/core/code_generators/ufunc_docstrings.py
@@ -2183,7 +2183,7 @@ def add_newdoc(place, name, doc):
     Returns
     -------
     y : ndarray or bool
-        Boolean result of the logical OR operation applied to the elements
+        Boolean result of the logical AND operation applied to the elements
         of `x1` and `x2`; the shape is determined by broadcasting.
         $OUT_SCALAR_2
 


Test patch:
Repository: numpy/numpy

Issue:
np.sinc() documentation "It works in 2-D as well" looks misleading
The [documentation](https://docs.scipy.org/doc/numpy/reference/generated/numpy.sinc.html#numpy.sinc) currently states:

> It works in 2-D as well:
> >>> x = np.linspace(-4, 4, 401)
> >>> xx = np.outer(x, x)
> >>> plt.imshow(np.sinc(xx))

This does not seem useful as it is computing np.sinc(x*y) over the domain [-4,4]*[-4,4].

In almost all cases, the desired generalization of np.sinc() to 2D is instead np.sinc(x)*np.sinc(y) [see [Wikipedia entry](https://en.wikipedia.org/wiki/Sinc_function#Higher_dimensions)]:

  xx, yy = np.meshgrid(np.linspace(-4, 4, 401), np.linspace(-4, 4, 401))
  plt.imshow(np.sinc(xx) * np.sinc(yy), cmap='gray')



Discussion:
I'm not convinced this section is even useful in the docs. All ufuncs work "in 2d" (read: on 2d inputs). I'd be in favor of removing it.
@eric-wieser If there is consensus I would love to help to remove it.

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
@@ -3297,13 +3297,6 @@ def sinc(x):
     Text(0.5, 0, 'X')
     >>> plt.show()
 
-    It works in 2-D as well:
-
-    >>> x = np.linspace(-4, 4, 401)
-    >>> xx = np.outer(x, x)
-    >>> plt.imshow(np.sinc(xx))
-    <matplotlib.image.AxesImage object at 0x...>
-
     """
     x = np.asanyarray(x)
     y = pi * where(x == 0, 1.0e-20, x)


Test patch:
Repository: numpy/numpy

Issue:
polyfit reference: definition of 'residuals'
Returns:  
residuals, rank, singular_values, rcond :
Present only if full = True. Residuals of the least-squares fit...

The 'residuals' returned is  the sum of (the square of each residual) (i.e. one number in an array).  It would be useful to actually return the array of all the residuals; if not that, then documentation should be changed.



Discussion:

Resolving patch:
diff --git a/numpy/lib/polynomial.py b/numpy/lib/polynomial.py
--- a/numpy/lib/polynomial.py
+++ b/numpy/lib/polynomial.py
@@ -479,10 +479,10 @@ def polyfit(x, y, deg, rcond=None, full=False, w=None, cov=False):
         coefficients for `k`-th data set are in ``p[:,k]``.
 
     residuals, rank, singular_values, rcond
-        Present only if `full` = True.  Residuals of the least-squares fit,
-        the effective rank of the scaled Vandermonde coefficient matrix,
-        its singular values, and the specified value of `rcond`. For more
-        details, see `linalg.lstsq`.
+        Present only if `full` = True.  Residuals is sum of squared residuals
+        of the least-squares fit, the effective rank of the scaled Vandermonde
+        coefficient matrix, its singular values, and the specified value of
+        `rcond`. For more details, see `linalg.lstsq`.
 
     V : ndarray, shape (M,M) or (M,M,K)
         Present only if `full` = False and `cov`=True.  The covariance


Test patch:
Repository: numpy/numpy

Issue:
Add API documentation for np.distutils.core.Extension class
[The f2py docs mention](https://docs.scipy.org/doc/numpy/f2py/distutils.html) that the `numpy.distutils.core.Extension` class can be used, but as far as I can tell there is no documentation of this class either in the main numpy documentation or in the f2py documentation.


Discussion:
Thanks @dstansby. Looking at that, it does seem like that's public and needs to be added to the docs. `numpy.distutils.core` may have been meant as the thing that imports the public API part from other Python files in that directory. Unclear though. For now, adding `core.Extension` to the docs sounds good. 

Resolving patch:
diff --git a/numpy/distutils/extension.py b/numpy/distutils/extension.py
--- a/numpy/distutils/extension.py
+++ b/numpy/distutils/extension.py
@@ -19,8 +19,24 @@
 cxx_ext_re = re.compile(r'.*[.](cpp|cxx|cc)\Z', re.I).match
 fortran_pyf_ext_re = re.compile(r'.*[.](f90|f95|f77|for|ftn|f|pyf)\Z', re.I).match
 
+
 class Extension(old_Extension):
-    def __init__ (
+    """
+    Parameters
+    ----------
+    name : str
+        Extension name.
+    sources : list of str
+        List of source file locations relative to the top directory of
+        the package.
+    extra_compile_args : list of str
+        Extra command line arguments to pass to the compiler.
+    extra_f77_compile_args : list of str
+        Extra command line arguments to pass to the fortran77 compiler.
+    extra_f90_compile_args : list of str
+        Extra command line arguments to pass to the fortran90 compiler.
+    """
+    def __init__(
             self, name, sources,
             include_dirs=None,
             define_macros=None,


Test patch:
Repository: numpy/numpy

Issue:
Docs: is np.dtype.descr compatible with constructing a dtype?
The [reference docs for dtype.descr](https://docs.scipy.org/doc/numpy/reference/generated/numpy.dtype.descr.html#numpy.dtype.descr) say:

> Warning: This attribute exists specifically for `__array_interface__`, and is not a datatype description compatible with np.dtype.

However, the [docs on constructing dtypes](https://docs.scipy.org/doc/numpy/reference/arrays.dtypes.html#specifying-and-constructing-data-types) describe `np.dtype()` accepting a list of 2- or 3-tuples, and explicitly say it's as used in `__array_interface__`.

> `(field_name, field_dtype, field_shape), ...]`
>
>  obj should be a list of fields where each field is described by a tuple of length 2 or 3. (Equivalent to the descr item in the `__array_interface__` attribute.)


Discussion:
I think what it is really getting at is that `np.dtype(dt.descr)` is lossy, and does not produce `dt`.
Aha, thanks. What can it lose?
```python
def roundtrip(*args, **kwargs):
    return np.dtype(np.dtype(*args, **kwargs).descr)
```
* Scalars - `roundtrip(np.int64)` &rarr; `dtype([('f0', '<i8')])`
* Subarrays - `roundtrip(np.int64)` &rarr; `dtype([('f0', 'V24')])`
* Hidden padding - `roundtrip([('a', np.uint8), ('b', np.uint16)], align=True)` &rarr; `dtype([('a', 'u1'), ('f1', 'V1'), ('b', '<u2')])`
* Field order: `roundtrip(dict(names=['b', 'a'], formats=[np.uint8, np.uint8], offsets=[1, 0])`  &rarr; `ValueError: dtype.descr is not defined for types with overlapping or out-of-order fields`
Aha, gotcha. That's quite a lot of information it can lose!

I'm happy to make a PR to clarify the documentation a bit, if you'd like.

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
@@ -5327,7 +5327,8 @@
     `__array_interface__` attribute.
 
     Warning: This attribute exists specifically for `__array_interface__`,
-    and is not a datatype description compatible with `np.dtype`.
+    and passing it directly to `np.dtype` will not accurately reconstruct
+    some dtypes (e.g., scalar and subarray dtypes).
 
     Examples
     --------


Test patch:
Repository: numpy/numpy

Issue:
Numpy FFTs return data types don't match input data types
<!-- Please describe the issue in detail here, and fill in the fields below -->

Unlike other functions, the NumPy FFT functions do not return arrays whose data types match the input arrays. Instead, `complex64` is promoted to `complex128`.

### Reproducing code example:

<!-- A short code example that reproduces the problem/missing feature. It should be
self-contained, i.e., possible to run as-is via 'python myproblem.py' -->

```python
import sys
import numpy as np

print(np.__version__, sys.version)

input = np.ones((5, 5), dtype='complex64')

output = np.square(input)
assert output.dtype == 'complex64', f"{output.dtype} square"  # assert passes

output = np.fft.fft2(input)
assert output.dtype == 'complex64', f"{output.dtype} fft"  # assert fails
```

### Numpy/Python version information:

<!-- Output from 'import sys, numpy; print(numpy.__version__, sys.version)' -->
1.17.3 3.8.0 | packaged by conda-forge | (default, Nov  6 2019, 23:20:36) 
[GCC 7.3.0]




Discussion:
You need SciPy to get support for float32/complex64.
I'm going to open a pull-request with an addition to the documentation page noting that `numpy.fft` is inconsistent with other NumPy functions because it promotes `float32/complex64` arrays to `float64/complex128` arrays.

Resolving patch:
diff --git a/numpy/fft/__init__.py b/numpy/fft/__init__.py
--- a/numpy/fft/__init__.py
+++ b/numpy/fft/__init__.py
@@ -118,8 +118,16 @@
 It differs from the forward transform by the sign of the exponential
 argument and the default normalization by :math:`1/n`.
 
+Type Promotion
+--------------
+
+`numpy.fft` promotes ``float32`` and ``complex64`` arrays to ``float64`` and
+``complex128`` arrays respectively. For an FFT implementation that does not
+promote input arrays, see `scipy.fftpack`.
+
 Normalization
 -------------
+
 The default normalization has the direct transforms unscaled and the inverse
 transforms are scaled by :math:`1/n`. It is possible to obtain unitary
 transforms by setting the keyword argument ``norm`` to ``"ortho"`` (default is


Test patch: