Mailman 3 January 2016 - 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

C-API: multidimensional array indexing?
by Johann Bauer March 31, 2016

March 31, 2016

Dear experts, is there a C-API function for numpy which implements Python's multidimensional indexing? Say, I have a 2d-array PyArrayObject * M; and an index int i; how do I extract the i-th row or column M[i,:] respectively M[:,i]? I am looking for a function which gives again a PyArrayObject * and which is a view to M (no copied data; the result should be another PyArrayObject whose data and strides points to the correct memory portion of M). I searched the API documentation, Google and mailing lists for quite a long time but didn't find anything. Can you help me? Thanks, Johann

3 3

FeatureRequest: support for array construction from iterators
by Stephan Sahm Feb. 18, 2016

Feb. 18, 2016

[ this request /discussion refers to numpy issue #5863 https://github.com/numpy/numpy/pull/5863#issuecomment-159738368 ] Dear all, As far as I can think, the expected functionality of np.array(...) would be np.array(list(...)) or something even nicer. Therefore, I like to request a generator/iterator support for np.array(...) as far as list(...) supports it. A more detailed reasoning behind this follows now. In general it seems possible to identify iterators/generators as needed for this purpose: - someone actually implemented this feature already (see #5863 <https://mail.google.com/mail/u/0/%E2%80%8Bhttps://github.com/numpy/numpy/pu…> ) - there is ``type.GeneratorType`` and ``collections.abc.Iterator`` for ``isinstance(...)`` check - numpy can destinguish them already from all other types which get well translated into a numpy array Given this, I think the general argument goes roughly like the following: PROS (effect maybe 10% of numpy user or more): - more intuitive overall behaviour, array(...) = array(list(...)) roughly - python3 compatibility (see e.g. #5951 <https://github.com/numpy/numpy/issues/5951>) - compatibility with analog ``__builtin__`` functions (see e.g. #5756 <https://github.com/numpy/numpy/issues/5756>) - all the above make numpy easier to use in an interactive style (e.g. ipython --pylab) (computation not that important, however coding time well) CONS (effect less than 0.1% numpy user I would guess): - might break existing code which in total, at least for me at this stage, speaks in favour of merging the already existing featurebranch (see #5863 <https://mail.google.com/mail/u/0/%E2%80%8Bhttps://github.com/numpy/numpy/pu…> ) or something similar into numpy master . Discussion, please! cheers, Stephan

7 13

Numpy 1.11.0b2 released
by Charles R Harris Feb. 10, 2016

Feb. 10, 2016

Hi All, I hope I am pleased to announce the Numpy 1.11.0b2 release. The first beta was a damp squib due to missing files in the released source files, this release fixes that. The new source filese may be downloaded from sourceforge, no binaries will be released until the mingw tool chain problems are sorted. Please test and report any problem. Chuck

17 43

Numpy 1.11.0b1 is out
by Charles R Harris Feb. 2, 2016

Feb. 2, 2016

Hi All, I'm pleased to announce that Numpy 1.11.0b1 <http://sourceforge.net/projects/numpy/files/NumPy/1.11.0b1/> is now available on sourceforge. This is a source release as the mingw32 toolchain is broken. Please test it out and report any errors that you discover. Hopefully we can do better with 1.11.0 than we did with 1.10.0 ;) Chuck

5 12

Numpy pull requests getting out of hand.
by Charles R Harris Feb. 2, 2016

Feb. 2, 2016

Hi All, There are now 130 open numpy pull requests and it seems almost impossible to keep that number down. My personal decision is that I am going to ignore any new enhancements for the next couple of months and only merge bug fixes, tests, house keeping (style, docs, deprecations), and old PRs. I would also request that other maintainers start looking a taking care of older PRs, either cleaning them up and merging, or closing them. Chuck

4 3

Problem with NumPy 1.10.4 with ATLAS on Python 2.7.8
by Davide Vanzo Jan. 28, 2016

Jan. 28, 2016

Hi all, I recently upgraded NumPy from 1.9.1 to 1.10.4 on Python 2.7.8 by using pip. As always I specified the paths to Blas, Lapack and Atlas in the respective environment variables. I used the same compiler I used to compile both Python and the libraries (GCC 4.6.1). The problem is that it always tries to get Blas symbols in the wrong library: >>> import numpy Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site- packages/numpy/__init__.py", line 180, in <module> from . import add_newdocs File "/usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site- packages/numpy/add_newdocs.py", line 13, in <module> from numpy.lib import add_newdoc File "/usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site- packages/numpy/lib/__init__.py", line 8, in <module> from .type_check import * File "/usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site- packages/numpy/lib/type_check.py", line 11, in <module> import numpy.core.numeric as _nx File "/usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site- packages/numpy/core/__init__.py", line 14, in <module> from . import multiarray ImportError: /usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site- packages/numpy/core/multiarray.so: undefined symbol: cblas_sgemm I also tried to install from source instead of pip but no luck either. The only way to get it to work is to downgrade to 1.9.1. Any idea why? Thanks. Davide

2 2

Proposal for IQR function
by Joseph Fox-Rabinovitz Jan. 28, 2016

Jan. 28, 2016

I have created an IQR function to add to the other dispersion metrics such as standard deviation. I have described the purpose and nature of the proposal in PR#7137, so I am pasting the text here as well: Motivation ---------- This function is used in one place in numpy already (to compute the Freedman-Diaconis histogram bin estimator) in addition to being requested on Stack Overflow a couple of times: - http://stackoverflow.com/questions/23228244/how-do-you-find-the-iqr-in-numpy - http://stackoverflow.com/questions/27472330/how-should-the-interquartile-ra… It is also used in matplotlib for box and violin plots: http://matplotlib.org/faq/howto_faq.html#interpreting-box-plots-and-violin-…. It is a very simple, common and robust dispersion estimator. There does not appear to be an implementation for it anywhere in numpy or scipy. About --------- This function is a convenience combination of `np.percentile` and `np.subtract`. As such, it allows the the difference between any two percentiles to be computed, not necessarily (25, 75), which is the default. All of the recent enhancements to percentile are used. The documentation and testing is borrowed heavily from `np.percentile`. Wikipedia Reference: https://en.wikipedia.org/wiki/Interquartile_range Note ---------- The tests will not pass until the bug-fix for `np.percentile` kwarg `interpolation='midpoint'` (#7129) is incorporated and this PR is rebased.

1 0

Bump warning stacklevel
by Sebastian Berg Jan. 28, 2016

Jan. 28, 2016

Hi all, in my PR about warnings suppression, I currently also have a commit which bumps the warning stacklevel to two (or three), i.e. use: warnings.warn(..., stacklevel=2) (almost) everywhere. This means that for example (take only the empty warning): np.mean([]) would not print: /usr/lib/python2.7/dist-packages/numpy/core/_methods.py:55: RuntimeWarning: Mean of empty slice. warnings.warn("Mean of empty slice.", RuntimeWarning) but instead print the actual `np.mean([])` code line (the repetition of the warning command is always a bit funny). The advantage is nicer printing for the user. The disadvantage would probably mostly be that existing warning filters that use the `module` keyword argument, will fail. Any objections/thoughts about doing this change to try to better report the offending code line? Frankly, I am not sure whether there might be a python standard about this, but I would expect that for a library such as numpy, it makes sense to change. But, if downstream uses warning filters with modules, we might want to reconsider for example. - Sebastian

5 6

Re: [Numpy-discussion] Building Numpy with OpenBLAS
by G Young Jan. 27, 2016

Jan. 27, 2016

Hello all, I'm trying to update the documentation for building Numpy from source, and I've hit a brick wall in trying to build the library using OpenBLAS because I can't seem to link the libopenblas.dll file. I tried following the suggestion of placing the DLL in numpy/core as suggested here <https://github.com/numpy/numpy/wiki/Mingw-static-toolchain#notes> but it still doesn't pick it up. What am I doing wrong? Thanks, Greg

4 9

Re: [Numpy-discussion] Appveyor Testing Changes
by G Young Jan. 26, 2016

Jan. 26, 2016

Hello all, I currently have a branch on my fork (not PR) where I am experimenting with running Appveyor CI via Virtualenv instead of Conda. I have build running here <https://ci.appveyor.com/project/gfyoung/numpy-dr74v/build/1.0.14>. What do people think of using Virtualenv (as we do on Travis) instead of Conda for testing? Thanks, Greg

5 7

Testing warnings
by Sebastian Berg Jan. 26, 2016

Jan. 26, 2016

Hi all, so I have been thinking about this a little more, and I do not think there is a truly nice solution to the python bug: http://bugs.python.org/issue4180 (does not create problems for new pythons). However, I have been so annoyed by trying to test FutureWarnings or DeprecationWarnings in the past that I want *some* improvement. You can do quite a lot by adding some new features, but there are also some limitations. I think that we must be able to: o Filter out warnings on the global test run level. o Find all not explicitly filtered warnings during development easily. o We should be able to test any (almost any?) warnings, even those that would be filtered globally. The next line of considerations for me is, whether we want: o To be able to *print* warnings during test runs? (in release mode) o Be able to not repeat filtering of globally filtered warnings when filtering additional warnings in an individual test? o Be able to count warnings, but ignore other warnings (not the global ones, though). o Filter warnings by module? (might be hard to impossible) And one further option: o Could we accept that testing warnings is *only* possible reliable in Python 3.4+? It would however even mean that we have to fully *skip* tests that would ensure specific warnings to be given. The first things can be achieved setting all warnings to errors on the global level and trying to make the local tests as specific specific as possible. I could go ahead with it. There will likely be some uglier points, but it should work. They do not require funnier new hacks. For all I can see, the second bunch of things requires new features such as in my current PR. So, I want to know whether we can/want to go ahead with this kind of idea [1]. For me personally, I cannot accept we do not provide the first points. The second bunch, I would like some of them (I do not know about printing warnings in release mode?), and skipping tests on Python 2, seems to me even worse then ugly hacks. Getting there is a bit uglier (requires a new context manager for all I see), an I tend to think it is worth the trouble, but I don't think it is vital. In other words, I don't care too much about those points, but I want to get somewhere because I have been bitten often enough by the annoying and in my opinion simply unacceptable (on python 2) use of "ignore" warnings filters in tests. The current state makes finding warnings given in our own tests almost impossible, in the best case they will have to be fixed much much later when the change actually occurs, in the worst case we never find our own real bugs. So where to go? :) - Sebastian [1] I need to fix the module filtering point, the module filtering does not work reliably currently, I think it can be fixed at least 99.5%, but it is not too pretty (not that the user should notice).

1 0

Inconsistent behavior for ufuncs in numpy v1.10.X
by Solbrig,Jeremy Jan. 26, 2016

Jan. 26, 2016

Hello, <http://stackoverflow.com/questions/35005569/behavior-of-ufuncs-and-mathemat…> Much of what is below was copied from this stack overflow question. I am attempting to subclass numpy.ma.MaskedArray. I am currently using Python v2.7.10. The problem discussed below does not occur in Numpy v1.9.2, but does occur in all versions of Numpy v1.10.x. In all versions of Numpy v1.10.x, using mathematical operators on my subclass behaves differently than using the analogous ufunc. When using the ufunc directly (e.g. np.subtract(arr1, arr2)), __array_prepare__, __array_finalize__, and __array_wrap__ are all called as expected, however, when using the symbolic operator (e.g. arr1-arr2) only __array_finalize__ is called. As a consequence, I lose any information stored in arr._optinfo when a mathematical operator is used. Here is a code snippet that illustrates the issue. #!/bin/env python import numpy as np from numpy.ma import MaskedArray, nomask class InfoArray(MaskedArray): def __new__(cls, info=None, data=None, mask=nomask, dtype=None, copy=False, subok=True, ndmin=0, fill_value=None, keep_mask=True, hard_mask=None, shrink=True, **kwargs): obj = super(InfoArray, cls).__new__(cls, data=data, mask=mask, dtype=dtype, copy=copy, subok=subok, ndmin=ndmin, fill_value=fill_value, hard_mask=hard_mask, shrink=shrink, **kwargs) obj._optinfo['info'] = info return obj def __array_prepare__(self, out, context=None): print '__array_prepare__' return super(InfoArray, self).__array_prepare__(out, context) def __array_wrap__(self, out, context=None): print '__array_wrap__' return super(InfoArray, self).__array_wrap__(out, context) def __array_finalize__(self, obj): print '__array_finalize__' return super(InfoArray, self).__array_finalize__(obj) if __name__ == "__main__": arr1 = InfoArray('test', data=[1,2,3,4,5,6]) arr2 = InfoArray(data=[0,1,2,3,4,5]) diff1 = np.subtract(arr1, arr2) print diff1._optinfo diff2 = arr1-arr2 print diff2._optinfo If run, the output looks like this: $ python test_ma_sub.py #Call to np.subtract(arr1, arr2) here __array_finalize__ __array_finalize__ __array_prepare__ __array_finalize__ __array_wrap__ __array_finalize__ {'info': 'test'} #Executing arr1-arr2 here __array_finalize__ {} Currently I have simply downgraded to 1.9.2 to solve the problem for myself, but have been having difficulty figuring out where the difference lies between 1.9.2 and 1.10.0. Thanks, Jeremy

3 9

Make as_strided result writeonly
by Sebastian Berg Jan. 26, 2016

Jan. 26, 2016

Hi all, I have just opened a PR, to make as_strided writeonly (as default). The reasoning for this change is that an `as_strided` array often have self overlapping memory. However, writing to an array where multiple elements have the identical memory address can be confusing, and the results are typically unpredictable. Considering the danger, the proposal is to add a `readonly=True`. A poweruser (who that function is designed for anyway), could thus still get a writeable array. For the moment, writing to the result would raise a FutureWarning with `readonly="warn"`. Do you agree with this, or would it be a major inconvenience? - Sebastian

4 10

PR #7090: ENH: Added 'doane' and 'sqrt' estimators to np.histogram
by Joseph Fox-Rabinovitz Jan. 24, 2016

Jan. 24, 2016

As someone very new to relatively large projects such as numpy, I was wondering how the process works. I have announced my PR with some small enhancements to the histogram function and fixed up all of the comments that were made (originally to PR 7083). What happens next? All I have to go on is http://docs.scipy.org/doc/numpy-1.10.1/dev/gitwash/development_workflow.htm…, but that does not go into detail about what happens after the point I have already reached. Regards, -Joe On Thu, Jan 21, 2016 at 3:37 PM, Joseph Fox-Rabinovitz <jfoxrabinovitz(a)gmail.com> wrote: > Due to a mistake I made in my branch structure, I have replaced this > PR with #7090: https://github.com/numpy/numpy/pull/7090. All of the > changes and fixes so far are squashed into the new request. > > -Joe > > On Thu, Jan 21, 2016 at 1:51 AM, Joseph Fox-Rabinovitz > <jfoxrabinovitz(a)gmail.com> wrote: >> Please let me know if there is anything wrong or missing. I have added >> a couple of estimators that I find useful sometimes. >> >> -Joe

2 2

ANN: scipy 0.17.0 release
by Evgeni Burovski Jan. 23, 2016

Jan. 23, 2016

Hi, On behalf of the Scipy development team I am pleased to announce the availability of Scipy 0.17.0. This release contains several new features, detailed in the release notes below. 101 people contributed to this release over the course of six months. This release requires Python 2.6, 2.7 or 3.2-3.4 and NumPy 1.6.2 or greater. Source tarballs and release notes can be found at https://github.com/scipy/scipy/releases/tag/v0.17.0. Thanks to everyone who contributed to this release. Cheers, Evgeni -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ========================== SciPy 0.17.0 Release Notes ========================== .. contents:: SciPy 0.17.0 is the culmination of 6 months of hard work. It contains many new features, numerous bug-fixes, improved test coverage and better documentation. There have been a number of deprecations and API changes in this release, which are documented below. All users are encouraged to upgrade to this release, as there are a large number of bug-fixes and optimizations. Moreover, our development attention will now shift to bug-fix releases on the 0.17.x branch, and on adding new features on the master branch. This release requires Python 2.6, 2.7 or 3.2-3.5 and NumPy 1.6.2 or greater. Release highlights: - New functions for linear and nonlinear least squares optimization with constraints: `scipy.optimize.lsq_linear` and `scipy.optimize.least_squares` - Support for fitting with bounds in `scipy.optimize.curve_fit`. - Significant improvements to `scipy.stats`, providing many functions with better handing of inputs which have NaNs or are empty, improved documentation, and consistent behavior between `scipy.stats` and `scipy.stats.mstats`. - Significant performance improvements and new functionality in `scipy.spatial.cKDTree`. New features ============ `scipy.cluster` improvements - ---------------------------- A new function `scipy.cluster.hierarchy.cut_tree`, which determines a cut tree from a linkage matrix, was added. `scipy.io` improvements - ----------------------- `scipy.io.mmwrite` gained support for symmetric sparse matrices. `scipy.io.netcdf` gained support for masking and scaling data based on data attributes. `scipy.optimize` improvements - ----------------------------- Linear assignment problem solver ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ `scipy.optimize.linear_sum_assignment` is a new function for solving the linear sum assignment problem. It uses the Hungarian algorithm (Kuhn-Munkres). Least squares optimization ~~~~~~~~~~~~~~~~~~~~~~~~~~ A new function for *nonlinear* least squares optimization with constraints was added: `scipy.optimize.least_squares`. It provides several methods: Levenberg-Marquardt for unconstrained problems, and two trust-region methods for constrained ones. Furthermore it provides different loss functions. New trust-region methods also handle sparse Jacobians. A new function for *linear* least squares optimization with constraints was added: `scipy.optimize.lsq_linear`. It provides a trust-region method as well as an implementation of the Bounded-Variable Least-Squares (BVLS) algorithm. `scipy.optimize.curve_fit` now supports fitting with bounds. `scipy.signal` improvements - --------------------------- A ``mode`` keyword was added to `scipy.signal.spectrogram`, to let it return other spectrograms than power spectral density. `scipy.stats` improvements - -------------------------- Many functions in `scipy.stats` have gained a ``nan_policy`` keyword, which allows specifying how to treat input with NaNs in them: propagate the NaNs, raise an error, or omit the NaNs. Many functions in `scipy.stats` have been improved to correctly handle input arrays that are empty or contain infs/nans. A number of functions with the same name in `scipy.stats` and `scipy.stats.mstats` were changed to have matching signature and behavior. See `gh-5474 <https://github.com/scipy/scipy/issues/5474>`__ for details. `scipy.stats.binom_test` and `scipy.stats.mannwhitneyu` gained a keyword ``alternative``, which allows specifying the hypothesis to test for. Eventually all hypothesis testing functions will get this keyword. For methods of many continuous distributions, complex input is now accepted. Matrix normal distribution has been implemented as `scipy.stats.matrix_normal`. `scipy.sparse` improvements - --------------------------- The `axis` keyword was added to sparse norms, `scipy.sparse.linalg.norm`. `scipy.spatial` improvements - ---------------------------- `scipy.spatial.cKDTree` was partly rewritten for improved performance and several new features were added to it: - - the ``query_ball_point`` method became significantly faster - - ``query`` and ``query_ball_point`` gained an ``n_jobs`` keyword for parallel execution - - build and query methods now release the GIL - - full pickling support - - support for periodic spaces - - the ``sparse_distance_matrix`` method can now return and sparse matrix type `scipy.interpolate` improvements - -------------------------------- Out-of-bounds behavior of `scipy.interpolate.interp1d` has been improved. Use a two-element tuple for the ``fill_value`` argument to specify separate fill values for input below and above the interpolation range. Linear and nearest interpolation kinds of `scipy.interpolate.interp1d` support extrapolation via the ``fill_value="extrapolate"`` keyword. ``fill_value`` can also be set to an array-like (or a two-element tuple of array-likes for separate below and above values) so long as it broadcasts properly to the non-interpolated dimensions of an array. This was implicitly supported by previous versions of scipy, but support has now been formalized and gets compatibility-checked before use. For example, a set of ``y`` values to interpolate with shape ``(2, 3, 5)`` interpolated along the last axis (2) could accept a ``fill_value`` array with shape ``()`` (singleton), ``(1,)``, ``(2, 1)``, ``(1, 3)``, ``(3,)``, or ``(2, 3)``; or it can be a 2-element tuple to specify separate below and above bounds, where each of the two tuple elements obeys proper broadcasting rules. `scipy.linalg` improvements - --------------------------- The default algorithm for `scipy.linalg.leastsq` has been changed to use LAPACK's function ``*gelsd``. Users wanting to get the previous behavior can use a new keyword ``lapack_driver="gelss"`` (allowed values are "gelss", "gelsd" and "gelsy"). ``scipy.sparse`` matrices and linear operators now support the matmul (``@``) operator when available (Python 3.5+). See [PEP 465](http://legacy.python.org/dev/peps/pep-0465/) A new function `scipy.linalg.ordqz`, for QZ decomposition with reordering, has been added. Deprecated features =================== ``scipy.stats.histogram`` is deprecated in favor of ``np.histogram``, which is faster and provides the same functionality. ``scipy.stats.threshold`` and ``scipy.mstats.threshold`` are deprecated in favor of ``np.clip``. See issue #617 for details. ``scipy.stats.ss`` is deprecated. This is a support function, not meant to be exposed to the user. Also, the name is unclear. See issue #663 for details. ``scipy.stats.square_of_sums`` is deprecated. This too is a support function not meant to be exposed to the user. See issues #665 and #663 for details. ``scipy.stats.f_value``, ``scipy.stats.f_value_multivariate``, ``scipy.stats.f_value_wilks_lambda``, and ``scipy.mstats.f_value_wilks_lambda`` are deprecated. These are related to ANOVA, for which ``scipy.stats`` provides quite limited functionality and these functions are not very useful standalone. See issues #660 and #650 for details. ``scipy.stats.chisqprob`` is deprecated. This is an alias. ``stats.chi2.sf`` should be used instead. ``scipy.stats.betai`` is deprecated. This is an alias for ``special.betainc`` which should be used instead. Backwards incompatible changes ============================== The functions ``stats.trim1`` and ``stats.trimboth`` now make sure the elements trimmed are the lowest and/or highest, depending on the case. Slicing without at least partial sorting was previously done, but didn't make sense for unsorted input. When ``variable_names`` is set to an empty list, ``scipy.io.loadmat`` now correctly returns no values instead of all the contents of the MAT file. Element-wise multiplication of sparse matrices now returns a sparse result in all cases. Previously, multiplying a sparse matrix with a dense matrix or array would return a dense matrix. The function ``misc.lena`` has been removed due to license incompatibility. The constructor for ``sparse.coo_matrix`` no longer accepts ``(None, (m,n))`` to construct an all-zero matrix of shape ``(m,n)``. This functionality was deprecated since at least 2007 and was already broken in the previous SciPy release. Use ``coo_matrix((m,n))`` instead. The Cython wrappers in ``linalg.cython_lapack`` for the LAPACK routines ``*gegs``, ``*gegv``, ``*gelsx``, ``*geqpf``, ``*ggsvd``, ``*ggsvp``, ``*lahrd``, ``*latzm``, ``*tzrqf`` have been removed since these routines are not present in the new LAPACK 3.6.0 release. With the exception of the routines ``*ggsvd`` and ``*ggsvp``, these were all deprecated in favor of routines that are currently present in our Cython LAPACK wrappers. Because the LAPACK ``*gegv`` routines were removed in LAPACK 3.6.0. The corresponding Python wrappers in ``scipy.linalg.lapack`` are now deprecated and will be removed in a future release. The source files for these routines have been temporarily included as a part of ``scipy.linalg`` so that SciPy can be built against LAPACK versions that do not provide these deprecated routines. Other changes ============= Html and pdf documentation of development versions of Scipy is now automatically rebuilt after every merged pull request. `scipy.constants` is updated to the CODATA 2014 recommended values. Usage of `scipy.fftpack` functions within Scipy has been changed in such a way that `PyFFTW <http://hgomersall.github.io/pyFFTW/>`__ can easily replace `scipy.fftpack` functions (with improved performance). See `gh-5295 <https://github.com/scipy/scipy/pull/5295>`__ for details. The ``imread`` functions in `scipy.misc` and `scipy.ndimage` were unified, for which a ``mode`` argument was added to `scipy.misc.imread`. Also, bugs for 1-bit and indexed RGB image formats were fixed. ``runtests.py``, the development script to build and test Scipy, now allows building in parallel with ``--parallel``. Authors ======= * @cel4 + * @chemelnucfin + * @endolith * @mamrehn + * @tosh1ki + * Joshua L. Adelman + * Anne Archibald * Hervé Audren + * Vincent Barrielle + * Bruno Beltran + * Sumit Binnani + * Joseph Jon Booker * Olga Botvinnik + * Michael Boyle + * Matthew Brett * Zaz Brown + * Lars Buitinck * Pete Bunch + * Evgeni Burovski * CJ Carey * Ien Cheng + * Cody + * Jaime Fernandez del Rio * Ales Erjavec + * Abraham Escalante * Yves-Rémi Van Eycke + * Yu Feng + * Eric Firing * Francis T. O'Donovan + * André Gaul * Christoph Gohlke * Ralf Gommers * Alex Griffing * Alexander Grigorievskiy * Charles Harris * Jörn Hees + * Ian Henriksen * Derek Homeier + * David Menéndez Hurtado * Gert-Ludwig Ingold * Aakash Jain + * Rohit Jamuar + * Jan Schlüter * Johannes Ballé * Luke Zoltan Kelley + * Jason King + * Andreas Kopecky + * Eric Larson * Denis Laxalde * Antony Lee * Gregory R. Lee * Josh Levy-Kramer + * Sam Lewis + * François Magimel + * Martín Gaitán + * Sam Mason + * Andreas Mayer * Nikolay Mayorov * Damon McDougall + * Robert McGibbon * Sturla Molden * Will Monroe + * Eric Moore * Maniteja Nandana * Vikram Natarajan + * Andrew Nelson * Marti Nito + * Behzad Nouri + * Daisuke Oyama + * Giorgio Patrini + * Fabian Paul + * Christoph Paulik + * Mad Physicist + * Irvin Probst * Sebastian Pucilowski + * Ted Pudlik + * Eric Quintero * Yoav Ram + * Joscha Reimer + * Juha Remes * Frederik Rietdijk + * Rémy Léone + * Christian Sachs + * Skipper Seabold * Sebastian Skoupý + * Alex Seewald + * Andreas Sorge + * Bernardo Sulzbach + * Julian Taylor * Louis Tiao + * Utkarsh Upadhyay + * Jacob Vanderplas * Gael Varoquaux + * Pauli Virtanen * Fredrik Wallner + * Stefan van der Walt * James Webber + * Warren Weckesser * Raphael Wettinger + * Josh Wilson + * Nat Wilson + * Peter Yin + A total of 101 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 0.17.0 - ------------------------ - - `#1923 <https://github.com/scipy/scipy/issues/1923>`__: problem with numpy 0's in stats.poisson.rvs (Trac #1398) - - `#2138 <https://github.com/scipy/scipy/issues/2138>`__: scipy.misc.imread segfaults on 1 bit png (Trac #1613) - - `#2237 <https://github.com/scipy/scipy/issues/2237>`__: distributions do not accept complex arguments (Trac #1718) - - `#2282 <https://github.com/scipy/scipy/issues/2282>`__: scipy.special.hyp1f1(0.5, 1.5, -1000) fails (Trac #1763) - - `#2618 <https://github.com/scipy/scipy/issues/2618>`__: poisson.pmf returns NaN if mu is 0 - - `#2957 <https://github.com/scipy/scipy/issues/2957>`__: hyp1f1 precision issue - - `#2997 <https://github.com/scipy/scipy/issues/2997>`__: FAIL: test_qhull.TestUtilities.test_more_barycentric_transforms - - `#3129 <https://github.com/scipy/scipy/issues/3129>`__: No way to set ranges for fitting parameters in Optimize functions - - `#3191 <https://github.com/scipy/scipy/issues/3191>`__: interp1d should contain a fill_value_below and a fill_value_above... - - `#3453 <https://github.com/scipy/scipy/issues/3453>`__: PchipInterpolator sets slopes at edges differently than Matlab's... - - `#4106 <https://github.com/scipy/scipy/issues/4106>`__: ndimage._ni_support._normalize_sequence() fails with numpy.int64 - - `#4118 <https://github.com/scipy/scipy/issues/4118>`__: `scipy.integrate.ode.set_solout` called after `scipy.integrate.ode.set_initial_value` fails silently - - `#4233 <https://github.com/scipy/scipy/issues/4233>`__: 1D scipy.interpolate.griddata using method=nearest produces nans... - - `#4375 <https://github.com/scipy/scipy/issues/4375>`__: All tests fail due to bad file permissions - - `#4580 <https://github.com/scipy/scipy/issues/4580>`__: scipy.ndimage.filters.convolve documenation is incorrect - - `#4627 <https://github.com/scipy/scipy/issues/4627>`__: logsumexp with sign indicator - enable calculation with negative... - - `#4702 <https://github.com/scipy/scipy/issues/4702>`__: logsumexp with zero scaling factor - - `#4834 <https://github.com/scipy/scipy/issues/4834>`__: gammainc should return 1.0 instead of NaN for infinite x - - `#4838 <https://github.com/scipy/scipy/issues/4838>`__: enh: exprel special function - - `#4862 <https://github.com/scipy/scipy/issues/4862>`__: the scipy.special.boxcox function is inaccurate for denormal... - - `#4887 <https://github.com/scipy/scipy/issues/4887>`__: Spherical harmonic incongruences - - `#4895 <https://github.com/scipy/scipy/issues/4895>`__: some scipy ufuncs have inconsistent output dtypes? - - `#4923 <https://github.com/scipy/scipy/issues/4923>`__: logm does not aggressively convert complex outputs to float - - `#4932 <https://github.com/scipy/scipy/issues/4932>`__: BUG: stats: The `fit` method of the distributions silently ignores... - - `#4956 <https://github.com/scipy/scipy/issues/4956>`__: Documentation error in `scipy.special.bi_zeros` - - `#4957 <https://github.com/scipy/scipy/issues/4957>`__: Docstring for `pbvv_seq` is wrong - - `#4967 <https://github.com/scipy/scipy/issues/4967>`__: block_diag should look at dtypes of all arguments, not only the... - - `#5037 <https://github.com/scipy/scipy/issues/5037>`__: scipy.optimize.minimize error messages are printed to stdout... - - `#5039 <https://github.com/scipy/scipy/issues/5039>`__: Cubic interpolation: On entry to DGESDD parameter number 12 had... - - `#5163 <https://github.com/scipy/scipy/issues/5163>`__: Base case example of Hierarchical Clustering (offer) - - `#5181 <https://github.com/scipy/scipy/issues/5181>`__: BUG: stats.genextreme.entropy should use the explicit formula - - `#5184 <https://github.com/scipy/scipy/issues/5184>`__: Some? wheels don't express a numpy dependency - - `#5197 <https://github.com/scipy/scipy/issues/5197>`__: mstats: test_kurtosis fails (ULP max is 2) - - `#5260 <https://github.com/scipy/scipy/issues/5260>`__: Typo causing an error in splrep - - `#5263 <https://github.com/scipy/scipy/issues/5263>`__: Default epsilon in rbf.py fails for colinear points - - `#5276 <https://github.com/scipy/scipy/issues/5276>`__: Reading empty (no data) arff file fails - - `#5280 <https://github.com/scipy/scipy/issues/5280>`__: 1d scipy.signal.convolve much slower than numpy.convolve - - `#5326 <https://github.com/scipy/scipy/issues/5326>`__: Implementation error in scipy.interpolate.PchipInterpolator - - `#5370 <https://github.com/scipy/scipy/issues/5370>`__: Test issue with test_quadpack and libm.so as a linker script - - `#5426 <https://github.com/scipy/scipy/issues/5426>`__: ERROR: test_stats.test_chisquare_masked_arrays - - `#5427 <https://github.com/scipy/scipy/issues/5427>`__: Automate installing correct numpy versions in numpy-vendor image - - `#5430 <https://github.com/scipy/scipy/issues/5430>`__: Python3 : Numpy scalar types "not iterable"; specific instance... - - `#5450 <https://github.com/scipy/scipy/issues/5450>`__: BUG: spatial.ConvexHull triggers a seg. fault when given nans. - - `#5478 <https://github.com/scipy/scipy/issues/5478>`__: clarify the relation between matrix normal distribution and `multivariate_normal` - - `#5539 <https://github.com/scipy/scipy/issues/5539>`__: lstsq related test failures on windows binaries from numpy-vendor - - `#5560 <https://github.com/scipy/scipy/issues/5560>`__: doc: scipy.stats.burr pdf issue - - `#5571 <https://github.com/scipy/scipy/issues/5571>`__: lstsq test failure after lapack_driver change - - `#5577 <https://github.com/scipy/scipy/issues/5577>`__: ordqz segfault on Python 3.4 in Wine - - `#5578 <https://github.com/scipy/scipy/issues/5578>`__: scipy.linalg test failures on python 3 in Wine - - `#5607 <https://github.com/scipy/scipy/issues/5607>`__: Overloaded ‘isnan(double&)’ is ambiguous when compiling with... - - `#5629 <https://github.com/scipy/scipy/issues/5629>`__: Test for lstsq randomly failed - - `#5630 <https://github.com/scipy/scipy/issues/5630>`__: memory leak with scipy 0.16 spatial cKDEtree - - `#5689 <https://github.com/scipy/scipy/issues/5689>`__: isnan errors compiling scipy/special/Faddeeva.cc with clang++ - - `#5694 <https://github.com/scipy/scipy/issues/5694>`__: fftpack test failure in test_import - - `#5719 <https://github.com/scipy/scipy/issues/5719>`__: curve_fit(method!="lm") ignores initial guess Pull requests for 0.17.0 - ------------------------ - - `#3022 <https://github.com/scipy/scipy/pull/3022>`__: hyp1f1: better handling of large negative arguments - - `#3107 <https://github.com/scipy/scipy/pull/3107>`__: ENH: Add ordered QZ decomposition - - `#4390 <https://github.com/scipy/scipy/pull/4390>`__: ENH: Allow axis and keepdims arguments to be passed to scipy.linalg.norm. - - `#4671 <https://github.com/scipy/scipy/pull/4671>`__: ENH: add axis to sparse norms - - `#4796 <https://github.com/scipy/scipy/pull/4796>`__: ENH: Add cut tree function to scipy.cluster.hierarchy - - `#4809 <https://github.com/scipy/scipy/pull/4809>`__: MAINT: cauchy moments are undefined - - `#4821 <https://github.com/scipy/scipy/pull/4821>`__: ENH: stats: make distribution instances picklable - - `#4839 <https://github.com/scipy/scipy/pull/4839>`__: ENH: Add scipy.special.exprel relative error exponential ufunc - - `#4859 <https://github.com/scipy/scipy/pull/4859>`__: Logsumexp fixes - allows sign flags and b==0 - - `#4865 <https://github.com/scipy/scipy/pull/4865>`__: BUG: scipy.io.mmio.write: error with big indices and low precision - - `#4869 <https://github.com/scipy/scipy/pull/4869>`__: add as_inexact option to _lib._util._asarray_validated - - `#4884 <https://github.com/scipy/scipy/pull/4884>`__: ENH: Finite difference approximation of Jacobian matrix - - `#4890 <https://github.com/scipy/scipy/pull/4890>`__: ENH: Port cKDTree query methods to C++, allow pickling on Python... - - `#4892 <https://github.com/scipy/scipy/pull/4892>`__: how much doctesting is too much? - - `#4896 <https://github.com/scipy/scipy/pull/4896>`__: MAINT: work around a possible numpy ufunc loop selection bug - - `#4898 <https://github.com/scipy/scipy/pull/4898>`__: MAINT: A bit of pyflakes-driven cleanup. - - `#4899 <https://github.com/scipy/scipy/pull/4899>`__: ENH: add 'alternative' keyword to hypothesis tests in stats - - `#4903 <https://github.com/scipy/scipy/pull/4903>`__: BENCH: Benchmarks for interpolate module - - `#4905 <https://github.com/scipy/scipy/pull/4905>`__: MAINT: prepend underscore to mask_to_limits; delete masked_var. - - `#4906 <https://github.com/scipy/scipy/pull/4906>`__: MAINT: Benchmarks for optimize.leastsq - - `#4910 <https://github.com/scipy/scipy/pull/4910>`__: WIP: Trimmed statistics functions have inconsistent API. - - `#4912 <https://github.com/scipy/scipy/pull/4912>`__: MAINT: fix typo in stats tutorial. Closes gh-4911. - - `#4914 <https://github.com/scipy/scipy/pull/4914>`__: DEP: deprecate `scipy.stats.ss` and `scipy.stats.square_of_sums`. - - `#4924 <https://github.com/scipy/scipy/pull/4924>`__: MAINT: if the imaginary part of logm of a real matrix is small,... - - `#4930 <https://github.com/scipy/scipy/pull/4930>`__: BENCH: Benchmarks for signal module - - `#4941 <https://github.com/scipy/scipy/pull/4941>`__: ENH: update `find_repeats`. - - `#4942 <https://github.com/scipy/scipy/pull/4942>`__: MAINT: use np.float64_t instead of np.float_t in cKDTree - - `#4944 <https://github.com/scipy/scipy/pull/4944>`__: BUG: integer overflow in correlate_nd - - `#4951 <https://github.com/scipy/scipy/pull/4951>`__: do not ignore invalid kwargs in distributions fit method - - `#4958 <https://github.com/scipy/scipy/pull/4958>`__: Add some detail to docstrings for special functions - - `#4961 <https://github.com/scipy/scipy/pull/4961>`__: ENH: stats.describe: add bias kw and empty array handling - - `#4963 <https://github.com/scipy/scipy/pull/4963>`__: ENH: scipy.sparse.coo.coo_matrix.__init__: less memory needed - - `#4968 <https://github.com/scipy/scipy/pull/4968>`__: DEP: deprecate ``stats.f_value*`` and ``mstats.f_value*`` functions. - - `#4969 <https://github.com/scipy/scipy/pull/4969>`__: ENH: review `stats.relfreq` and `stats.cumfreq`; fixes to `stats.histogram` - - `#4971 <https://github.com/scipy/scipy/pull/4971>`__: Extend github source links to line ranges - - `#4972 <https://github.com/scipy/scipy/pull/4972>`__: MAINT: impove the error message in validate_runtests_log - - `#4976 <https://github.com/scipy/scipy/pull/4976>`__: DEP: deprecate `scipy.stats.threshold` - - `#4977 <https://github.com/scipy/scipy/pull/4977>`__: MAINT: more careful dtype treatment in block diagonal matrix... - - `#4979 <https://github.com/scipy/scipy/pull/4979>`__: ENH: distributions, complex arguments - - `#4984 <https://github.com/scipy/scipy/pull/4984>`__: clarify dirichlet distribution error handling - - `#4992 <https://github.com/scipy/scipy/pull/4992>`__: ENH: `stats.fligner` and `stats.bartlett` empty input handling. - - `#4996 <https://github.com/scipy/scipy/pull/4996>`__: DOC: fix stats.spearmanr docs - - `#4997 <https://github.com/scipy/scipy/pull/4997>`__: Fix up boxcox for underflow / loss of precision - - `#4998 <https://github.com/scipy/scipy/pull/4998>`__: DOC: improved documentation for `stats.ppcc_max` - - `#5000 <https://github.com/scipy/scipy/pull/5000>`__: ENH: added empty input handling `scipy.moment`; doc enhancements - - `#5003 <https://github.com/scipy/scipy/pull/5003>`__: ENH: improves rankdata algorithm - - `#5005 <https://github.com/scipy/scipy/pull/5005>`__: scipy.stats: numerical stability improvement - - `#5007 <https://github.com/scipy/scipy/pull/5007>`__: ENH: nan handling in functions that use `stats._chk_asarray` - - `#5009 <https://github.com/scipy/scipy/pull/5009>`__: remove coveralls.io - - `#5010 <https://github.com/scipy/scipy/pull/5010>`__: Hypergeometric distribution log survival function - - `#5014 <https://github.com/scipy/scipy/pull/5014>`__: Patch to compute the volume and area of convex hulls - - `#5015 <https://github.com/scipy/scipy/pull/5015>`__: DOC: Fix mistaken variable name in sawtooth - - `#5016 <https://github.com/scipy/scipy/pull/5016>`__: DOC: resample example - - `#5017 <https://github.com/scipy/scipy/pull/5017>`__: DEP: deprecate `stats.betai` and `stats.chisqprob` - - `#5018 <https://github.com/scipy/scipy/pull/5018>`__: ENH: Add test on random inpu to volume computations - - `#5026 <https://github.com/scipy/scipy/pull/5026>`__: BUG: Fix return dtype of lil_matrix.getnnz(axis=0) - - `#5030 <https://github.com/scipy/scipy/pull/5030>`__: DOC: resample slow for prime output too - - `#5033 <https://github.com/scipy/scipy/pull/5033>`__: MAINT: integrate, special: remove unused R1MACH and Makefile - - `#5034 <https://github.com/scipy/scipy/pull/5034>`__: MAINT: signal: lift max_len_seq validation out of Cython - - `#5035 <https://github.com/scipy/scipy/pull/5035>`__: DOC/MAINT: refguide / doctest drudgery - - `#5041 <https://github.com/scipy/scipy/pull/5041>`__: BUG: fixing some small memory leaks detected by cppcheck - - `#5044 <https://github.com/scipy/scipy/pull/5044>`__: [GSoC] ENH: New least-squares algorithms - - `#5050 <https://github.com/scipy/scipy/pull/5050>`__: MAINT: C fixes, trimmed a lot of dead code from Cephes - - `#5057 <https://github.com/scipy/scipy/pull/5057>`__: ENH: sparse: avoid densifying on sparse/dense elementwise mult - - `#5058 <https://github.com/scipy/scipy/pull/5058>`__: TST: stats: add a sample distribution to the test loop - - `#5061 <https://github.com/scipy/scipy/pull/5061>`__: ENH: spatial: faster 2D Voronoi and Convex Hull plotting - - `#5065 <https://github.com/scipy/scipy/pull/5065>`__: TST: improve test coverage for `stats.mvsdist` and `stats.bayes_mvs` - - `#5066 <https://github.com/scipy/scipy/pull/5066>`__: MAINT: fitpack: remove a noop - - `#5067 <https://github.com/scipy/scipy/pull/5067>`__: ENH: empty and nan input handling for `stats.kstat` and `stats.kstatvar` - - `#5071 <https://github.com/scipy/scipy/pull/5071>`__: DOC: optimize: Correct paper reference, add doi - - `#5072 <https://github.com/scipy/scipy/pull/5072>`__: MAINT: scipy.sparse cleanup - - `#5073 <https://github.com/scipy/scipy/pull/5073>`__: DOC: special: Add an example showing the relation of diric to... - - `#5075 <https://github.com/scipy/scipy/pull/5075>`__: DOC: clarified parameterization of stats.lognorm - - `#5076 <https://github.com/scipy/scipy/pull/5076>`__: use int, float, bool instead of np.int, np.float, np.bool - - `#5078 <https://github.com/scipy/scipy/pull/5078>`__: DOC: Rename fftpack docs to README - - `#5081 <https://github.com/scipy/scipy/pull/5081>`__: BUG: Correct handling of scalar 'b' in lsmr and lsqr - - `#5082 <https://github.com/scipy/scipy/pull/5082>`__: loadmat variable_names: don't confuse [] and None. - - `#5083 <https://github.com/scipy/scipy/pull/5083>`__: Fix integrate.fixed_quad docstring to indicate None return value - - `#5086 <https://github.com/scipy/scipy/pull/5086>`__: Use solve() instead of inv() for gaussian_kde - - `#5090 <https://github.com/scipy/scipy/pull/5090>`__: MAINT: stats: add explicit _sf, _isf to gengamma distribution - - `#5094 <https://github.com/scipy/scipy/pull/5094>`__: ENH: scipy.interpolate.NearestNDInterpolator: cKDTree configurable - - `#5098 <https://github.com/scipy/scipy/pull/5098>`__: DOC: special: fix typesetting in ``*_roots quadrature`` functions - - `#5099 <https://github.com/scipy/scipy/pull/5099>`__: DOC: make the docstring of stats.moment raw - - `#5104 <https://github.com/scipy/scipy/pull/5104>`__: DOC/ENH fixes and micro-optimizations for scipy.linalg - - `#5105 <https://github.com/scipy/scipy/pull/5105>`__: enh: made l-bfgs-b parameter for the maximum number of line search... - - `#5106 <https://github.com/scipy/scipy/pull/5106>`__: TST: add NIST test cases to `stats.f_oneway` - - `#5110 <https://github.com/scipy/scipy/pull/5110>`__: [GSoC]: Bounded linear least squares - - `#5111 <https://github.com/scipy/scipy/pull/5111>`__: MAINT: special: Cephes cleanup - - `#5118 <https://github.com/scipy/scipy/pull/5118>`__: BUG: FIR path failed if len(x) < len(b) in lfilter. - - `#5124 <https://github.com/scipy/scipy/pull/5124>`__: ENH: move the filliben approximation to a publicly visible function - - `#5126 <https://github.com/scipy/scipy/pull/5126>`__: StatisticsCleanup: `stats.kruskal` review - - `#5130 <https://github.com/scipy/scipy/pull/5130>`__: DOC: update PyPi trove classifiers. Beta -> Stable. Add license. - - `#5131 <https://github.com/scipy/scipy/pull/5131>`__: DOC: differential_evolution, improve docstring for mutation and... - - `#5132 <https://github.com/scipy/scipy/pull/5132>`__: MAINT: differential_evolution improve init_population_lhs comments... - - `#5133 <https://github.com/scipy/scipy/pull/5133>`__: MRG: rebased mmio refactoring - - `#5135 <https://github.com/scipy/scipy/pull/5135>`__: MAINT: `stats.mstats` consistency with `stats.stats` - - `#5139 <https://github.com/scipy/scipy/pull/5139>`__: TST: linalg: add a smoke test for gh-5039 - - `#5140 <https://github.com/scipy/scipy/pull/5140>`__: EHN: Update constants.codata to CODATA 2014 - - `#5145 <https://github.com/scipy/scipy/pull/5145>`__: added ValueError to docstring as possible error raised - - `#5146 <https://github.com/scipy/scipy/pull/5146>`__: MAINT: Improve implementation details and doc in `stats.shapiro` - - `#5147 <https://github.com/scipy/scipy/pull/5147>`__: [GSoC] ENH: Upgrades to curve_fit - - `#5150 <https://github.com/scipy/scipy/pull/5150>`__: Fix misleading wavelets/cwt example - - `#5152 <https://github.com/scipy/scipy/pull/5152>`__: BUG: cluster.hierarchy.dendrogram: missing font size doesn't... - - `#5153 <https://github.com/scipy/scipy/pull/5153>`__: add keywords to control the summation in discrete distributions... - - `#5156 <https://github.com/scipy/scipy/pull/5156>`__: DOC: added comments on algorithms used in Legendre function - - `#5158 <https://github.com/scipy/scipy/pull/5158>`__: ENH: optimize: add the Hungarian algorithm - - `#5162 <https://github.com/scipy/scipy/pull/5162>`__: FIX: Remove lena - - `#5164 <https://github.com/scipy/scipy/pull/5164>`__: MAINT: fix cluster.hierarchy.dendrogram issues and docs - - `#5166 <https://github.com/scipy/scipy/pull/5166>`__: MAINT: changed `stats.pointbiserialr` to delegate to `stats.pearsonr` - - `#5167 <https://github.com/scipy/scipy/pull/5167>`__: ENH: add nan_policy to `stats.kendalltau`. - - `#5168 <https://github.com/scipy/scipy/pull/5168>`__: TST: added nist test case (Norris) to `stats.linregress`. - - `#5169 <https://github.com/scipy/scipy/pull/5169>`__: update lpmv docstring - - `#5171 <https://github.com/scipy/scipy/pull/5171>`__: Clarify metric parameter in linkage docstring - - `#5172 <https://github.com/scipy/scipy/pull/5172>`__: ENH: add mode keyword to signal.spectrogram - - `#5177 <https://github.com/scipy/scipy/pull/5177>`__: DOC: graphical example for KDTree.query_ball_point - - `#5179 <https://github.com/scipy/scipy/pull/5179>`__: MAINT: stats: tweak the formula for ncx2.pdf - - `#5188 <https://github.com/scipy/scipy/pull/5188>`__: MAINT: linalg: A bit of clean up. - - `#5189 <https://github.com/scipy/scipy/pull/5189>`__: BUG: stats: Use the explicit formula in stats.genextreme.entropy - - `#5193 <https://github.com/scipy/scipy/pull/5193>`__: BUG: fix uninitialized use in lartg - - `#5194 <https://github.com/scipy/scipy/pull/5194>`__: BUG: properly return error to fortran from ode_jacobian_function - - `#5198 <https://github.com/scipy/scipy/pull/5198>`__: TST: Fix TestCtypesQuad failure on Python 3.5 for Windows - - `#5201 <https://github.com/scipy/scipy/pull/5201>`__: allow extrapolation in interp1d - - `#5209 <https://github.com/scipy/scipy/pull/5209>`__: MAINT: Change complex parameter to boolean in Y_() - - `#5213 <https://github.com/scipy/scipy/pull/5213>`__: BUG: sparse: fix logical comparison dtype conflicts - - `#5216 <https://github.com/scipy/scipy/pull/5216>`__: BUG: sparse: fixing unbound local error - - `#5218 <https://github.com/scipy/scipy/pull/5218>`__: DOC and BUG: Bessel function docstring improvements, fix array_like,... - - `#5222 <https://github.com/scipy/scipy/pull/5222>`__: MAINT: sparse: fix COO ctor - - `#5224 <https://github.com/scipy/scipy/pull/5224>`__: DOC: optimize: type of OptimizeResult.hess_inv varies - - `#5228 <https://github.com/scipy/scipy/pull/5228>`__: ENH: Add maskandscale support to netcdf; based on pupynere and... - - `#5229 <https://github.com/scipy/scipy/pull/5229>`__: DOC: sparse.linalg.svds doc typo fixed - - `#5234 <https://github.com/scipy/scipy/pull/5234>`__: MAINT: sparse: simplify COO ctor - - `#5235 <https://github.com/scipy/scipy/pull/5235>`__: MAINT: sparse: warn on todia() with many diagonals - - `#5236 <https://github.com/scipy/scipy/pull/5236>`__: MAINT: ndimage: simplify thread handling/recursion + constness - - `#5239 <https://github.com/scipy/scipy/pull/5239>`__: BUG: integrate: Fixed issue 4118 - - `#5241 <https://github.com/scipy/scipy/pull/5241>`__: qr_insert fixes, closes #5149 - - `#5246 <https://github.com/scipy/scipy/pull/5246>`__: Doctest tutorial files - - `#5247 <https://github.com/scipy/scipy/pull/5247>`__: DOC: optimize: typo/import fix in linear_sum_assignment - - `#5248 <https://github.com/scipy/scipy/pull/5248>`__: remove inspect.getargspec and test python 3.5 on Travis CI - - `#5250 <https://github.com/scipy/scipy/pull/5250>`__: BUG: Fix sparse multiply by single-element zero - - `#5261 <https://github.com/scipy/scipy/pull/5261>`__: Fix bug causing a TypeError in splrep when a runtime warning... - - `#5262 <https://github.com/scipy/scipy/pull/5262>`__: Follow up to 4489 (Addition LAPACK routines in linalg.lstsq) - - `#5264 <https://github.com/scipy/scipy/pull/5264>`__: ignore zero-length edges for default epsilon - - `#5269 <https://github.com/scipy/scipy/pull/5269>`__: DOC: Typos and spell-checking - - `#5272 <https://github.com/scipy/scipy/pull/5272>`__: MAINT: signal: Convert array syntax to memoryviews - - `#5273 <https://github.com/scipy/scipy/pull/5273>`__: DOC: raw strings for docstrings with math - - `#5274 <https://github.com/scipy/scipy/pull/5274>`__: MAINT: sparse: update cython code for MST - - `#5278 <https://github.com/scipy/scipy/pull/5278>`__: BUG: io: Stop guessing the data delimiter in ARFF files. - - `#5289 <https://github.com/scipy/scipy/pull/5289>`__: BUG: misc: Fix the Pillow work-around for 1-bit images. - - `#5291 <https://github.com/scipy/scipy/pull/5291>`__: ENH: call np.correlate for 1d in scipy.signal.correlate - - `#5294 <https://github.com/scipy/scipy/pull/5294>`__: DOC: special: Remove a potentially misleading example from the... - - `#5295 <https://github.com/scipy/scipy/pull/5295>`__: Simplify replacement of fftpack by pyfftw - - `#5296 <https://github.com/scipy/scipy/pull/5296>`__: ENH: Add matrix normal distribution to stats - - `#5297 <https://github.com/scipy/scipy/pull/5297>`__: Fixed leaf_rotation and leaf_font_size in Python 3 - - `#5303 <https://github.com/scipy/scipy/pull/5303>`__: MAINT: stats: rewrite find_repeats - - `#5307 <https://github.com/scipy/scipy/pull/5307>`__: MAINT: stats: remove unused Fortran routine - - `#5313 <https://github.com/scipy/scipy/pull/5313>`__: BUG: sparse: fix diags for nonsquare matrices - - `#5315 <https://github.com/scipy/scipy/pull/5315>`__: MAINT: special: Cephes cleanup - - `#5316 <https://github.com/scipy/scipy/pull/5316>`__: fix input check for sparse.linalg.svds - - `#5319 <https://github.com/scipy/scipy/pull/5319>`__: MAINT: Cython code maintenance - - `#5328 <https://github.com/scipy/scipy/pull/5328>`__: BUG: Fix place_poles return values - - `#5329 <https://github.com/scipy/scipy/pull/5329>`__: avoid a spurious divide-by-zero in Student t stats - - `#5334 <https://github.com/scipy/scipy/pull/5334>`__: MAINT: integrate: miscellaneous cleanup - - `#5340 <https://github.com/scipy/scipy/pull/5340>`__: MAINT: Printing Error Msg to STDERR and Removing iterate.dat - - `#5347 <https://github.com/scipy/scipy/pull/5347>`__: ENH: add Py3.5-style matmul operator (e.g. A @ B) to sparse linear... - - `#5350 <https://github.com/scipy/scipy/pull/5350>`__: FIX error, when reading 32-bit float wav files - - `#5351 <https://github.com/scipy/scipy/pull/5351>`__: refactor the PCHIP interpolant's algorithm - - `#5354 <https://github.com/scipy/scipy/pull/5354>`__: MAINT: construct csr and csc matrices from integer lists - - `#5359 <https://github.com/scipy/scipy/pull/5359>`__: add a fast path to interp1d - - `#5364 <https://github.com/scipy/scipy/pull/5364>`__: Add two fill_values to interp1d. - - `#5365 <https://github.com/scipy/scipy/pull/5365>`__: ABCD docstrings - - `#5366 <https://github.com/scipy/scipy/pull/5366>`__: Fixed typo in the documentation for scipy.signal.cwt() per #5290. - - `#5367 <https://github.com/scipy/scipy/pull/5367>`__: DOC updated scipy.spatial.Delaunay example - - `#5368 <https://github.com/scipy/scipy/pull/5368>`__: ENH: Do not create a throwaway class at every function call - - `#5372 <https://github.com/scipy/scipy/pull/5372>`__: DOC: spectral: fix reference formatting - - `#5375 <https://github.com/scipy/scipy/pull/5375>`__: PEP8 amendments to ffpack_basic.py - - `#5377 <https://github.com/scipy/scipy/pull/5377>`__: BUG: integrate: builtin name no longer shadowed - - `#5381 <https://github.com/scipy/scipy/pull/5381>`__: PEP8ified fftpack_pseudo_diffs.py - - `#5385 <https://github.com/scipy/scipy/pull/5385>`__: BLD: fix Bento build for changes to optimize and spatial - - `#5386 <https://github.com/scipy/scipy/pull/5386>`__: STY: PEP8 amendments to interpolate.py - - `#5387 <https://github.com/scipy/scipy/pull/5387>`__: DEP: deprecate stats.histogram - - `#5388 <https://github.com/scipy/scipy/pull/5388>`__: REL: add "make upload" command to doc/Makefile. - - `#5389 <https://github.com/scipy/scipy/pull/5389>`__: DOC: updated origin param of scipy.ndimage.filters.convolve - - `#5395 <https://github.com/scipy/scipy/pull/5395>`__: BUG: special: fix a number of edge cases related to `x = np.inf`. - - `#5398 <https://github.com/scipy/scipy/pull/5398>`__: MAINT: stats: avoid spurious warnings in lognorm.pdf(0, s) - - `#5407 <https://github.com/scipy/scipy/pull/5407>`__: ENH: stats: Handle mu=0 in stats.poisson - - `#5409 <https://github.com/scipy/scipy/pull/5409>`__: Fix the behavior of discrete distributions at the right-hand... - - `#5412 <https://github.com/scipy/scipy/pull/5412>`__: TST: stats: skip a test to avoid a spurious log(0) warning - - `#5413 <https://github.com/scipy/scipy/pull/5413>`__: BUG: linalg: work around LAPACK single-precision lwork computation... - - `#5414 <https://github.com/scipy/scipy/pull/5414>`__: MAINT: stats: move creation of namedtuples outside of function... - - `#5415 <https://github.com/scipy/scipy/pull/5415>`__: DOC: fix up sections in ToC in the pdf reference guide - - `#5416 <https://github.com/scipy/scipy/pull/5416>`__: TST: fix issue with a ctypes test for integrate on Fedora. - - `#5418 <https://github.com/scipy/scipy/pull/5418>`__: DOC: fix bugs in signal.TransferFunction docstring. Closes gh-5287. - - `#5419 <https://github.com/scipy/scipy/pull/5419>`__: MAINT: sparse: fix usage of NotImplementedError - - `#5420 <https://github.com/scipy/scipy/pull/5420>`__: Raise proper error if maxiter < 1 - - `#5422 <https://github.com/scipy/scipy/pull/5422>`__: DOC: changed documentation of brent to be consistent with bracket - - `#5444 <https://github.com/scipy/scipy/pull/5444>`__: BUG: gaussian_filter, BPoly.from_derivatives fail on numpy int... - - `#5445 <https://github.com/scipy/scipy/pull/5445>`__: MAINT: stats: fix incorrect deprecation warnings and test noise - - `#5446 <https://github.com/scipy/scipy/pull/5446>`__: DOC: add note about PyFFTW in fftpack tutorial. - - `#5459 <https://github.com/scipy/scipy/pull/5459>`__: DOC: integrate: Some improvements to the differential equation... - - `#5465 <https://github.com/scipy/scipy/pull/5465>`__: BUG: Relax mstats kurtosis test tolerance by a few ulp - - `#5471 <https://github.com/scipy/scipy/pull/5471>`__: ConvexHull should raise ValueError for NaNs. - - `#5473 <https://github.com/scipy/scipy/pull/5473>`__: MAINT: update decorators.py module to version 4.0.5 - - `#5476 <https://github.com/scipy/scipy/pull/5476>`__: BUG: imsave searches for wrong channel axis if image has 3 or... - - `#5477 <https://github.com/scipy/scipy/pull/5477>`__: BLD: add numpy to setup/install_requires for OS X wheels - - `#5479 <https://github.com/scipy/scipy/pull/5479>`__: ENH: return Jacobian/Hessian from BasinHopping - - `#5484 <https://github.com/scipy/scipy/pull/5484>`__: BUG: fix ttest zero division handling - - `#5486 <https://github.com/scipy/scipy/pull/5486>`__: Fix crash on kmeans2 - - `#5491 <https://github.com/scipy/scipy/pull/5491>`__: MAINT: Expose parallel build option to runtests.py - - `#5494 <https://github.com/scipy/scipy/pull/5494>`__: Sort OptimizeResult.__repr__ by key - - `#5496 <https://github.com/scipy/scipy/pull/5496>`__: DOC: update the author name mapping - - `#5497 <https://github.com/scipy/scipy/pull/5497>`__: Enhancement to binned_statistic: option to unraveled returned... - - `#5498 <https://github.com/scipy/scipy/pull/5498>`__: BUG: sparse: fix a bug in sparsetools input dtype resolution - - `#5500 <https://github.com/scipy/scipy/pull/5500>`__: DOC: detect unprintable characters in docstrings - - `#5505 <https://github.com/scipy/scipy/pull/5505>`__: BUG: misc: Ensure fromimage converts mode 'P' to 'RGB' or 'RGBA'. - - `#5514 <https://github.com/scipy/scipy/pull/5514>`__: DOC: further update the release notes - - `#5515 <https://github.com/scipy/scipy/pull/5515>`__: ENH: optionally disable fixed-point acceleration - - `#5517 <https://github.com/scipy/scipy/pull/5517>`__: DOC: Improvements and additions to the matrix_normal doc - - `#5518 <https://github.com/scipy/scipy/pull/5518>`__: Remove wrappers for LAPACK deprecated routines - - `#5521 <https://github.com/scipy/scipy/pull/5521>`__: TST: skip a linalg.orth memory test on 32-bit platforms. - - `#5523 <https://github.com/scipy/scipy/pull/5523>`__: DOC: change a few floats to integers in docstring examples - - `#5524 <https://github.com/scipy/scipy/pull/5524>`__: DOC: more updates to 0.17.0 release notes. - - `#5525 <https://github.com/scipy/scipy/pull/5525>`__: Fix to minor typo in documentation for scipy.integrate.ode - - `#5527 <https://github.com/scipy/scipy/pull/5527>`__: TST: bump arccosh tolerance to allow for inaccurate numpy or... - - `#5535 <https://github.com/scipy/scipy/pull/5535>`__: DOC: signal: minor clarification to docstring of TransferFunction. - - `#5538 <https://github.com/scipy/scipy/pull/5538>`__: DOC: signal: fix find_peaks_cwt documentation - - `#5545 <https://github.com/scipy/scipy/pull/5545>`__: MAINT: Fix typo in linalg/basic.py - - `#5547 <https://github.com/scipy/scipy/pull/5547>`__: TST: mark TestEig.test_singular as knownfail in master. - - `#5550 <https://github.com/scipy/scipy/pull/5550>`__: MAINT: work around lstsq driver selection issue - - `#5556 <https://github.com/scipy/scipy/pull/5556>`__: BUG: Fixed broken dogbox trust-region radius update - - `#5561 <https://github.com/scipy/scipy/pull/5561>`__: BUG: eliminate warnings, exception (on Win) in test_maskandscale;... - - `#5567 <https://github.com/scipy/scipy/pull/5567>`__: TST: a few cleanups in the test suite; run_module_suite and clearer... - - `#5568 <https://github.com/scipy/scipy/pull/5568>`__: MAINT: simplify poisson's _argcheck - - `#5569 <https://github.com/scipy/scipy/pull/5569>`__: TST: bump GMean test tolerance to make it pass on Wine - - `#5572 <https://github.com/scipy/scipy/pull/5572>`__: TST: lstsq: bump test tolerance for TravisCI - - `#5573 <https://github.com/scipy/scipy/pull/5573>`__: TST: remove use of np.fromfile from cluster.vq tests - - `#5576 <https://github.com/scipy/scipy/pull/5576>`__: Lapack deprecations - - `#5579 <https://github.com/scipy/scipy/pull/5579>`__: TST: skip tests of linalg.norm axis keyword on numpy <= 1.7.x - - `#5582 <https://github.com/scipy/scipy/pull/5582>`__: Clarify language of survival function documentation - - `#5583 <https://github.com/scipy/scipy/pull/5583>`__: MAINT: stats/tests: A bit of clean up. - - `#5588 <https://github.com/scipy/scipy/pull/5588>`__: DOC: stats: Add a note that stats.burr is the Type III Burr distribution. - - `#5595 <https://github.com/scipy/scipy/pull/5595>`__: TST: fix test_lamch failures on Python 3 - - `#5600 <https://github.com/scipy/scipy/pull/5600>`__: MAINT: Ignore spatial/ckdtree.cxx and .h - - `#5602 <https://github.com/scipy/scipy/pull/5602>`__: Explicitly numbered replacement fields for maintainability - - `#5605 <https://github.com/scipy/scipy/pull/5605>`__: MAINT: collection of small fixes to test suite - - `#5614 <https://github.com/scipy/scipy/pull/5614>`__: Minor doc change. - - `#5624 <https://github.com/scipy/scipy/pull/5624>`__: FIX: Fix interpolate - - `#5625 <https://github.com/scipy/scipy/pull/5625>`__: BUG: msvc9 binaries crash when indexing std::vector of size 0 - - `#5635 <https://github.com/scipy/scipy/pull/5635>`__: BUG: misspelled __dealloc__ in cKDTree. - - `#5642 <https://github.com/scipy/scipy/pull/5642>`__: STY: minor fixup of formatting of 0.17.0 release notes. - - `#5643 <https://github.com/scipy/scipy/pull/5643>`__: BLD: fix a build issue in special/Faddeeva.cc with isnan. - - `#5661 <https://github.com/scipy/scipy/pull/5661>`__: TST: linalg tests used stdlib random instead of numpy.random. - - `#5682 <https://github.com/scipy/scipy/pull/5682>`__: backports for 0.17.0 - - `#5696 <https://github.com/scipy/scipy/pull/5696>`__: Minor improvements to least_squares' docstring. - - `#5697 <https://github.com/scipy/scipy/pull/5697>`__: BLD: fix for isnan/isinf issues in special/Faddeeva.cc - - `#5720 <https://github.com/scipy/scipy/pull/5720>`__: TST: fix for file opening error in fftpack test_import.py - - `#5722 <https://github.com/scipy/scipy/pull/5722>`__: BUG: Make curve_fit respect an initial guess with bounds - - `#5726 <https://github.com/scipy/scipy/pull/5726>`__: Backports for v0.17.0rc2 - - `#5727 <https://github.com/scipy/scipy/pull/5727>`__: API: Changes to least_squares API Checksums ========= MD5 ~~~ 5ff2971e1ce90e762c59d2cd84837224 scipy-0.17.0.tar.gz ef0949640ee73f845dde6dd7f84d7691 scipy-0.17.0.tar.xz 28a4fe29e980804db162524f10873211 scipy-0.17.0.zip SHA256 ~~~~~~ f600b755fb69437d0f70361f9e560ab4d304b1b66987ed5a28bdd9dd7793e089 scipy-0.17.0.tar.gz 2bc03ea36cd55bfd80869d87f690334b4cad240373e05857ddfa7a4d1e2f9a7a scipy-0.17.0.tar.xz ede6820030b2e5796126aa1571d86738b14bbd670d68c83378877b1d9eb9894d scipy-0.17.0.zip -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJWokWbAAoJEIp0pQ0zQcu+JUgH/16Qqurptl3jUU11+4pl+8ji 3AFZN+dgzGLyiMz9s+V+OyL4hcdZY4++WM2QizF5uD3hDDFNi+aJRHAYySMAZeIZ O8y//v+DXDVOLZpKwcPFq5E5ZebTDh1jO4zZzpuyi1PnKgTAEKZeSyBSMd0RMx/p kZ0URTcAa/tPgkNZz3+i8By9b/zBWOlbI+v6fCVwV8E20YWfGBSp2s0KAtQk787D Q88ylnc3Zfv4IR1hgCFZz6oJA0RgmpH4USKi7guyg+fIKjf1nFe64zIuV3C2r/Uj y9Qbs/8x/HTteDp5owkRiSwnpTZHOtx/jqeh2z/w9aQe0i8Nag5Ere6JZ2kixG4= =jZUn -----END PGP SIGNATURE-----

3 4

deprecating assignment to ndarray.data
by Nathaniel Smith Jan. 22, 2016

Jan. 22, 2016

So it turns out that ndarray.data supports assignment at the Python level, and what it does is just assign to the ->data field of the ndarray object: https://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/getset… This kind of assignment been deprecated at the C level since 1.7, and is totally unsafe -- if there are any views pointing to the array when this happens, then they'll be left pointing off into unallocated memory. E.g.: a = np.arange(10) b = np.linspace(0, 1, 10) c = a.view() a.data = b.data # Now c points into free'd memory Can we deprecate or just remove this? (Also filed issue: https://github.com/numpy/numpy/issues/7093) -n -- Nathaniel J. Smith -- https://vorpus.org

3 4

Set FutureWarnings to error in (dev) tests?
by Sebastian Berg Jan. 22, 2016

Jan. 22, 2016

Hi all, should we try to set FutureWarnings to errors in dev tests? I am seriously annoyed by FutureWarnings getting lost all over for two reasons. First, it is hard to impossible to find even our own errors for our own FutureWarning changes. Secondly, we currently would not even see any Futurewarnings from someone else. For numpy that may not be a big issue, but still. So, I was starting to try it, and it is annoying obviously. The only serious issue, though, seems actually MA [1]. Sometimes one would add a filter for a whole test file (for my start I did this for the NaT stuff) [2]. Anyway, should we attempt to do this? I admit that trying to make it work, even *with* the change FutureWarnings suddenly pop up when you make the warnings being given less often (I will guess that warning was already issued at import time somewhere). - Sebastian [1] And at that a brand new future warning there, which seems too agressive in any case, though that won't change much. [2] One annoying thing about this, the filter might never be removed. One could add a canary maybe to error out when the filter is not needed anymore.

2 6

ANN: xarray (formerly xray) v0.7.0 released
by Stephan Hoyer Jan. 22, 2016

Jan. 22, 2016

I am pleased to announce version v0.7.0 of xarray, the project formerly known as xray. xarray is an open source project and Python package that aims to bring the labeled data power of pandas to the physical sciences, by providing N-dimensional variants of the core pandas data structures. These data structures are based on the data model of the netCDF file format. In this latest release, we have renamed the project from "xray" to "xarray". This avoids a namespace conflict with the entire field of X-ray science. We have new URLs for our documentation, source code and mailing list: http://xarray.pydata.org/ http://github.com/pydata/xarray/ https://groups.google.com/forum/#!forum/xarray Highlights of this release: * An internal refactor of DataArray internals * New methods for reshaping, rolling and shifting data * Preliminary support for pandas.MultiIndex * Support for reading GRIB, HDF4 and other file formats via PyNIO For more details, read the full release notes: http://xarray.pydata.org/en/stable/whats-new.html Contributors to this release: Antony Lee Fabien Maussion Joe Hamman Maximilian Roos Stephan Hoyer Takeshi Kanmae femtotrader I'd also like to highlight the contributions of Clark Fitzgerald, who added a plotting module to xray in v0.6, and Dave Brown, for his assistance adding PyNIO support. Best, Stephan

1 0

PR #7083: ENH: Added 'doane' and 'sqrt' estimators to np.histogram
by Joseph Fox-Rabinovitz Jan. 21, 2016

Jan. 21, 2016

Please let me know if there is anything wrong or missing. I have added a couple of estimators that I find useful sometimes. -Joe

2 3

Re: [Numpy-discussion] PR #7083: ENH: Added 'doane' and 'sqrt' estimators to np.histogram
by Joseph Fox-Rabinovitz Jan. 21, 2016

Jan. 21, 2016

Where can I find the output of the tests on GitHub? I seem to be having trouble locating them. -Joe Sent from my LG Optimus L70™ ------ Original message------From: Jaime Fernández del RíoDate: Thu, Jan 21, 2016 02:17To: Discussion of Numerical Python;Subject:Re: [Numpy-discussion] PR #7083: ENH: Added 'doane' and 'sqrt' estimators to np.histogramThe tests are not passing, seems like you are taking the sqrt of a negative number, may want to check the inputs and raise a more informative error (and add a test for it). Jaime On Thu, Jan 21, 2016 at 7:51 AM, Joseph Fox-Rabinovitz <jfoxrabinovitz(a)gmail.com> wrote: Please let me know if there is anything wrong or missing. I have added a couple of estimators that I find useful sometimes. -Joe _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion(a)scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion -- (__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.

1 0

Behavior of np.random.uniform
by Jaime Fernández del Río Jan. 21, 2016

Jan. 21, 2016

Hi all, There is a PR (#7026 <https://github.com/numpy/numpy/pull/7026>) that documents the current behavior of np.random.uniform when the low and high parameters it takes do not conform to the expected low < high. Basically: - if low < high, random numbers are drawn from [low, high), - if low = high, all random numbers will be equal to low, and - if low > high, random numbers are drawn from (high, low] (notice the change in the open side of the interval.) My only worry is that, once we document this, we can no longer claim that it is a bug. So I would like to hear from others what do they think. The other more or less obvious options would be to: - Raise an error, but this would require a deprecation cycle, as people may be relying on the current undocumented behavior. - Check the inputs and draw numbers from [min(low, high), max(low, high)), which is minimally different from current behavior. I will be merging the current documentation changes in the next few days, so it would be good if any concerns were voiced before that. Thanks, Jaime -- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.

11 18

Should I use pip install numpy in linux?
by Yuxiang Wang Jan. 21, 2016

Jan. 21, 2016

Dear all, I know that in Windows, we should use either Christoph's package or Anaconda for MKL-optimized numpy. In Linux, the fortran compiler issue is solved, so should I directly used pip install numpy to get numpy with a reasonable BLAS library? Thanks! Shawn -- Yuxiang "Shawn" Wang Gerling Haptics Lab University of Virginia yw5aj(a)virginia.edu +1 (434) 284-0836 https://sites.google.com/a/virginia.edu/yw5aj/

18 68

Re: [Numpy-discussion] Behavior of np.random.uniform
by Peter Creasey Jan. 21, 2016

Jan. 21, 2016

>> I would also point out that requiring open vs closed intervals (in >> doubles) is already an extremely specialised use case. In terms of >> *sampling the reals*, there is no difference between the intervals >> (a,b) and [a,b], because the endpoints have measure 0, and even with >> double-precision arithmetic, you are going to have to make several >> petabytes of random data before you hit an endpoint... >> > Petabytes ain't what they used to be ;) I remember testing some hardware > which, due to grounding/timing issues would occasionally goof up a readable > register. The hardware designers never saw it because they didn't test for > hours and days at high data rates. But it was there, and it would show up > in the data. Measure zero is about as real as real numbers... > > Chuck Actually, your point is well taken and I am quite mistaken. If you pick some values like uniform(low, low * (1+2**-52)) then you can hit your endpoints pretty easily. I am out of practice making pathological tests for double precision arithmetic. I guess my suggestion would be to add the deprecation warning and change the docstring to warn that the interval is not guaranteed to be right-open. Peter

3 2

Behavior of Printoptions with scalar types
by Sam Radhakrishan Jan. 21, 2016

Jan. 21, 2016

Hi all, This is related to #6908 <https://github.com/numpy/numpy/issues/6908>. While working on it I found that the printoptions are set only for array printing. The documentation however tells that printoptions can be set to pretty print single numpy values. I tried working on it and I am kinda stuck. I really don't know where else to post this. Regards, Sam Radhakrishnan

1 0

Re: [Numpy-discussion] Behavior of np.random.uniform
by Peter Creasey Jan. 20, 2016

Jan. 20, 2016

+1 for the deprecation warning for low>high, I think the cases where that is called are more likely to be unintentional rather than someone trying to use uniform(closed_end, open_end) and you might help users find bugs - i.e. the idioms of ‘explicit is better than implicit’ and ‘fail early and fail loudly’ apply. I would also point out that requiring open vs closed intervals (in doubles) is already an extremely specialised use case. In terms of *sampling the reals*, there is no difference between the intervals (a,b) and [a,b], because the endpoints have measure 0, and even with double-precision arithmetic, you are going to have to make several petabytes of random data before you hit an endpoint... Peter

2 1

1.11.0 release notes.
by Charles R Harris Jan. 20, 2016

Jan. 20, 2016

Hi All, I've put up a PR with revised 1.11.0 release notes at https://github.com/numpy/numpy/pull/7073. I would appreciate it if anyone involved in the 1.11 release would take a look and note anything missing that they think should be included or things that are misrepresented. Chuck

2 1

What does -0.0 means?
by Arnaldo Russo Jan. 20, 2016

Jan. 20, 2016

Hi all, After fitting a curve, the output returns the initial value as *-0.0*. Why not a simple 0.0? What is this difference? Sorry for the stupid question, but why exist a negative zero? Cheers, Arnaldo. --- Arnaldo D'Amaral Pereira Granja Russo Instituto Ambiental Boto Flipper institutobotoflipper .org

2 2

maintenance/1.11.x branched
by Charles R Harris Jan. 20, 2016

Jan. 20, 2016

Hi All, I've branched 1.11.x. There is still work to be done, but the branch draws the line for PRs to be included in 1.11. Experience teaches that fixups will needed, but new work/enhancements will be in 1.12.0-dev0. Please run tests on this branch if you have the time. Travis CI has begun failing for Python 3.2 due to a bug in pip. I don't know if this is on our account or something on the Travis end. Thoughts on that are welcome. Chuck

1 0

building with setuptools
by Ralf Gommers Jan. 18, 2016

Jan. 18, 2016

Hi all, We've been able to hold out for a long time, but this is to let you all know that we have now had to switch the numpy build to rely on setuptools: https://github.com/numpy/numpy/pull/6895. Main reason: plain distutils doesn't support PEP 440 naming. See https://github.com/numpy/numpy/issues/6257 and https://github.com/numpy/numpy/issues/6551 for details. So if you see different build weirdness on master, it's likely due to this change. Cheers, Ralf

1 0

Software Capabilities of NumPy in Our Tensor Survey Paper
by Li Jiajia Jan. 15, 2016

Jan. 15, 2016

Hi all, I’m a PhD student in Georgia Tech. Recently, we’re working on a survey paper about tensor algorithms: basic tensor operations, tensor decomposition and some tensor applications. We are making a table to compare the capabilities of different software and planning to include NumPy. We’d like to make sure these parameters are correct to make a fair compare. Although we have looked into the related documents, please help us to confirm these. Besides, if you think there are more features of your software and a more preferred citation, please let us know. We’ll consider to update them. We want to show NumPy supports tensors, and we also include "scikit-tensor” in our survey, which is based on NumPy. Please let me know any confusion or any advice! Thanks a lot! :-) Notice: 1. “YES/NO” to show whether or not the software supports the operation or has the feature. 2. “?” means we’re not sure of the feature, and please help us out. 3. “Tensor order” means the maximum number of tensor dimensions that users can do with this software. 4. For computational cores, 1) "Element-wise Tensor Operation (A * B)” includes element-wise add/minus/multiply/divide, also Kronecker, outer and Katri-Rao products. If the software contains one of them, we mark “YES”. 2) “TTM” means tensor-times-matrix multiplication. We distinguish TTM from tensor contraction. If the software includes tensor contraction, it can also support TTM. 3) For “MTTKRP”, we know most software can realize it through the above two operations. We mark it “YES”, only if an specified optimization for the whole operation. <> <>Software Name <> NumPy Computational Cores Element-wise Tensor Operation (A * B) YES Tensor Contraction (A Xmn B) NO TTM ( A Xn B) NO Matriced Tensor Times Khatri-Rao Product (MTTKRP) NO Tensor Decomposition CP NO Tucker NO Hierarchical Tucker (HT) NO Tensor Train (TT) NO Tensor Features Tensor Order Arbitrary Dense Tensors YES Sparse Tensors NO ? Parallelized NO ? Software Information Application Domain General Programming Environment Python Latest Version 1.10.4 Release Date 2016 Citation: 1. AN DER WALT, S., COLBERT, S., AND VAROQUAUX, G. The NumPy array: A structure for efficient numerical computation. Computing in Science Engineering 13, 2 (March 2011), 22–30. 2. OLIPHANT, T. E. Python for scientific computing. Computing in Science Engineering 9, 3 (May 2007), 10–20. 3. NumPy (Version1.10.4).Available from http://www.numpy.org, Jan <http://www.numpy.org, Jan> 2016. Best regards! Jiajia Li ------------------------------------------ E-mail: jiajiali(a)gatech.edu Tel: +1 (404)9404603 Computational Science & Engineering Georgia Institute of Technology

