Mailman 3 August 2019 - NumPy-Discussion

mixed mode arithmetic
by Neal Becker July 11, 2023

July 11, 2023

I've been browsing the numpy source. I'm wondering about mixed-mode arithmetic on arrays. I believe the way numpy handles this is that it never does mixed arithmetic, but instead converts arrays to a common type. Arguably, that might be efficient for a mix of say, double and float. Maybe not. But for a mix of complex and a scalar type (say, CDouble * Double), it's clearly suboptimal in efficiency. So, do I understand this correctly? If so, is that something we should improve?

4 6

Invalid value encoutered : how to prevent numpy.where to do this?
by Eric Emsellem Feb. 18, 2023

Feb. 18, 2023

Dear all, I have a code using lots of "numpy.where" to make some constrained calculations as in: data = arange(10) result = np.where(data == 0, 0., 1./data) # or data1 = arange(10) data2 = arange(10)+1.0 result = np.where(data1 > data2, np.sqrt(data1-data2), np.sqrt(data2-data2)) which then produces warnings like: /usr/bin/ipython:1: RuntimeWarning: invalid value encountered in sqrt or for the first example: /usr/bin/ipython:1: RuntimeWarning: divide by zero encountered in divide How do I avoid these messages to appear? I know that I could in principle use numpy.seterr. However, I do NOT want to remove these warnings for other potential divide/multiply/sqrt etc errors. Only when I am using a "where", to in fact avoid such warnings! Note that the warnings only happen once, but since I am going to release that code, I would like to avoid the user to get such messages which are irrelevant here (because I am testing, with the where, when NOT to divide by zero or take a sqrt of a negative number). thanks! Eric

5 4

Re: [Numpy-discussion] example reading binary Fortran file
by Neil Martinsen-Burrell July 22, 2021

July 22, 2021

David Froger <david.froger.info <at> gmail.com> writes: > Hy,My question is about reading Fortran binary file (oh no this question > again...) I've posted this before, but I finally got it cleaned up for the Cookbook. For this purpose I use a subclass of file that has methods for reading unformatted Fortran data. See http://www.scipy.org/Cookbook/FortranIO/FortranFile. I'd gladly see this in numpy or scipy somewhere, but I'm not sure where it belongs. > program makeArray > implicit none > integer,parameter:: nx=10,ny=20 > real(4),dimension(nx,ny):: ux,uy,p > integer :: i,j > open(11,file='uxuyp.bin',form='unformatted') > do i = 1,nx > do j = 1,ny > ux(i,j) = real(i*j) > uy(i,j) = real(i)/real(j) > p (i,j) = real(i) + real(j) > enddo > enddo > write(11) ux,uy > write(11) p > close(11) > end program makeArray When I run the above program compiled with gfortran on my Intel Mac, I can read it back with:: >>> import numpy as np >>> from fortranfile import FortranFile >>> f=FortranFile('uxuyp.bin', endian='<') >>> uxuy = f.readReals(prec='f') # 'f' for default reals >>> len(uxuy) 400 >>> ux = np.array(uxuy[:200]).reshape((20,10)).T >>> uy = np.array(uxuy[200:]).reshape((20,10)).T >>> p = f.readReals('f').reshape((20,10)).T >>> ux array([[ 1., 2., 3., 4., 5., 6., 7., 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20.], [ 2., 4., 6., 8., 10., 12., 14., 16., 18., 20., 22., 24., 26., 28., 30., 32., 34., 36., 38., 40.], [ 3., 6., 9., 12., 15., 18., 21., 24., 27., 30., 33., 36., 39., 42., 45., 48., 51., 54., 57., 60.], [ 4., 8., 12., 16., 20., 24., 28., 32., 36., 40., 44., 48., 52., 56., 60., 64., 68., 72., 76., 80.], [ 5., 10., 15., 20., 25., 30., 35., 40., 45., 50., 55., 60., 65., 70., 75., 80., 85., 90., 95., 100.], [ 6., 12., 18., 24., 30., 36., 42., 48., 54., 60., 66., 72., 78., 84., 90., 96., 102., 108., 114., 120.], [ 7.,Proxy-Connection: keep-alive Cache-Control: max-age=0 14., 21., 28., 35., 42., 49., 56., 63., 70., 77., 84., 91., 98., 105., 112., 119., 126., 133., 140.], [ 8., 16., 24., 32., 40., 48., 56., 64., 72., 80., 88., 96., 104., 112., 120., 128., 136., 144., 152., 160.], [ 9., 18., 27., 36., 45., 54., 63., 72., 81., 90., 99., 108., 117., 126., 135., 144., 153., 162., 171., 180.], [ 10., 20., 30., 40., 50., 60., 70., 80., 90., 100., 110., 120., 130., 140., 150., 160., 170., 180., 190., 200.]]) >>> uy array([[ 1. , 0.5 , 0.33333334, 0.25 , 0.2 , 0.16666667, 0.14285715, 0.125 , 0.11111111, 0.1 , 0.09090909, 0.08333334, 0.07692308, 0.07142857, 0.06666667, 0.0625 , 0.05882353, 0.05555556, 0.05263158, 0.05 ], [ 2. , 1. , 0.66666669, 0.5 , 0.40000001, 0.33333334, 0.2857143 , 0.25 , 0.22222222, 0.2 , 0.18181819, 0.16666667, 0.15384616, 0.14285715, 0.13333334, 0.125 , 0.11764706, 0.11111111, 0.10526316, 0.1 ], [ 3. , 1.5 , 1. , 0.75 , 0.60000002, 0.5 , 0.42857143, 0.375 , 0.33333334, 0.30000001, 0.27272728, 0.25 , 0.23076923, 0.21428572, 0.2 , 0.1875 , 0.17647059, 0.16666667, 0.15789473, 0.15000001], [ 4. , 2. , 1.33333337, 1. , 0.80000001, 0.66666669, 0.5714286 , 0.5 , 0.44444445, 0.40000001, 0.36363637, 0.33333334, 0.30769232, 0.2857143 , 0.26666668, 0.25 , 0.23529412, 0.22222222, 0.21052632, 0.2 ], [ 5. , 2.5 , 1.66666663, 1.25 , 1. , 0.83333331, 0.71428573, 0.625 , 0.55555558, 0.5 , 0.45454547, 0.41666666, 0.38461539, 0.35714287, 0.33333334, 0.3125 , 0.29411766, 0.27777779, 0.2631579 , 0.25 ], [ 6. , 3. , 2. , 1.5 , 1.20000005, 1. , 0.85714287, 0.75 , 0.66666669, 0.60000002, 0.54545456, 0.5 , 0.46153846, 0.42857143, 0.40000001, 0.375 , 0.35294119, 0.33333334, 0.31578946, 0.30000001], [ 7. , 3.5 , 2.33333325, 1.75 , 1.39999998, 1.16666663, 1. , 0.875 , 0.77777779, 0.69999999, 0.63636363, 0.58333331, 0.53846157, 0.5 , 0.46666667, 0.4375 , 0.41176471, 0.3888889 , 0.36842105, 0.34999999], [ 8. , 4. , 2.66666675, 2. , 1.60000002, 1.33333337, 1.14285719, 1. , 0.8888889 , 0.80000001, 0.72727275, 0.66666669, 0.61538464, 0.5714286 , 0.53333336, 0.5 , 0.47058824, 0.44444445, 0.42105263, 0.40000001], [ 9. , 4.5 , 3. , 2.25 , 1.79999995, 1.5 , 1.28571427, 1.125 , 1. , 0.89999998, 0.81818181, 0.75 , 0.69230771, 0.64285713, 0.60000002, 0.5625 , 0.52941179, 0.5 , 0.47368422, 0.44999999], [ 10. , 5. , 3.33333325, 2.5 , 2. , 1.66666663, 1.42857146, 1.25 , 1.11111116, 1. , 0.90909094, 0.83333331, 0.76923078, 0.71428573, 0.66666669, 0.625 , 0.58823532, 0.55555558, 0.52631581, 0.5 ]]) >>> p array([[ 2., 3., 4., 5., 6., 7., 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21.], [ 3., 4., 5., 6., 7., 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22.], [ 4., 5., 6., 7., 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23.], [ 5., 6., 7., 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23., 24.], [ 6., 7., 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23., 24., 25.], [ 7., 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23., 24., 25., 26.], [ 8., 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23., 24., 25., 26., 27.], [ 9., 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23., 24., 25., 26., 27., 28.], [ 10., 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23., 24., 25., 26., 27., 28., 29.], [ 11., 12., 13., 14., 15., 16., 17., 18., 19., 20., 21., 22., 23., 24., 25., 26., 27., 28., 29., 30.]]) Note that you have to provide the shape information for ux and uy because fortran writes them together as a stream of 400 numbers. -Neil

