Mailman 3 June 2018 - NumPy-Discussion

NumPy 1.14.4 release
by Charles R Harris June 5, 2018

June 5, 2018

Hi All, The release notes for the NumPy 1.14.4 <https://github.com/numpy/numpy/pull/11251> release are up. Chuck

1 0

Re: [Numpy-discussion] NEP: Random Number Generator Policy
by Kevin Sheppard June 4, 2018

June 4, 2018

I’m not sure if this is within the scope of the NEP or an implementation detail, but I think a new PRNG should use platform independent integer types rather than depending on the platform’s choice of 64-bit data model. This should be enough to ensure that any integer distribution that only uses integers internally should produce identical results across uarch/OS.

2 1

A roadmap for NumPy - longer term planning
by Matti Picus June 4, 2018

June 4, 2018

At the recent NumPy sprint at BIDS (thanks to those who made the trip) we spent some time brainstorming about a roadmap for NumPy, in the spirit of similar work that was done for Jupyter. The idea is that a document with wide community acceptance can guide the work of the full-time developer(s), and be a source of ideas for expanding development efforts. I put the document up at https://github.com/numpy/numpy/wiki/NumPy-Roadmap, and hope to discuss it at a BOF session during SciPy in the middle of July in Austin. Eventually it could become a NEP or formalized in another way. Matti

12 14

Re: [Numpy-discussion] NEP: Random Number Generator Policy
by Kevin Sheppard June 4, 2018

June 4, 2018

The seed() discussion seems unnecessary. StableRandom will need to have a method to set/get state which can be used by any project that needs to get reproducible numbers from the module-level generator. While this is an implementation detail, many generators have much smaller states than MT19937 (a few uint64s). So this is easy enough to hard code where needed.

2 1

Python 3 compatible examples
by Charles R Harris June 1, 2018

June 1, 2018

Hi All, This post is prompted by this PR <https://github.com/numpy/numpy/pull/11222>. It would be good to come up with a timeline and plan for rewriting the examples to be Python 3 compatible. When we do so, we should also make it assumed that `from __future__ import print_function` has been executed when the examples are executed in Python 2.7. Might want to include `division` in that future import as well. Anyway, wanted to raise the subject. Thoughts? Chuck

5 4

Change in default behavior of np.polyfit
by Andreas Nußbaumer June 1, 2018

June 1, 2018

Hi, in [1] the scaling factor for the covariance matrix of `np.polyfit` was discussed. The conclusion was, that it is non-standard and a patch might be in order to correct this. Pull request [2] changes the factor from chisq(popt)/(M-N-2) to chisq(popt)/(M-N) (with M=number of point, N=number of parameters) essentially removing the "-2". Clearly, this changes the result for the covariance matrix (but not the result for the polynomial coefficients) and therefore the current behavior if `cov=True` is set. It should be noted, that `scipy.optimize.curve_fit` also uses the chisq(popt)/(M-N) as scaling factor (without "-2"). Therefore, the change would remove a discrepancy. Additionally, patch [2] adds an option that sets the scaling factor of the covariance matrix to 1 . This can be useful in occasions, where the weights are given by 1/sigma with sigma being the (known) standard errors of (Gaussian distributed) data points, in which case the un-scaled matrix is already a correct estimate for the covariance matrix. Best, Andreas [1] http://numpy-discussion.10968.n7.nabble.com/Inconsistent-results-for-the-co… [2] https://github.com/numpy/numpy/pull/11197

2 1