6 5

inconsistency in np.isclose
by Andrew Nelson Jan. 15, 2016

Jan. 15, 2016

Hi all, I think there is an inconsistency with np.isclose when I compare two numbers: >>> np.isclose(0, np.inf) array([False], dtype=bool) >>> np.isclose(0, 1) False The first comparison returns a bool array, the second returns a bool. Shouldn't they both return the same result? -- _____________________________________ Dr. Andrew Nelson _____________________________________

2 1

Fast Access to Container of Numpy Arrays on Disk?
by Ryan R. Rosario Jan. 14, 2016

Jan. 14, 2016

Hi, I have a very large dictionary that must be shared across processes and does not fit in RAM. I need access to this object to be fast. The key is an integer ID and the value is a list containing two elements, both of them numpy arrays (one has ints, the other has floats). The key is sequential, starts at 0, and there are no gaps, so the “outer” layer of this data structure could really just be a list with the key actually being the index. The lengths of each pair of arrays may differ across keys. For a visual: { key=0: [ numpy.array([1,8,15,…, 16000]), numpy.array([0.1,0.1,0.1,…,0.1]) ], key=1: [ numpy.array([5,6]), numpy.array([0.5,0.5]) ], … } I’ve tried: - manager proxy objects, but the object was so big that low-level code threw an exception due to format and monkey-patching wasn’t successful. - Redis, which was far too slow due to setting up connections and data conversion etc. - Numpy rec arrays + memory mapping, but there is a restriction that the numpy arrays in each “column” must be of fixed and same size. - I looked at PyTables, which may be a solution, but seems to have a very steep learning curve. - I haven’t tried SQLite3, but I am worried about the time it takes to query the DB for a sequential ID, and then translate byte arrays. Any ideas? I greatly appreciate any guidance you can provide. Thanks, Ryan

