Mailman 3 January 2016 - NumPy-Discussion

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 … [View More]

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 … [View More]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). [View Less]

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 … [View More]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 [View Less]

3 9

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

Jan. 25, 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 … [View More]

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 … [View More]

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, … [View More]

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) … [View More]

3 4

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

Jan. 21, 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 … [View More]

2 6