10 10

NEP 30 - Duck Typing for NumPy Arrays - Implementation
by Peter Andreas Entschev Sept. 17, 2019

Sept. 17, 2019

Hi, we have a new proposal for the implementation of NumPy array duck typing [1] [2], following the high-level overview described in NEP-22 [3]. Would be great to get some comments on that. [1] https://github.com/numpy/numpy/blob/master/doc/neps/nep-0030-duck-array-pro… [2] https://github.com/numpy/numpy/pull/14170 [3] https://numpy.org/neps/nep-0022-ndarray-duck-typing-overview.html Best, Peter

6 23

Code review for adding axis argument to permutation and shuffle function
by Kexuan Sun Sept. 13, 2019

Sept. 13, 2019

Hi, I would like to request a code review. The random.permutation and random.shuffle functions now can only shuffle along the first axis of a multi-dimensional array. I propose to add an axis argument for the functions and allow them to shuffle along a given axis. Here is the link to the PR (https://github.com/numpy/numpy/pull/13829). Thanks!

5 4

NumPy Community Survey
by Inessa Pawson Sept. 12, 2019

Sept. 12, 2019

You know that NumPy is essential to the Python community. The NumPy team wants you to know that YOU, our user and developer community, are essential to us. That’s why we are putting together a team to create the inaugural NumPy Community Survey. We hope feedback will provide insights that will help us to guide better decision-making about the development of NumPy as software and community. For more information about the proposed survey please refer to github.com/numpy/numpy-surveys . *Call for Contributions* We are looking for volunteers experienced in survey design and translating English into Spanish, Portuguese, Russian, Hindi, Chinese and other languages. If you’d like to learn more about these volunteer opportunities, or additional ways to support NumPy, feel free to reach out to our community coordinators at numpy-team(a)googlegroups.com or join us on Slack numpy-team.slack.com (email to numpy-team(a)googlegroups.com for an invite first). -- Every good wish, Inessa Pawson NumPy Team

3 2

Allowing Dependabot access to the numpy repo
by Matti Picus Sept. 1, 2019

Sept. 1, 2019

4 4

Re: [Numpy-discussion] NEP 31: Context-local and global overrides of the NumPy API
by Hameer Abbasi Aug. 29, 2019

Aug. 29, 2019

The full-text of the NEP is quoted below, apologies for not including it earlier: ============================================================ NEP 31 — Context-local and global overrides of the NumPy API ============================================================ :Author: Hameer Abbasi <habbasi(a)quansight.com> :Author: Ralf Gommers <rgommers(a)quansight.com> :Author: Peter Bell <peterbell10(a)live.co.uk> :Status: Draft :Type: Standards Track :Created: 2019-08-22 Abstract -------- This NEP proposes to make all of NumPy's public API overridable via an extensible backend mechanism, using a library called ``uarray`` `[1]`_ ``uarray`` provides global and context-local overrides, as well as a dispatch mechanism similar to NEP-18 `[2]`_. First experiences with ``__array_function__`` show that it is necessary to be able to override NumPy functions that *do not take an array-like argument*, and hence aren't overridable via ``__array_function__``. The most pressing need is array creation and coercion functions - see e.g. NEP-30 `[9]`_. This NEP proposes to allow, in an opt-in fashion, overriding any part of the NumPy API. It is intended as a comprehensive resolution to NEP-22 `[3]`_, and obviates the need to add an ever-growing list of new protocols for each new type of function or object that needs to become overridable. Motivation and Scope -------------------- The motivation behind ``uarray`` is manyfold: First, there have been several attempts to allow dispatch of parts of the NumPy API, including (most prominently), the ``__array_ufunc__`` protocol in NEP-13 `[4]`_, and the ``__array_function__`` protocol in NEP-18 `[2]`_, but this has shown the need for further protocols to be developed, including a protocol for coercion (see `[5]`_). The reasons these overrides are needed have been extensively discussed in the references, and this NEP will not attempt to go into the details of why these are needed. Another pain point requiring yet another protocol is the duck-array protocol (see `[9]`_). This NEP takes a more holistic approach: It assumes that there are parts of the API that need to be overridable, and that these will grow over time. It provides a general framework and a mechanism to avoid a design of a new protocol each time this is required. This NEP proposes the following: That ``unumpy`` `[8]`_ becomes the recommended override mechanism for the parts of the NumPy API not yet covered by ``__array_function__`` or ``__array_ufunc__``, and that ``uarray`` is vendored into a new namespace within NumPy to give users and downstream dependencies access to these overrides. This vendoring mechanism is similar to what SciPy decided to do for making ``scipy.fft`` overridable (see `[10]`_). Detailed description -------------------- **Note:** *This section will not attempt to explain the specifics or the mechanism of ``uarray``, that is explained in the ``uarray`` documentation.* `[1]`_ *However, the NumPy community will have input into the design of ``uarray``, and any backward-incompatible changes will be discussed on the mailing list.* The way we propose the overrides will be used by end users is:: import numpy.overridable as np with np.set_backend(backend): x = np.asarray(my_array, dtype=dtype) And a library that implements a NumPy-like API will use it in the following manner (as an example):: import numpy.overridable as np _ua_implementations = {} __ua_domain__ = "numpy" def __ua_function__(func, args, kwargs): fn = _ua_implementations.get(func, None) return fn(*args, **kwargs) if fn is not None else NotImplemented def implements(ua_func): def inner(func): _ua_implementations[ua_func] = func return func return inner @implements(np.asarray) def asarray(a, dtype=None, order=None): # Code here # Either this method or __ua_convert__ must # return NotImplemented for unsupported types, # Or they shouldn't be marked as dispatchable. # Provides a default implementation for ones and zeros. @implements(np.full) def full(shape, fill_value, dtype=None, order='C'): # Code here The only change this NEP proposes at its acceptance, is to make ``unumpy`` the officially recommended way to override NumPy. ``unumpy`` will remain a separate repository/package (which we propose to vendor to avoid a hard dependency, and use the separate ``unumpy`` package only if it is installed) rather than depend on for the time being), and will be developed primarily with the input of duck-array authors and secondarily, custom dtype authors, via the usual GitHub workflow. There are a few reasons for this: * Faster iteration in the case of bugs or issues. * Faster design changes, in the case of needed functionality. * ``unumpy`` will work with older versions of NumPy as well. * The user and library author opt-in to the override process, rather than breakages happening when it is least expected. In simple terms, bugs in ``unumpy`` mean that ``numpy`` remains unaffected. Advantanges of ``unumpy`` over other solutions ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``unumpy`` offers a number of advantanges over the approach of defining a new protocol for every problem encountered: Whenever there is something requiring an override, ``unumpy`` will be able to offer a unified API with very minor changes. For example: * ``ufunc`` objects can be overridden via their ``__call__``, ``reduce`` and other methods. * ``dtype`` objects can be overridden via the dispatch/backend mechanism, going as far as to allow ``np.float32`` et. al. to be overridden by overriding ``__get__``. * Other functions can be overridden in a similar fashion. * ``np.asduckarray`` goes away, and becomes ``np.asarray`` with a backend set. * The same holds for array creation functions such as ``np.zeros``, ``np.empty`` and so on. This also holds for the future: Making something overridable would require only minor changes to ``unumpy``. Another promise ``unumpy`` holds is one of default implementations. Default implementations can be provided for any multimethod, in terms of others. This allows one to override a large part of the NumPy API by defining only a small part of it. This is to ease the creation of new duck-arrays, by providing default implementations of many functions that can be easily expressed in terms of others, as well as a repository of utility functions that help in the implementation of duck-arrays that most duck-arrays would require. The last benefit is a clear way to coerce to a given backend, and a protocol for coercing not only arrays, but also ``dtype`` objects and ``ufunc`` objects with similar ones from other libraries. This is due to the existence of actual, third party dtype packages, and their desire to blend into the NumPy ecosystem (see `[6]`_). This is a separate issue compared to the C-level dtype redesign proposed in `[7]`_, it's about allowing third-party dtype implementations to work with NumPy, much like third-party array implementations. Mixing NumPy and ``unumpy`` in the same file ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Normally, one would only want to import only one of ``unumpy`` or ``numpy``, you would import it as ``np`` for familiarity. However, there may be situations where one wishes to mix NumPy and the overrides, and there are a few ways to do this, depending on the user's style:: import numpy.overridable as unumpy import numpy as np or:: import numpy as np # Use unumpy via np.overridable Related Work ------------ Previous override mechanisms ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * NEP-18, the ``__array_function__`` protocol. `[2]`_ * NEP-13, the ``__array_ufunc__`` protocol. `[3]`_ Existing NumPy-like array implementations ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * Dask: https://dask.org/ * CuPy: https://cupy.chainer.org/ * PyData/Sparse: https://sparse.pydata.org/ * Xnd: https://xnd.readthedocs.io/ * Astropy's Quantity: https://docs.astropy.org/en/stable/units/ Existing and potential consumers of alternative arrays ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * Dask: https://dask.org/ * scikit-learn: https://scikit-learn.org/ * Xarray: https://xarray.pydata.org/ * TensorLy: http://tensorly.org/ Existing alternate dtype implementations ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * ``ndtypes``: https://ndtypes.readthedocs.io/en/latest/ * Datashape: https://datashape.readthedocs.io * Plum: https://plum-py.readthedocs.io/ Implementation -------------- The implementation of this NEP will require the following steps: * Implementation of ``uarray`` multimethods corresponding to the NumPy API, including classes for overriding ``dtype``, ``ufunc`` and ``array`` objects, in the ``unumpy`` repository. * Moving backends from ``unumpy`` into the respective array libraries. Backward compatibility ---------------------- There are no backward incompatible changes proposed in this NEP. Alternatives ------------ The current alternative to this problem is NEP-30 plus adding more protocols (not yet specified) in addition to it. Even then, some parts of the NumPy API will remain non-overridable, so it's a partial alternative. The main alternative to vendoring ``unumpy`` is to simply move it into NumPy completely and not distribute it as a separate package. This would also achieve the proposed goals, however we prefer to keep it a separate package for now, for reasons already stated above. Discussion ---------- * ``uarray`` blogpost: https://labs.quansight.org/blog/2019/07/uarray-update-api-changes-overhead-… * The discussion section of NEP-18: https://numpy.org/neps/nep-0018-array-function-protocol.html#discussion * NEP-22: https://numpy.org/neps/nep-0022-ndarray-duck-typing-overview.html * Dask issue #4462: https://github.com/dask/dask/issues/4462 * PR #13046: https://github.com/numpy/numpy/pull/13046 * Dask issue #4883: https://github.com/dask/dask/issues/4883 * Issue #13831: https://github.com/numpy/numpy/issues/13831 * Discussion PR 1: https://github.com/hameerabbasi/numpy/pull/3 * Discussion PR 2: https://github.com/hameerabbasi/numpy/pull/4 References and Footnotes ------------------------ .. _[1]: [1] uarray, A general dispatch mechanism for Python: https://uarray.readthedocs.io .. _[2]: [2] NEP 18 — A dispatch mechanism for NumPy’s high level array functions: https://numpy.org/neps/nep-0018-array-function-protocol.html .. _[3]: [3] NEP 22 — Duck typing for NumPy arrays – high level overview: https://numpy.org/neps/nep-0022-ndarray-duck-typing-overview.html .. _[4]: [4] NEP 13 — A Mechanism for Overriding Ufuncs: https://numpy.org/neps/nep-0013-ufunc-overrides.html .. _[5]: [5] Reply to Adding to the non-dispatched implementation of NumPy methods: http://numpy-discussion.10968.n7.nabble.com/Adding-to-the-non-dispatched-im… .. _[6]: [6] Custom Dtype/Units discussion: http://numpy-discussion.10968.n7.nabble.com/Custom-Dtype-Units-discussion-t… .. _[7]: [7] The epic dtype cleanup plan: https://github.com/numpy/numpy/issues/2899 .. _[8]: [8] unumpy: NumPy, but implementation-independent: https://unumpy.readthedocs.io .. _[9]: [9] NEP 30 — Duck Typing for NumPy Arrays - Implementation: https://www.numpy.org/neps/nep-0030-duck-array-protocol.html .. _[10]: [10] http://scipy.github.io/devdocs/fft.html#backend-control Copyright --------- This document has been placed in the public domain. From: Hameer Abbasi <hameerabbasi(a)yahoo.com> Date: Wednesday, 28. August 2019 at 10:18 To: Discussion of Numerical Python <numpy-discussion(a)python.org> Cc: "rgommers(a)quansight.com" <rgommers(a)quansight.com>, Peter Bell <peterbell10(a)live.co.uk> Subject: NEP 31: Context-local and global overrides of the NumPy API Hello, Me, Ralf Gommers and Peter Bell (both cc’d) have come up with a proposal on how to solve the array creation and duck array problems. The solution is outlined in NEP-31, currently in the form of a PR, [1] Following the high level discussion in NEP-22. [2] It would be nice to get some feedback. Best regards, Hameer Abbasi [1] https://github.com/numpy/numpy/pull/14389 [2] https://numpy.org/neps/nep-0022-ndarray-duck-typing-overview.html

1 0

NEP 31: Context-local and global overrides of the NumPy API
by Hameer Abbasi Aug. 28, 2019

Aug. 28, 2019

Hello, Me, Ralf Gommers and Peter Bell (both cc’d) have come up with a proposal on how to solve the array creation and duck array problems. The solution is outlined in NEP-31, currently in the form of a PR, [1] Following the high level discussion in NEP-22. [2] It would be nice to get some feedback. Best regards, Hameer Abbasi [1] https://github.com/numpy/numpy/pull/14389 [2] https://numpy.org/neps/nep-0022-ndarray-duck-typing-overview.html

1 0

ENH: Add Moving Average Function
by Nicholas Georgescu Aug. 27, 2019

Aug. 27, 2019

Hi all, I opened a Pull Request (https://link.getmailspring.com/link/58478F5E-3390-4C6D-8AA4-0B8724FC079A@ge…) to include this package in numpy (https://link.getmailspring.com/link/58478F5E-3390-4C6D-8AA4-0B8724FC079A@ge…), along with the associated sliding window function in this PR (https://link.getmailspring.com/link/58478F5E-3390-4C6D-8AA4-0B8724FC079A@ge…). The function picks the fastest method to do a moving average if there is no weighting, but with weights it resorts to the second-fastest method which has an easier implementation. It also contains a binning option which cuts the number of points down by a factor of n rather than by subtracting n. The details are in the package documentation and PR. Thanks, Nicholas

4 3

NumPy 1.16.5 released
by Charles R Harris Aug. 27, 2019

Aug. 27, 2019

Hi All, On behalf of the NumPy team I am pleased to announce that NumPy 1.16.5 has been released. This release fixes bugs reported against the 1.16.4 release and backports several enhancements from master that seem appropriate for the LTS release series that is the last to support Python 2.7. Downstream developers should use Cython >= 0.29.2 and OpenBLAS >= 3.7 to avoid wrong results on the Skylake architecture. The NumPy wheels on PyPI are built from the OpenBLAS development branch in order to avoid those problems. Wheels for this release can be downloaded from PyPI <https://pypi.org/project/numpy/1.16.5/>, source archives and release notes are available from Github <https://github.com/numpy/numpy/releases/tag/v1.16.5>. *Contributors* A total of 18 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Alexander Shadchin - Allan Haldane - Bruce Merry + - Charles Harris - Colin Snyder + - Dan Allan + - Emile + - Eric Wieser - Grey Baker + - Maksim Shabunin + - Marten van Kerkwijk - Matti Picus - Peter Andreas Entschev + - Ralf Gommers - Richard Harris + - Sebastian Berg - Sergei Lebedev + - Stephan Hoyer *Pull requests merged* A total of 23 pull requests were merged for this release. - gh-13742: ENH: Add project URLs to setup.py - gh-13823: TEST, ENH: fix tests and ctypes code for PyPy - gh-13845: BUG: use npy_intp instead of int for indexing array - gh-13867: TST: Ignore DeprecationWarning during nose imports - gh-13905: BUG: Fix use-after-free in boolean indexing - gh-13933: MAINT/BUG/DOC: Fix errors in _add_newdocs - gh-13984: BUG: fix byte order reversal for datetime64[ns] - gh-13994: MAINT,BUG: Use nbytes to also catch empty descr during allocation - gh-14042: BUG: np.array cleared errors occured in PyMemoryView_FromObject - gh-14043: BUG: Fixes for Undefined Behavior Sanitizer (UBSan) errors. - gh-14044: BUG: ensure that casting to/from structured is properly checked. - gh-14045: MAINT: fix histogram*d dispatchers - gh-14046: BUG: further fixup to histogram2d dispatcher. - gh-14052: BUG: Replace contextlib.suppress for Python 2.7 - gh-14056: BUG: fix compilation of 3rd party modules with Py_LIMITED_API... - gh-14057: BUG: Fix memory leak in dtype from dict contructor - gh-14058: DOC: Document array_function at a higher level. - gh-14084: BUG, DOC: add new recfunctions to `__all__` - gh-14162: BUG: Remove stray print that causes a SystemError on python 3.7 - gh-14297: TST: Pin pytest version to 5.0.1. - gh-14322: ENH: Enable huge pages in all Linux builds - gh-14346: BUG: fix behavior of structured_to_unstructured on non-trivial... - gh-14382: REL: Prepare for the NumPy 1.16.5 release. Cheers, Charles Harris

1 0

NumPy logo refresh
by Ralf Gommers Aug. 27, 2019

Aug. 27, 2019

Hi all, At https://github.com/numpy/numpy.org/issues/37 we have an update to the NumPy logo, changing the colors for more contrast / a more modern look. Please have a look! What would also be helpful is to know who made this logo, and with what tool. We'd like to produce a new SVG, but doing that from the old SVG turned out to be problematic. So for now it's PNG only. Cheers, Ralf

1 0

Calling BLAS functions from Python
by Jens Jørgen Mortensen Aug. 27, 2019

Aug. 27, 2019

Hi! I'm trying to use dgemm, zgemm and friends from scipy.linalg.blas to multiply matrices efficiently. As an example, I'd like to do: c += a.dot(b) using whatever BLAS scipy is linked to and I want to avoid copies of large matrices. This works the way I want it: >>> import numpy as np >>> from scipy.linalg.blas import dgemm >>> a = np.ones((2, 3), order='F') >>> b = np.ones((3, 4), order='F') >>> c = np.zeros((2, 4), order='F') >>> dgemm(1.0, a, b, 1.0, c, 0, 0, 1) array([[3., 3., 3., 3.], [3., 3., 3., 3.]]) >>> print(c) [[3. 3. 3. 3.] [3. 3. 3. 3.]] but if c is not contiguous, then c is not overwritten: >>> c = np.zeros((7, 4), order='F')[:2, :] >>> dgemm(1.0, a, b, 1.0, c, 0, 0, 1) array([[3., 3., 3., 3.], [3., 3., 3., 3.]]) >>> print(c) [[0. 0. 0. 0.] [0. 0. 0. 0.]] Which is also what the docs say, but I think the raw BLAS function dgemm could do the update of c in-place by setting LDC=7. See here: http://www.netlib.org/lapack/explore-html/d7/d2b/dgemm_8f.html Is there a way to call the raw BLAS function from Python? I found this capsule thing, but I don't know if there is a way to call that (maybe using ctypes): >>> from scipy.linalg import cython_blas >>> cython_blas.__pyx_capi__['dgemm'] <capsule object "void (char *, char *, int *, int *, int *, __pyx_t_5scipy_6linalg_11cython_blas_d *, __pyx_t_5scipy_6linalg_11cython_blas_d *, int *, __pyx_t_5scipy_6linalg_11cython_blas_d *, int *, __pyx_t_5scipy_6linalg_11cython_blas_d *, __pyx_t_5scipy_6linalg_11cython_blas_d *, int *)" at 0x7f06fe1d2ba0> Best, Jens Jørgen

3 4

NumPy Community Meeting Wednesday, Aug. 28
by Sebastian Berg Aug. 27, 2019

Aug. 27, 2019

Hi all, There will be a NumPy Community meeting Wednesday August 28 at 11 am Pacific Time. Everyone is invited to join in and edit the work-in- progress meeting topics and notes: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both Best wishes Sebastian

1 0

PyData/Sparse 0.8.0
by Hameer Abbasi Aug. 27, 2019

Aug. 27, 2019

(Apologies for the cross-posting) Hello, everyone! PyData/Sparse 0.8.0 has been released. It is available on PyPI (and a source distribution and a universal binary) and conda-forge. Changelog with credits: https://sparse.pydata.org/en/0.8.0/changelog.html Documentation: https://sparse.pydata.org/en/0.8.0/ Source: https://github.com/pydata/sparse/releases/tag/0.8.0

1 0

NumPy 1.17.1 released
by Charles R Harris Aug. 26, 2019

Aug. 26, 2019

Hi All, On behalf of the NumPy team I am pleased to announce that NumPy 1.17.1 has been released. This release contains a number of fixes for bugs reported against NumPy 1.17.0 along with a few documentation and build improvements. The Python versions supported are 3.5-3.7, note that Python 2.7 has been dropped. Python 3.8b3 should work with the released source packages, but there are no future guarantees. Downstream developers should use Cython >= 0.29.13 for Python 3.8 support and OpenBLAS >= 3.7 to avoid wrong results on the Skylake architecture. The NumPy wheels on PyPI are built from the OpenBLAS development branch in order to avoid those problems. Wheels for this release can be downloaded from PyPI <https://pypi.org/project/numpy/1.17.1/>, source archives and release notes are available from Github <https://github.com/numpy/numpy/releases/tag/v1.17.1>. *Contributors* A total of 17 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Alexander Jung + - Allan Haldane - Charles Harris - Eric Wieser - Giuseppe Cuccu + - Hiroyuki V. Yamazaki - Jérémie du Boisberranger - Kmol Yuan + - Matti Picus - Max Bolingbroke + - Maxwell Aladago + - Oleksandr Pavlyk - Peter Andreas Entschev - Sergei Lebedev - Seth Troisi + - Vladimir Pershin + - Warren Weckesser *Pull requests merged* A total of 24 pull requests were merged for this release. - gh-14156: TST: Allow fuss in testing strided/non-strided exp/log loops - gh-14157: BUG: avx2_scalef_ps must be static - gh-14158: BUG: Remove stray print that causes a SystemError on python 3.7. - gh-14159: BUG: Fix DeprecationWarning in python 3.8. - gh-14160: BLD: Add missing gcd/lcm definitions to npy_math.h - gh-14161: DOC, BUILD: cleanups and fix (again) 'build dist' - gh-14166: TST: Add 3.8-dev to travisCI testing. - gh-14194: BUG: Remove the broken clip wrapper (Backport) - gh-14198: DOC: Fix hermitian argument docs in svd. - gh-14199: MAINT: Workaround for Intel compiler bug leading to failing test - gh-14200: TST: Clean up of test_pocketfft.py - gh-14201: BUG: Make advanced indexing result on read-only subclass writeable... - gh-14236: BUG: Fixed default BitGenerator name - gh-14237: ENH: add c-imported modules for freeze analysis in np.random - gh-14296: TST: Pin pytest version to 5.0.1 - gh-14301: BUG: Fix leak in the f2py-generated module init and `PyMem_Del`... - gh-14302: BUG: Fix formatting error in exception message - gh-14307: MAINT: random: Match type of SeedSequence.pool_size to DEFAULT_POOL_SIZE. - gh-14308: BUG: Fix numpy.random bug in platform detection - gh-14309: ENH: Enable huge pages in all Linux builds - gh-14330: BUG: Fix segfault in `random.permutation(x)` when x is a string. - gh-14338: BUG: don't fail when lexsorting some empty arrays (#14228) - gh-14339: BUG: Fix misuse of .names and .fields in various places (backport... - gh-14345: BUG: fix behavior of structured_to_unstructured on non-trivial... - gh-14350: REL: Prepare 1.17.1 release Cheers, Charles Harris

1 0

first Season of Docs blog post
by Ralf Gommers Aug. 25, 2019

Aug. 25, 2019

Hi all, Anne has written a very nice blog post about the start of the Season of Docs projects: https://towardsdatascience.com/what-do-you-want-to-see-in-the-numpy-docs-de… It even includes a pineapple with sunglasses and a party hat, so a good read:) Cheers, Ralf

1 0

NumPy cross-compilation on macOS host
by Jakub Piotr Cłapa Aug. 23, 2019

Aug. 23, 2019

Hi, I spent some time trying to cross-compile NumPy for Linux ARM64 on a macOS host as part of an OpenWRT compilation [1]. It was not so bad but certainly not trivial and I was wondering if we could use my experience to help streamline the process. I encountered two challenges: 1. Python distutils did not allow me to provide a proper cross-ranlib program path. I opened an issue for this on the Python bug tracker [2]. 2. numpy distutils scripts check sys.platform in many places. sys.platform returns the platform on which compilation occurs (darwin in my case) which in case of cross-compilation is not the one on which the code will be run (linux). This of course results in invalid compiler and linker flags. I made a quick'n'dirty fix [3] and got numpy to compile and run correctly (but I have yet to run the full test suite). Of course this is not a proper way to solve this so I was hoping to get some feedback on the preferred/best way. I did not find any info about an official way to do this with distutils. One idea (from @commodo on GitHub) would be to just change my hardcoded string ("Linux") to something like this: target_platform = os.getenviron(“TARGET_PLATFORM”, sys.platform) It could also be further refactored by moving it to a single place but while certainly more elegant and "proper" it may ultimately make it less readable and harder to follow. I am also unsure where would be the best place to put it and how to pass it around to other modules. [1]: https://github.com/openwrt/packages/pull/9797 [2]: https://bugs.python.org/issue37916 [3]: https://github.com/openwrt/packages/pull/9797/commits/e701e122fb9c78d5cecff…

2 1

NumFOCUS Summit and 4 Nov sprint
by Ralf Gommers Aug. 21, 2019

Aug. 21, 2019

Hi all, On 2-3 November the NumFOCUS Summit will be held in NYC, and as a sponsored project NumPy can send two people to it (with NumFOCUS covering travel and hotel costs). To choose those two people we asked the members of the Steering Council first. It seems that we may have an open slot left, so we're asking anyone else who is a part of the NumPy project if they're interested in going. Details from the invitation: We will kick things off Friday, November 1st with a Reception Dinner at Havana Central <https://numfocus-dot-yamm-track.appspot.com/Redirect?ukey=1my4O8gi_yIWFTKq0…> . The Summit program (Nov 2-3) will be aimed at addressing both the challenge of securing funding and navigating the challenges of project governance and leadership. You can view the schedule in more detail here <https://numfocus-dot-yamm-track.appspot.com/Redirect?ukey=1my4O8gi_yIWFTKq0…> . If you're interested, please say so either here or off-list. Also note that we'll likely organize a sprint on 4 Nov, so if there are people who would be interested in that (I imagine there's quite a few people on this list from near NYC?), that'd be good to know as well. Cheers, Ralf

1 0

Releasing the GIL in ufuncs dealing with object arrays
by Joris Van den Bossche Aug. 21, 2019

Aug. 21, 2019

Hi all, PyGEOS (https://github.com/caspervdw/pygeos) is an experimental package implementing a set of numpy ufuncs to provide vectorized geometry functionality (wrapping the C++ GEOS library). The way it does this is by implementing a Python extension type (pygeos.Geometry) that wraps an actual GEOSGeometry object by storing a pointer to it in the PyObject struct of the extension type. This way, we can store those objects in an object dtype array in numpy, but still access the pointer in the ufunc inner loop without needing the python interpreter. The single threaded performance of the ufuncs with the approach above is very good. There doesn't seem to be an overhead of using the object array approach. However, as far as I can find in the docs, the GIL is only released in ufuncs for non-object dtypes. So the question here is: is there a way to let numpy release the GIL in such a case nonetheless? Although the array holds python objects, the ufunc inner loop only accesses a static attribute of the object struct, not needing any explicit Python interaction. Best, Joris

2 3

NumPy 1.17.1
by Charles R Harris Aug. 19, 2019

Aug. 19, 2019

Hi All, I'm planning on releasing NumPy 1.17.1 this weekend. If there are fixes that you think need to be included that are not currently marked for backport, please let me know. Chuck

1 0

NumPy Community Meeting Wednesday, Aug. 21
by Sebastian Berg Aug. 19, 2019

Aug. 19, 2019

Hi all, There will be a NumPy Community meeting Wednesday August 21 at 11 am Pacific Time. Everyone is invited to join in and edit the work-in- progress meeting topics and notes: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both Best wishes Sebastian

1 0

Season of Docs - welcome Anne, Maja, Brandon
by Ralf Gommers Aug. 18, 2019

Aug. 18, 2019

Hi all, Google has announced the Season of Docs participants for this year [1]. We had a lot of excellent candidates and had to make some hard choices. We applied for extra slots, but unfortunately didn't win the lottery for those; we got one slot for NumPy and one for SciPy. We chose the projects of Anne for NumPy and Maja for SciPy: Anne Bonner, "Making "The Basics" a Little More Basic: Improving the Introductory NumPy Sections" [2] Maja Gwozdz, "User-oriented documentation and thorough restructuring" [3] That's not all though. There was some space left in the budget of the NumPy BIDS grant, and Stéfan has reserved that so we can accept more writers and provide them the same mentoring and funding as they would have gotten through GSoD. We could only start the conversations about that once Google made its decisions, so a further announcement will follow. However, we already have one extra project confirmed, from Brandon: Brandon David, "Improve the documentation of scipy.stats" (project details to be published). I will send out a poll to find a good time for everyone for a kickoff call. Our intent is to build a documentation team with multiple writers and mentors interacting and able to help each other out. And all of this will also interact with the numpy.org website redesign and the people putting energy into that:) I'm very happy to welcome Anne, Maja and Brandon! Cheers, Ralf [1] https://developers.google.com/season-of-docs/docs/participants/ [2] https://developers.google.com/season-of-docs/docs/participants/project-numpy [3] https://developers.google.com/season-of-docs/docs/participants/project-scipy

5 7

Numpy twitter handle?
by Abdur-Rahmaan Janhangeer Aug. 18, 2019

Aug. 18, 2019

Greetings, what is the numpy twitter handle? Thanks! Abdur-Rahmaan Janhangeer Mauritius

3 3

ANN: NumExpr 2.7.0 Release
by Robert McLeod Aug. 14, 2019

Aug. 14, 2019

========================= Announcing Numexpr 2.7.0 ========================= Hi everyone, This is a minor version bump for NumExpr. We would like to highlight the changes made in 2.6.9 (which in retrospect should have been a minor version bump), where the maximum number of threads spawned can be limited by setting the environment variable "NUMEXPR_MAX_THREADS". If this variable is not set, in 2.7.0 the historical limit of 8 threads will be used. The lack of a check caused some problems on very large hosts in cluster environments in 2.6.9. In addition, we are officially dropping Python 2.6 support in this release as we cannot perform continuous integration for it. Project documentation is available at: http://numexpr.readthedocs.io/ Changes from 2.6.9 to 2.7.0 ---------------------------- - The default number of 'safe' threads has been restored to the historical limit of 8, if the environment variable "NUMEXPR_MAX_THREADS" has not been set. - Thanks to @eltoder who fixed a small memory leak. - Support for Python 2.6 has been dropped, as it is no longer available via TravisCI. - A typo in the test suite that had a less than rather than greater than symbol in the NumPy version check has been corrected thanks to dhomeier. - The file `site.cfg` was being accidentally included in the sdists on PyPi. It has now been excluded. What's Numexpr? --------------- Numexpr is a fast numerical expression evaluator for NumPy. With it, expressions that operate on arrays (like "3*a+4*b") are accelerated and use less memory than doing the same calculation in Python. It has multi-threaded capabilities, as well as support for Intel's MKL (Math Kernel Library), which allows an extremely fast evaluation of transcendental functions (sin, cos, tan, exp, log...) while squeezing the last drop of performance out of your multi-core processors. Look here for a some benchmarks of numexpr using MKL: https://github.com/pydata/numexpr/wiki/NumexprMKL Its only dependency is NumPy (MKL is optional), so it works well as an easy-to-deploy, easy-to-use, computational engine for projects that don't want to adopt other solutions requiring more heavy dependencies. Where I can find Numexpr? ------------------------- The project is hosted at GitHub in: https://github.com/pydata/numexpr You can get the packages from PyPI as well (but not for RC releases): http://pypi.python.org/pypi/numexpr Documentation is hosted at: http://numexpr.readthedocs.io/en/latest/ Share your experience --------------------- Let us know of any bugs, suggestions, gripes, kudos, etc. you may have. Enjoy data! -- Robert McLeod robbmcleod(a)gmail.com robert.mcleod(a)hitachi-hhtc.ca

1 0

NumPy Community Meeting Wednesday, August 14
by Sebastian Berg Aug. 14, 2019

Aug. 14, 2019

Hi all, There will be a NumPy Community meeting Wednesday August 14 at 11 am Pacific Time. Everyone is invited to join in and edit the work-in- progress meeting topics and notes: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg Best wishes Sebastian

2 2

merging empty bins used by histogram(bins='auto') to avoid MemoryErrors
by Alexander Reeves Aug. 9, 2019

Aug. 9, 2019

Hi all, This thread is to do with the github issues raised in #11879, #10297, #8203 of and possibly others that didn't appear in my search. The main issue is that histogram(bins='auto') will sometimes raise a memory error if the number of automatically-generated bin edges is too large. In all documented cases, the conditions producing outsized bin numbers are when the auto-binning defaults to the 'fd' method. I have taken a crack at minimizing the number of bins used by setting bins to 'auto' in numpy's histogram method. Based on suggestions from eric-weiser, the approach merges empty bins. The method works for the sample datasets in all the issues related to the FD estimator (#11879, #10297, #8203). Note that this method produces unequal bin widths. You can see some code I've already written in a comment on issue #11879 in the link below. https://github.com/numpy/numpy/issues/11879#issuecomment-516686087 Thanks for reading this far. Would be happy to turn this into a PR if there is interest. -areeves87

1 0

ANN: SciPy 1.3.1
by Tyler Reddy Aug. 9, 2019

Aug. 9, 2019

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, On behalf of the SciPy development team I'm pleased to announce the release of SciPy 1.3.1, which is a bug fix release. Sources and binary wheels can be found at: https://pypi.org/project/scipy/ and at: https://github.com/scipy/scipy/releases/tag/v1.3.1 One of a few ways to install this release with pip: pip install scipy==1.3.1 ========================== SciPy 1.3.1 Release Notes ========================== SciPy 1.3.1 is a bug-fix release with no new features compared to 1.3.0. Authors ======= * Matt Haberland * Geordie McBain * Yu Feng * Evgeni Burovski * Sturla Molden * Tapasweni Pathak * Eric Larson * Peter Bell * Carlos Ramos Carreño + * Ralf Gommers * David Hagen * Antony Lee * Ayappan P * Tyler Reddy * Pauli Virtanen A total of 15 people contributed to this release. People with a "+" by their names contributed a patch for the first time. This list of names is automatically generated, and may not be fully complete. Issues closed for 1.3.1 ------------------------------- * `#5040 <https://github.com/scipy/scipy/issues/5040>`__: BUG: Empty data handling of (c)KDTrees * `#9901 <https://github.com/scipy/scipy/issues/9901>`__: lsoda fails to detect stiff problem when called from solve_ivp * `#10206 <https://github.com/scipy/scipy/issues/10206>`__: sparse matrices indexing with scipy 1.3 * `#10232 <https://github.com/scipy/scipy/issues/10232>`__: Exception in loadarff with quoted nominal attributes in scipy... * `#10292 <https://github.com/scipy/scipy/issues/10292>`__: DOC/REL: Some sections of the release notes are not nested correctly. * `#10303 <https://github.com/scipy/scipy/issues/10303>`__: BUG: optimize: `linprog` failing TestLinprogSimplexBland::test_unbounded_below_no_presolve_corrected * `#10376 <https://github.com/scipy/scipy/issues/10376>`__: TST: Travis CI fails (with pytest 5.0 ?) * `#10384 <https://github.com/scipy/scipy/issues/10384>`__: CircleCI doc build failing on new warnings * `#10398 <https://github.com/scipy/scipy/issues/10398>`__: Scipy 1.3.0 build broken in AIX * `#10501 <https://github.com/scipy/scipy/issues/10501>`__: BUG: scipy.spatial.HalfspaceIntersection works incorrectly * `#10514 <https://github.com/scipy/scipy/issues/10514>`__: BUG: cKDTree GIL handling is incorrect * `#10535 <https://github.com/scipy/scipy/issues/10535>`__: TST: master branch CI failures * `#10572 <https://github.com/scipy/scipy/issues/10572>`__: BUG: ckdtree query_ball_point errors on discontiguous input * `#10597 <https://github.com/scipy/scipy/issues/10597>`__: BUG: No warning on PchipInterpolator changing from bernstein base to local power base Pull requests for 1.3.1 ------------------------------ * `#10071 <https://github.com/scipy/scipy/pull/10071>`__: DOC: reconstruct SuperLU permutation matrices avoiding SparseEfficiencyWarning * `#10196 <https://github.com/scipy/scipy/pull/10196>`__: Fewer checks on xdata for curve_fit. * `#10207 <https://github.com/scipy/scipy/pull/10207>`__: BUG: Compressed matrix indexing should return a scalar * `#10233 <https://github.com/scipy/scipy/pull/10233>`__: Fix for ARFF reader regression (#10232) * `#10306 <https://github.com/scipy/scipy/pull/10306>`__: BUG: optimize: Fix for 10303 * `#10309 <https://github.com/scipy/scipy/pull/10309>`__: BUG: Pass jac=None directly to lsoda * `#10377 <https://github.com/scipy/scipy/pull/10377>`__: TST, MAINT: adjustments for pytest 5.0 * `#10379 <https://github.com/scipy/scipy/pull/10379>`__: BUG: sparse: set writeability to be forward-compatible with numpy>=1.17 * `#10426 <https://github.com/scipy/scipy/pull/10426>`__: MAINT: Fix doc build bugs * `#10431 <https://github.com/scipy/scipy/pull/10431>`__: Update numpy version for AIX * `#10457 <https://github.com/scipy/scipy/pull/10457>`__: BUG: Allow ckdtree to accept empty data input * `#10503 <https://github.com/scipy/scipy/pull/10503>`__: BUG: spatial/qhull: get HalfspaceIntersection.dual_points from the correct array * `#10516 <https://github.com/scipy/scipy/pull/10516>`__: BUG: Use nogil contexts in cKDTree * `#10520 <https://github.com/scipy/scipy/pull/10520>`__: DOC: Proper .rst formatting for deprecated features and Backwards incompatible changes * `#10540 <https://github.com/scipy/scipy/pull/10540>`__: MAINT: Fix Travis and Circle * `#10573 <https://github.com/scipy/scipy/pull/10573>`__: BUG: Fix query_ball_point with discontiguous input * `#10600 <https://github.com/scipy/scipy/pull/10600>`__: BUG: interpolate: fix broken conversions between PPoly/BPoly objects Checksums ========= MD5 ~~~ 818dc6325a4511d656582ff2946eed80 scipy-1.3.1-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 83a11b3127b19e71353ee2a04c4be20c scipy-1.3.1-cp35-cp35m-manylinux1_i686.whl 49c52e00706b47b7311171fe37b9efac scipy-1.3.1-cp35-cp35m-manylinux1_x86_64.whl 015b3d443e2a9e4e664a50af64a7f5b6 scipy-1.3.1-cp35-cp35m-win32.whl 43cf62be72bf7b8e42a1a0fad6570e22 scipy-1.3.1-cp35-cp35m-win_amd64.whl 08d697cdeeb2a4121bbeca8d8d756da9 scipy-1.3.1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 25f6364aa052213d4f504bc96031e431 scipy-1.3.1-cp36-cp36m-manylinux1_i686.whl 2fb8c8c5c17dd7d811165b59d070ef4a scipy-1.3.1-cp36-cp36m-manylinux1_x86_64.whl 6559f4a0438d849cac85ea57f1baa3ba scipy-1.3.1-cp36-cp36m-win32.whl 8164a4832b3b5e948135b92f91d6e8fa scipy-1.3.1-cp36-cp36m-win_amd64.whl 1054925a3d2130f803b27a30e8779282 scipy-1.3.1-cp37-cp37m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl cf90a33975bfcd08f7275bbc885785cf scipy-1.3.1-cp37-cp37m-manylinux1_i686.whl a9f6dbda23d81ff544d5e0debcc78320 scipy-1.3.1-cp37-cp37m-manylinux1_x86_64.whl 701657c017eb5164582035232bde5769 scipy-1.3.1-cp37-cp37m-win32.whl f7d8824ff9193c34b10017a1d67ce9fe scipy-1.3.1-cp37-cp37m-win_amd64.whl 69db58ceb4b4c3ff3f3ea816e4e426b9 scipy-1.3.1.tar.gz 66e95ade5399a9a336c1b2b78edb2d3a scipy-1.3.1.tar.xz 62ebcbc144342800c5e6b1c3ba86ba0d scipy-1.3.1.zip SHA256 ~~~~~~ 3ae3692616975d3c10aca6d574d6b4ff95568768d4525f76222fb60f142075b9 scipy-1.3.1-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 7ccfa44a08226825126c4ef0027aa46a38c928a10f0a8a8483c80dd9f9a0ad44 scipy-1.3.1-cp35-cp35m-manylinux1_i686.whl cbc0611699e420774e945f6a4e2830f7ca2b3ee3483fca1aa659100049487dd5 scipy-1.3.1-cp35-cp35m-manylinux1_x86_64.whl 435d19f80b4dcf67dc090cc04fde2c5c8a70b3372e64f6a9c58c5b806abfa5a8 scipy-1.3.1-cp35-cp35m-win32.whl 243b04730d7223d2b844bda9500310eecc9eda0cba9ceaf0cde1839f8287dfa8 scipy-1.3.1-cp35-cp35m-win_amd64.whl 46a5e55850cfe02332998b3aef481d33f1efee1960fe6cfee0202c7dd6fc21ab scipy-1.3.1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl dd3b52e00f93fd1c86f2d78243dfb0d02743c94dd1d34ffea10055438e63b99d scipy-1.3.1-cp36-cp36m-manylinux1_i686.whl 75b513c462e58eeca82b22fc00f0d1875a37b12913eee9d979233349fce5c8b2 scipy-1.3.1-cp36-cp36m-manylinux1_x86_64.whl 396eb4cdad421f846a1498299474f0a3752921229388f91f60dc3eda55a00488 scipy-1.3.1-cp36-cp36m-win32.whl a81da2fe32f4eab8b60d56ad43e44d93d392da228a77e229e59b51508a00299c scipy-1.3.1-cp36-cp36m-win_amd64.whl 0baa64bf42592032f6f6445a07144e355ca876b177f47ad8d0612901c9375bef scipy-1.3.1-cp37-cp37m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl d02d813ec9958ed63b390ded463163685af6025cb2e9a226ec2c477df90c6957 scipy-1.3.1-cp37-cp37m-manylinux1_i686.whl 89dd6a6d329e3f693d1204d5562dd63af0fd7a17854ced17f9cbc37d5b853c8d scipy-1.3.1-cp37-cp37m-manylinux1_x86_64.whl ac37eb652248e2d7cbbfd89619dce5ecfd27d657e714ed049d82f19b162e8d45 scipy-1.3.1-cp37-cp37m-win32.whl a9d606d11eb2eec7ef893eb825017fbb6eef1e1d0b98a5b7fc11446ebeb2b9b1 scipy-1.3.1-cp37-cp37m-win_amd64.whl 2643cfb46d97b7797d1dbdb6f3c23fe3402904e3c90e6facfe6a9b98d808c1b5 scipy-1.3.1.tar.gz 326ffdad79f113659ed0bca80f5d0ed5e28b2e967b438bb1f647d0738073a92e scipy-1.3.1.tar.xz 47dd0ff4a9f17d97e9b68b363c54111f11b73a388cac55069d6e88a602d20552 scipy-1.3.1.zip -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJdTOWrAAoJELD/41ZX0J71Y1UP/ivoDqq6BDDdIB45Oo+XIH6h oZ3c5np+ui/jo/SIF82vM7W/7ZfTEf/BZEKM/ypqO8vk/EltF6jJb8pwyte8Mdic 5hlAQEbLLez2hipGvIIe3K2kS7OFWWorrZWcd+xuZxn9xV3BK4wDXNndpUW61xBF ElKI+HqfwZ6BLSOpDE9UuMWfIQ9wVACr+TtZSmJsQ1A55o9pcMR5HC0HrTBT40Sj SPQM1ECOJw2yNzijaYhEUvPIZsFIHjLqtAVkk+4HG675TtLw0NyqZIw9jhUax6vj rdkj1tSChtSEXE7D2AfZ446bHT+KsxHW6gMXhI96SFi0w698+h2UErZ7uqbnBkQO OAyzewcUp9yqgSf9pciR6WNiRKvPW8yW+l4XJGqERZDePQ1U4d1Ou9yx1efAkb6t j4SxpziM4n3ib3TKzRwQ574EJKKOK5TNYHAwH0BIqN4Ace3aN3D/XNojmelUh8gH d1TklvMGj54pwZjHnqeJMQG+vXbJdI2TXN5qUjFUcsghGvhKPWhl+Un9qoi0+/ZX nBOEXylKF1MkdV1vd4xLS5gFuyCf7EPnJl9vKMHnrkoUuCoxLM2YtAzjgiUiTjK2 lJAxppWZuNMgTcBsDgg6rtHiLcgl44YehPquV1pvs5DrxQzdq5kVwGu7yU2XRSbf QIsVcdAujT8MNGOvoJae =G7vC -----END PGP SIGNATURE-----

1 0

Reformat the wall-of-text release notes
by Matti Picus Aug. 8, 2019

Aug. 8, 2019

2 1

Re: [Numpy-discussion] [SciPy-Dev] Season of Docs - welcome Anne, Maja, Brandon
by Bennet Fauber Aug. 8, 2019

Aug. 8, 2019

I can offer some time for alpha or beta reading and proofreading. I have experience as a proofreader, copy editor (American Statistical Association), and mathematical typesetter (Wiley, Academic Press, Addison-Wesley, et al.). I've taught statistical software workshops, (very) introductory python, have a Software Carpentry instructor certificate, and work daily with people who are finding themselves needing technical and scientific computing but who don't have strong backgrounds. Hopefully that would be good context for early review of a couple of the projects. I will add my name to the poll, if that's OK? -- bennet On Wed, Aug 7, 2019 at 9:03 PM Ralf Gommers <ralf.gommers(a)gmail.com> wrote: > > > > On Tue, Aug 6, 2019 at 4:46 PM Ralf Gommers <ralf.gommers(a)gmail.com> wrote: >> >> Hi all, >> >> Google has announced the Season of Docs participants for this year [1]. We had a lot of excellent candidates and had to make some hard choices. We applied for extra slots, but unfortunately didn't win the lottery for those; we got one slot for NumPy and one for SciPy. We chose the projects of Anne for NumPy and Maja for SciPy: >> >> Anne Bonner, "Making "The Basics" a Little More Basic: Improving the Introductory NumPy Sections" [2] >> >> Maja Gwozdz, "User-oriented documentation and thorough restructuring" [3] >> >> That's not all though. There was some space left in the budget of the NumPy BIDS grant, and Stéfan has reserved that so we can accept more writers and provide them the same mentoring and funding as they would have gotten through GSoD. We could only start the conversations about that once Google made its decisions, so a further announcement will follow. However, we already have one extra project confirmed, from Brandon: >> >> Brandon David, "Improve the documentation of scipy.stats" (project details to be published). > > > Happy to announce that we have a fourth participant: > > Shekhar Rajak, "numpy.org redesign and high level documentation restructuring for end user focus" > > Welcome Shekhar! > >> I will send out a poll to find a good time for everyone for a kickoff call. Our intent is to build a documentation team with multiple writers and mentors interacting and able to help each other out. And all of this will also interact with the numpy.org website redesign and the people putting energy into that:) > > > Here is the poll link: https://doodle.com/poll/skgbk74gsg8zpziu. I hope we can find a time that works for everyone - we're split over all US timezones, Europe and India. So it's going to be early morning or late evening somewhere. > > Sending this out in public, so anyone who wants to participate is welcome to join. I've Bcc'd all participants and mentors, to make sure they see this. > > Cheers, > Ralf > > >> >> >> I'm very happy to welcome Anne, Maja and Brandon! >> >> Cheers, >> Ralf >> >> >> [1] https://developers.google.com/season-of-docs/docs/participants/ >> [2] https://developers.google.com/season-of-docs/docs/participants/project-numpy >> [3] https://developers.google.com/season-of-docs/docs/participants/project-scipy > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev(a)python.org > https://mail.python.org/mailman/listinfo/scipy-dev

2 1

(no subject)
by Charles R Harris Aug. 6, 2019

Aug. 6, 2019

Hi All, There is a PR <https://github.com/numpy/numpy/pull/14197> up that adds a "mode" variable to `multivariate_normal`. It allows choosing various options for factoring the passed covariance. 1. "fast" -- cholesky (x45 legacy method) 2. "default" -- eigh (used in R I believe) 3. "legacy" -- svd (current method) 4. "factor" -- proposed Feedback is welcome. Chuck

1 0

NumPy Community Meeting Wednesday, July 17
by Sebastian Berg Aug. 6, 2019

Aug. 6, 2019

Hi all, There will be a NumPy Community meeting Wednesday August 7 at 11 am Pacific Time. Everyone is invited to join in and edit the work-in- progress meeting topics and notes: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg Best wishes Sebastian PS: (Sorry if you recently updated the file, I may have deleted some changes)

1 0

did anyone create numpy.slack.com?
by Ralf Gommers Aug. 6, 2019

Aug. 6, 2019

Hi all, I was trying to create a Slack workspace named numpy, but it turns out that numpy.slack.com already exists. Does anyone have access to it or knows who is administering it? Thanks, Ralf

3 3

NEP 28 — A standard community policy for dropping support of old Python and NumPy versions
by Thomas Caswell Aug. 6, 2019

Aug. 6, 2019

Folks, This NEP is a proposing a standard policy for the community to determine when we age-out support for old versions of Python. This came out of in-person discussions at SciPy earlier in July and scattered discussion across github. This is being proposed by maintainers from Matplotlib, scikit-learn, IPython, Jupyter, yt, SciPy, NumPy, and scikit-image. TL;DR: We propose only supporting versions of CPython initially released in the preceding 42 months of a major or minor release of any of our projects. Please see https://github.com/numpy/numpy/pull/14086 and keep the discussion there as there are many interested parties (from the other projects) that may not be subscribed to the numpy mailing list. Tom -- Thomas Caswell tcaswell(a)gmail.com

2 1

proposal to accept NEP 28 (numpy.org website redesign)
by Ralf Gommers Aug. 5, 2019

Aug. 5, 2019

Hi all, I propose to accept NEP 28 (https://github.com/numpy/numpy/pull/14032). Discussion seems to have died down, and there have been no major objections raised. In addition to the discussion on the PR, we had some discussion on translations in the community call 1.5 weeks ago. We decided that it was low-risk/impact to simply try this out with one language, and Zijie already volunteered to help so we can try this with Mandarin. Once that's done, we can evaluate the process and the cost/benefit better. If there are no substantive objections within 5 days from this email, then the NEP will be accepted. Cheers, Ralf

1 0