8 9

Get rid of special scalar arithmetic
by Charles R Harris Jan. 13, 2016

Jan. 13, 2016

Hi All, I've opened issue #7002 <https://github.com/numpy/numpy/issues/7002>, reproduced below, for discussion. > Numpy umath has a file scalarmath.c.src that implements scalar arithmetic > using special functions that are about 10x faster than the equivalent > ufuncs. > > In [1]: a = np.float64(1) > > In [2]: timeit a*a > 10000000 loops, best of 3: 69.5 ns per loop > > In [3]: timeit np.multiply(a, a) > 1000000 loops, best of 3: 722 ns per loop > > I contend that in large programs this improvement in execution time is not > worth the complexity and maintenance overhead; it is unlikely that > scalar-scalar arithmetic is a significant part of their execution time. > Therefore I propose to use ufuncs for all of the scalar-scalar arithmetic. > This would also bring the benefits of __numpy_ufunc__ to scalars with > minimal effort. > Thoughts? Chuck

5 4

1.11 branch this weekend
by Charles R Harris Jan. 12, 2016

Jan. 12, 2016

Hi All, Just a heads up. Note that we are trying to move to a faster release cycle and that changes the flavor of the releases. Instead of a list of goals to meet before each release, releases will more resemble snapshots of master at branch time. The main thing is that they be regression and bug free to the best of our ability when the branch is made. Chuck

1 0

Defining a base linux-64 environment [was: Should I use pip install numpy in linux?]
by Robert McGibbon Jan. 12, 2016

Jan. 12, 2016

Hi all, I went ahead and tried to collect a list of all of the libraries that could be considered to constitute the "base" system for linux-64. The strategy I used was to leverage off the work done by the folks at Continuum by searching through their pre-compiled binaries from https://repo.continuum.io/pkgs/free/linux-64/ to find shared libraries that were dependened on (according to ldd) that were not accounted for by the declared dependencies that each package made known to the conda package manager. The full list of these system libraries, sorted in from most-commonly-depend-on to rarest, is below. There are 158 of them. ['linux-vdso.so.1', 'libc.so.6', 'libpthread.so.0', 'libm.so.6', 'libdl.so.2', 'libutil.so.1', 'libgcc_s.so.1', 'libstdc++.so.6', 'libexpat.so.1', 'librt.so.1', 'libpng12.so.0', 'libcrypt.so.1', 'libffi.so.6', 'libresolv.so.2', 'libkeyutils.so.1', 'libcom_err.so.2', 'libp11-kit.so.0', 'libkrb5.so.26', 'libheimntlm.so.0', 'libtasn1.so.6', 'libheimbase.so.1', 'libgssapi.so.3', 'libroken.so.18', 'libhcrypto.so.4', 'libhogweed.so.4', 'libnettle.so.6', 'libhx509.so.5', 'libwind.so.0', 'libgnutls-deb0.so.28', 'libasn1.so.8', 'libgmp.so.10', 'libsasl2.so.2', 'libidn.so.11', 'librtmp.so.1', 'liblber-2.4.so.2', 'libldap_r-2.4.so.2', 'libXdmcp.so.6', 'libX11.so.6', 'libXau.so.6', 'libxcb.so.1', 'libgssapi_krb5.so.2', 'libkrb5.so.3', 'libk5crypto.so.3', 'libkrb5support.so.0', 'libicudata.so.55', 'libicuuc.so.55', 'libhdf5_serial.so.10', 'libcurl-gnutls.so.4', 'libhdf5_serial_hl.so.10', 'libtinfo.so.5', 'libgcrypt.so.20', 'libgpg-error.so.0', 'libnsl.so.1', 'libXext.so.6', 'libncursesw.so.5', 'libpanelw.so.5', 'libXrender.so.1', 'libjbig.so.0', 'libpcre.so.3', 'libglib-2.0.so.0', 'libnvidia-tls.so.352.41', 'libnvidia-glcore.so.352.41', 'libGL.so.1', 'libuuid.so.1', 'libSM.so.6', 'libICE.so.6', 'libgobject-2.0.so.0', 'libgfortran.so.1', 'liblzma.so.5', 'libXt.so.6', 'libgmodule-2.0.so.0', 'libXi.so.6', 'libgstpbutils-1.0.so.0', 'liborc-0.4.so.0', 'libgstreamer-1.0.so.0', 'libgsttag-1.0.so.0', 'libgstvideo-1.0.so.0', 'libxslt.so.1', 'libaudio.so.2', 'libjpeg.so.8', 'libgstaudio-1.0.so.0', 'libgstbase-1.0.so.0', 'libgstapp-1.0.so.0', 'libz.so.1', 'libgthread-2.0.so.0', 'libfreetype.so.6', 'libfontconfig.so.1', 'libdbus-1.so.3', 'libsystemd.so.0', 'libltdl.so.7', 'libGLU.so.1', 'libsqlite3.so.0', 'libpgm-5.1.so.0', 'libgomp.so.1', 'libxcb-render.so.0', 'libxcb-shm.so.0', 'libncurses.so.5', 'libxml2.so.2', 'libXss.so.1', 'libXft.so.2', 'libtk.so', 'libtcl.so', 'libasound.so.2', 'libharfbuzz.so.0', 'libpixman-1.so.0', 'libgio-2.0.so.0', 'libXinerama.so.1', 'libselinux.so.1', 'libXcomposite.so.1', 'libthai.so.0', 'libXdamage.so.1', 'libgdk-x11-2.0.so.0', 'libpangoft2-1.0.so.0', 'libcairo.so.2', 'libpangocairo-1.0.so.0', 'libdatrie.so.1', 'libatk-1.0.so.0', 'libXcursor.so.1', 'libXfixes.so.3', 'libgraphite2.so.3', 'libgdk_pixbuf-2.0.so.0', 'libgtk-x11-2.0.so.0', 'libquadmath.so.0', 'libpango-1.0.so.0', 'libXrandr.so.2', 'libgfortran.so.3', 'libjson-c.so.2', 'libshiboken-python2.7.so.1.1', 'libogg.so.0', 'libvorbis.so.0', 'libatlas.so.3', 'libcurl.so.4', 'libhdf5.so.9', 'libodbcinst.so.1', 'libpcap.so.0.9', 'libnetcdf.so.7', 'libblas.so.3', 'libpulse.so.0', 'libcaca.so.0', 'libgstreamer-0.10.so.0', 'libXxf86vm.so.1', 'libhdf5_hl.so.9', 'libpulse-simple.so.0', 'libasyncns.so.0', 'libwrap.so.0', 'libvorbisenc.so.2', 'libmagic.so.1', 'libssl.so.1.0.0', 'libFLAC.so.8', 'libSDL-1.2.so.0', 'libsndfile.so.1', 'libslang.so.2', 'libglapi.so.0', 'libaio.so.1', 'libgstinterfaces-0.10.so.0', 'libpulsecommon-6.0.so', 'libjpeg.so.62', 'libcrypto.so.1.0.0'] This list actually contains a fair number of false positives, so it would need to be pruned manually. If you stare at it a little while, you might see some libraries in there that you recognize that shouldn't be part of the base system, like libatlas.so.3. This gist https://gist.github.com/rmcgibbo/a13e7623c38ec54fcc93 contains some more detailed data -- for each of libraries in the list above, it gives a list of names of the packages that depend on this library. For example, for libatlas.so.3, the there is only a single package which depends on it, ["scikit-learn-0.11-np16py27_ce0"]. So, probably a bug. "libgfortran.so.1" is also in the list. It's depended on by ["cvxopt-1.1.6-py27_0", "cvxopt-1.1.7-py27_0", "cvxopt-1.1.7-py34_0", "cvxopt-1.1.7-py35_0", "numpy-1.5.1-py27_1", "numpy-1.5.1-py27_3", "numpy-1.5.1-py27_4", "numpy-1.5.1-py27_ce0", "numpy-1.6.2-py27_1", "numpy-1.6.2-py27_3", "numpy-1.6.2-py27_4", "numpy-1.6.2-py27_ce0", "numpy-1.7.0-py27_0", "numpy-1.7.0b2-py27_ce0", "numpy-1.7.0rc1-py27_0", "numpy-1.7.1-py27_0", "numpy-1.7.1-py27_2", "numpy-1.8.0-py27_0", "numpy-1.8.1-py27_0", "numpy-1.8.1-py34_0", "numpy-1.8.2-py27_0", "numpy-1.8.2-py34_0", "numpy-1.9.0-py27_0", "numpy-1.9.0-py34_0", "numpy-1.9.1-py27_0", "numpy-1.9.1-py34_0", "numpy-1.9.2-py27_0", "numpy-1.9.2-py34_0"]. Note that this list of numpy versions doesn't include the latest ones -- all of the numpy-1.10 binaries made by Continuum pick up libgfortan from a conda package and don't depend on it being provided by the system. Also, the final '_0' or '_1' segment of many of these package names is the build number, which is to make a new release of the same release of a package, usually because of a packaging problem. So many of these packages were probably built incorrectly and superseded by new builds with a higher build number. So it's not perfect. But it might be a useful starting place. -Robert

4 8

Re: [Numpy-discussion] Windows build/distribute plan & MingwPy funding
by Erik Bray Jan. 9, 2016

Jan. 9, 2016

On Sat, Jan 2, 2016 at 3:20 AM, Ralf Gommers <ralf.gommers(a)gmail.com> wrote: > Hi all, > > You probably know that building Numpy, Scipy and the rest of the Scipy Stack > on Windows is problematic. And that there are plans to adopt the static > MinGW-w64 based toolchain that Carl Kleffner has done a lot of work on for > the last two years to fix that situation. > > The good news is: this has become a lot more concrete just now, with this > proposal for funding: http://mingwpy.github.io/proposal_december2015.html > > Funding for phases 1 and 2 is already confirmed; the phase 3 part has been > submitted to the PSF. Phase 1 (of $1000) is funded by donations made to > Numpy and Scipy (through NumFOCUS), and phase 2 (of $4000) by NumFOCUS > directly. So a big thank you to everyone who made a donation to Numpy, Scipy > and NumFOCUS! > > I hope that that proposal gives a clear idea of the work that's going to be > done over the next months. Note that the http://mingwpy.github.io contains a > lot more background info, description of technical issues, etc. > > Feedback & ideas very welcome of course! > > Cheers, > Ralf Hi Ralph, I've seen you drop hints about this recently, and am interested to follow this work. I've been hired as part of the OpenDreamKit project to work, in large part, on developing a sensible toolchain for building and distributing Sage on Windows. I know you've been following the thread on that too. Although the primary goal there is "whatever works", I'm personally inclined to focus on the mingwpy / mingw-w64 approach, due in large part with my past success with the MinGW 32-bit toolchain. (I personally have a desire to improve support for building with MSVC as well, but that's a less important goal as far as the funding is concerned.) So anyways, please keep me in the loop about this, as I will also be putting effort into this over the next year as well. Has there been any discussion about setting up a mailing list specifically for this project? Thanks, Erik

3 2

Generalize hstack/vstack --> stack; Block matrices like in matlab
by Stefan Otte Jan. 9, 2016

Jan. 9, 2016

Hey, quite often I work with block matrices. Matlab offers the convenient notation [ a b; c d ] to stack matrices. The numpy equivalent is kinda clumsy: vstack([hstack([a,b]), hstack([c,d])]) I wrote the little function `stack` that does exactly that: stack([[a, b], [c, d]]) In my case `stack` replaced `hstack` and `vstack` almost completely. If you're interested in including it in numpy I created a pull request [1]. I'm looking forward to getting some feedback! Best, Stefan [1] https://github.com/numpy/numpy/pull/5057

12 24

Re: [Numpy-discussion] ENH: Add the function 'expand_view'
by John Kirkham Jan. 9, 2016

Jan. 9, 2016

First, off sorry for the long turnaround on responding to these questions. Below I have tried to respond to everyone's questions and comments. I have restructured the order of the messages so that my responses are a little more structured. If anybody has more thoughts or questions, please let me know. >>>> Takes an array and tacks on arbitrary dimensions on either side, which >>> is returned as a view always. Here are the relevant features: >>>> >>>> * Creates a view of the array that has the dimensions before and after >>> tacked on to it. >>>> * Takes the before and after arguments independent of each other and >>> the current shape. >>>> * Allows for read and write access to the underlying array. >>> >>> Can you expand this with some discussion of why you want this function, >>> and why you chose these specific features? (E.g. as mentioned in the PR >>> comments already, the reason broadcast_to returns a read-only array is that >>> it was decided that this was less confusing for users, not because of any >>> technical issue.) Sometimes I find that broadcasting is insufficient or gets confused with some more complex cases. Even adding the extra dimensions using `np.newaxis`/`None` doesn't always cut it. So, being able to add the dimensions with the right shape and without copying is very nice. However, I wanted to do this in a way where this would always be a view onto the original data to avoid any copying penalty. It also came in handy when I didn't know how many dimensions I would be dealing with. The alternative would be to do something doing things like `a[..., (b.ndim-1)*(None,)]` and possibly something similar with `b`, which end up being pretty gross and unreadable as opposed to doing `expand_view(a, reps_after=b.shape[1:])`, which is quite clear. The latter also conveys to reader what those dimensions are doing. Finally in cases where `None` or `np.newaxis` work fine, it is possible for you to combine them in some operation you are doing in way which you did not intend. If broadcasting would have worked in this case, you won't get an error, but you will get the wrong answer, which you may discover later than you would like. When using `expand_view` an explicit shape can be set, which when mismatched will give you an error allowing you discover the problem as soon as you run the code as opposed after when you are trying to figure out your answer is wrong. The write option I never actually use so making it readonly is fine. I just never blocked that behavior. Perhaps it would be preferable as has been suggested. Ensuring a view is nice because this remains performant for large arrays. Using a view seems reasonable here based on the fact that we are never trying to restructure the data here. Instead, we are trying to make it appear as if its shape were different. > How is this different from using np.newaxis and broadcasting? Or am I > misunderstanding this? I hope the description above also helps clarify this a bit. To be more succinct and explicit: * This can always be used even when broadcasting may get confused. * Works cleanly and easily with variable numbers of dimensions unlike `np.newaxis`/`None`. * Using explicit shapes more tightly constrains behavior with the resulting view (helping catch bugs). * Provides the reader more information about how the other dimensions should work. >> Why is this a stride_trick? >> >> I thought this looks similar to expand_dims and could maybe be implemented >> with some extra options there. So, `expand_dims` adds a single dimension with a length of 1 where specified, but not multiple. Though I am going to infer by extra options you mean change it some way that it can add multiple axes. Though I suppose you could do this and it may even be worth pursing, it ends up being a similar idea to using `np.newaxis`/`None` a few times and so I have basically the same points to make here as I made in the last section's response. Also, I feel like using `expand_dims` with more axes specified might make it a little harder to follow than just using `np.newaxis`/`None`, but it could have its merrits. >From a performance standpoint, `expand_dims` using `reshape` to add these extra dimensions. So, it has the possibility of not returning a view, but a copy, which could take some time to build if the array is large. By using our method, we guarantee a view will always be returned; so, this allocation will never be encountered.

2 1

ANN: second release candidate for scipy 0.17.0
by Evgeni Burovski Jan. 8, 2016

Jan. 8, 2016

Hi, I'm pleased to announce the availability of the second release candidate for Scipy 0.17.0. It's two days ahead of the original schedule: based on typical development patterns, I'd like to have two weekends and a full working week before January 17th, when this rc2 is supposed to become the final release. Please try this rc and report any issues on Github tracker or scipy-dev mailing list. Source tarballs and full release notes are available from Github Releases: https://github.com/scipy/scipy/releases/tag/v0.17.0rc2 Compared to rc1, the following PRs were merged: - - `#5624 <https://github.com/scipy/scipy/pull/5624>`__: FIX: Fix interpolate - - `#5625 <https://github.com/scipy/scipy/pull/5625>`__: BUG: msvc9 binaries crash when indexing std::vector of size 0 - - `#5635 <https://github.com/scipy/scipy/pull/5635>`__: BUG: misspelled __dealloc__ in cKDTree. - - `#5642 <https://github.com/scipy/scipy/pull/5642>`__: STY: minor fixup of formatting of 0.17.0 release notes. - - `#5643 <https://github.com/scipy/scipy/pull/5643>`__: BLD: fix a build issue in special/Faddeeva.cc with isnan. - - `#5661 <https://github.com/scipy/scipy/pull/5661>`__: TST: linalg tests used stdlib random instead of numpy.random. There is a bit of an unusual change in this rc. In short, in testing rc1 we found that 1) interpolate.interp1d had an undocumented feature of allowing an array-valued fill_value to be broadcast against the data being interpolated, and 2) we broke it in 0.17.0rc1. (See PR 5624 for details.) We now *think* we fixed it so that no existing code is broken. Nevertheless, I would like to encourage everyone to test their code against this rc2, especially all code which uses interp1d. Cheers, Evgeni

2 1

Numpy 1.10.4 release.
by Charles R Harris Jan. 7, 2016

Jan. 7, 2016

Hi All, I'm pleased the release of the Numpy 1.10.4 (bugs stomped) release. This release was motivated by a reported segfault, but a few additional fixes were made: * gh-6922 BUG: numpy.recarray.sort segfaults on Windows, * gh-6937 BUG: busday_offset does the wrong thing with modifiedpreceding roll, * gh-6949 BUG: Type is lost when slicing a subclass of recarray, together with one minor enhancement * gh-6950 BUG trace is not subclass aware, np.trace(ma) != ma.trace(). The sources and documentation are available on Sourceforge, but no binaries. The usual windows binaries were ommitted due to problems with the toolchain. We hope that will be remedied in the future. Mac binaries can be installed from pypi. "Where is numpy 1.10.3?", you may ask. There were glitches with the uploads to pypi for that version that necessitated a version upgrade. A release manager's life is not a happy one. Many thanks to Marten van Kerkwijk, Sebastian Seberg, and Mark Wiebe for the quick bug fixes. Chuck

2 2

Building master issues on Windows
by G Young Jan. 7, 2016

Jan. 7, 2016

Hello all, I've recently encountered issues building numpy off master on Windows in which setup.py complains that it can't find the Advapi library in any directories (which is an empty list). I scanned the DLL under System32 and ran /sfc scannow as Administrator, and both came up clean. Is anyone else encountering (or can reproduce) this issue, or is it just me? Any suggestions about how to resolve this problem? Thanks! Greg

2 3

Subclass awareness of outer, inner, dot, ...
by Marten van Kerkwijk Jan. 6, 2016

Jan. 6, 2016

Hi All, Having just had a look at functions where astropy's quantities are silently converted to ndarray, I came across some that, in principle, are easy to solve, yet for which, as always, there is a worry about backward compatibility. So, the question arises what to do. As a specific example, consider `np.outer` which is defined in `numeric.py` and boils down to multiply(a.ravel()[:, newaxis], b.ravel()[newaxis,:], out) Since multiply is fine with subclasses, all should be well, except that before it is called, there are `a = asarray(a)` and `b = asarray(b)` statements, which mean subclasses are lost. Obviously, in this case, a simple fix would be to use `asanyarray` instead, but ideally, similar routines behave similarly and hence one would also want to change `np.inner` and `np.dot` (and perhaps more)... Hence, before doing anything, I thought I would ask whether: 1. Such changes are or are not too risky for backward compatibility; 2. If so, whether, given that `np.dot` can be caught using `__numpy_ufunc__`, one should perhaps allow functions such as `outer` also to be passed through that? All the best, Marten

1 0

Numpy 1.10.3 release.
by Charles R Harris Jan. 6, 2016

Jan. 6, 2016

Hi All, A significant segfault problem has been reported against Numpy 1.10.2 and I want to make a quick 1.10.3 release to get it fixed. Two questions - What exactly is the release process that has been decided on? AFAIK, I should just do a source release on Sourceforge, ping Matthew to produce wheels for Mac and wait for him to put them on pypi, and then upload the sources to pypi. No windows binaries are to be produced. - Is there anything else that needs fixing for 1.10.3? Chuck

4 8

1.10.3 release tomorrow, 1.11.x branch this month.
by Charles R Harris Jan. 6, 2016

Jan. 6, 2016

Hi All, I'm going to attempt a 1.10.3 release tomorrow to address the segfault reported in #6922 <https://github.com/numpy/numpy/issues/6922>. I'd also like to branch 1.11.x sometime this month, hopefully around Jan 18 (two weeks from now). There are some unresolved issues, in particular __numpy_ufunc__, but there is plenty of accumulated material and I'd like to get something out before the tinder buildup constitutes a fire hazard. Releases generate plenty of sparks and it would be good if the 1.11.0 release was less flamable than the 1.10 release was. I will take a look through the current bug fix PRs with intent to merge as many as possible before the branch, but enhancements will not be a high priority except for a couple that have been sitting ready in the queue for awhile. If there are some enhancements that you think need to be in the release, mention them here. Chuck

4 4

Re: [Numpy-discussion] deprecate random.random_integers
by G Young Jan. 4, 2016

Jan. 4, 2016

Hello all, In light of the discussion in #6910 <https://github.com/numpy/numpy/pull/6910>, I have gone ahead and deprecated random_integers in my most recent PR here <https://github.com/numpy/numpy/pull/6910>. As this is an API change (sort of), what are people's thoughts on this deprecation? Thanks! Greg

2 1

Re: [Numpy-discussion] dtype random.rand
by G Young Jan. 3, 2016

Jan. 3, 2016

Hello, Issue #6790 <https://github.com/numpy/numpy/issues/6790> had requested the enhancement of adding the dtype argument to both random.randint and random.rand. With #6910 <https://github.com/numpy/numpy/pull/6910> merged in, that addresses the first half of the request. What do people think of adding a dtype argument to random.rand? Thanks! Greg

1 0

Proposal for a new function: np.moveaxis
by Stephan Hoyer Jan. 2, 2016

Jan. 2, 2016

I've put up a pull request implementing a new function, np.moveaxis, as an alternative to np.transpose and np.rollaxis: https://github.com/numpy/numpy/pull/6630 This functionality has been discussed (even the exact function name) several times over the years, but it never made it into a pull request. The most pressing issue is that the behavior of np.rollaxis is not intuitive to most users: https://mail.scipy.org/pipermail/numpy-discussion/2010-September/052882.html https://github.com/numpy/numpy/issues/2039 http://stackoverflow.com/questions/29891583/reason-why-numpy-rollaxis-is-so… In this pull request, I also allow the source and destination axes to be sequences as well as scalars. This does not add much complexity to the code, solves some additional use cases and makes np.moveaxis a proper generalization of the other axes manipulation routines (see the pull requests for details). Best of all, it already works on ndarray duck types (like masked array and dask.array), because they have already implemented transpose. I think np.moveaxis would be a useful addition to NumPy -- I've found myself writing helper functions with a subset of its functionality several times over the past few years. What do you think? Cheers, Stephan

4 3

Numpy funding update
by Ralf Gommers Jan. 2, 2016

Jan. 2, 2016

Hi all, A quick good news message: OSDC has made a $5k contribution to NumFOCUS, which is split between support for a women in technology workshop and support for Numpy: http://www.numfocus.org/blog/osdc-donates-5k-to-support-numpy-women-in-tech This was a very nice surprise to me, and a first sign that the FSA (fiscal sponsorship agreement) we recently signed with NumFOCUS is going to yield significant benefits for Numpy. NumFOCUS is also doing a special end-of-year fundraiser. Funds donated (up to $5k) will be tripled by anonymous sponsors: http://www.numfocus.org/blog/numfocus-end-of-year-fundraising-drive-5000-ma… So think of Numpy (or your other favorite NumFOCUS-sponsored project of course) if you're considering a holiday season charitable gift! Cheers, Ralf

2 2

Windows build/distribute plan & MingwPy funding
by Ralf Gommers Jan. 2, 2016

Jan. 2, 2016

Hi all, You probably know that building Numpy, Scipy and the rest of the Scipy Stack on Windows is problematic. And that there are plans to adopt the static MinGW-w64 based toolchain that Carl Kleffner has done a lot of work on for the last two years to fix that situation. The good news is: this has become a lot more concrete just now, with this proposal for funding: http://mingwpy.github.io/proposal_december2015.html Funding for phases 1 and 2 is already confirmed; the phase 3 part has been submitted to the PSF. Phase 1 (of $1000) is funded by donations made to Numpy and Scipy (through NumFOCUS), and phase 2 (of $4000) by NumFOCUS directly. So a big thank you to everyone who made a donation to Numpy, Scipy and NumFOCUS! I hope that that proposal gives a clear idea of the work that's going to be done over the next months. Note that the http://mingwpy.github.io contains a lot more background info, description of technical issues, etc. Feedback & ideas very welcome of course! Cheers, Ralf

1 0

Unable to install a copy of Numpy, retrieved from the Git Repository.
by Colin W. Jan. 2, 2016

Jan. 2, 2016

2 1

what would you expect A[none] to do?
by Neal Becker Jan. 1, 2016

Jan. 1, 2016

In my case, what it does is: A.shape = (5760,) A[none] -> (1, 5760) In my case, use of none here is just a mistake. But why would you want this to be accepted at all, and how should it be interpreted?

5 5