Mailman 3 November 2016 - NumPy-Discussion

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

18 Feb '23

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 22 Jul '21

22 Jul '21

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

automatically avoiding temporary arrays
by Julian Taylor 28 Feb '17

28 Feb '17

hi, Temporary arrays generated in expressions are expensive as the imply extra memory bandwidth which is the bottleneck in most numpy operations. For example: r = a + b + c creates the b + c temporary and then adds a to it. This can be rewritten to be more efficient using inplace operations: r = b + c r += a This saves some memory bandwidth and can speedup the operation by 50% for very large arrays or even more if the inplace operation allows it to be completed completely in the cpu cache. The problem is that inplace operations are a lot less readable so they are often only used in well optimized code. But due to pythons refcounting semantics we can actually do some inplace conversions transparently. If an operand in python has a reference count of one it must be a temporary so we can use it as the destination array. CPython itself does this optimization for string concatenations. In numpy we have the issue that we can be called from the C-API directly where the reference count may be one for other reasons. To solve this we can check the backtrace until the python frame evaluation function. If there are only numpy and python functions in between that and our entry point we should be able to elide the temporary. This PR implements this: https://github.com/numpy/numpy/pull/7997 It currently only supports Linux with glibc (which has reliable backtraces via unwinding) and maybe MacOS depending on how good their backtrace is. On windows the backtrace APIs are different and I don't know them but in theory it could also be done there. A problem is that checking the backtrace is quite expensive, so should only be enabled when the involved arrays are large enough for it to be worthwhile. In my testing this seems to be around 180-300KiB sized arrays, basically where they start spilling out of the CPU L2 cache. I made a little crappy benchmark script to test this cutoff in this branch: https://github.com/juliantaylor/numpy/tree/elide-bench If you are interested you can run it with: python setup.py build_ext -j 4 --inplace ipython --profile=null check.ipy At the end it will plot the ratio between elided and non-elided runtime. It should get larger than one around 180KiB on most cpus. If no one points out some flaw in the approach, I'm hoping to get this into the next numpy version. cheers, Julian

11 22

__numpy_ufunc__
by Charles R Harris 23 Feb '17

23 Feb '17

Hi All, For those interested in continuing the __numpy_ufunc__ saga, there is a pull request enabling it <https://github.com/numpy/numpy/pull/8247>. Likely we will want to make some changes up front before merging that, so some discussion is in order. Chuck

5 8

Re: [Numpy-discussion] Integers to negative integer powers, time for a decision.
by Peter Creasey 04 Jan '17

04 Jan '17

> On Sun, Oct 9, 2016 at 12:59 PM, Stephan Hoyer <shoyer(a)gmail.com> wrote: > >> >> I agree with Sebastian and Nathaniel. I don't think we can deviating from >> the existing behavior (int ** int -> int) without breaking lots of existing >> code, and if we did, yes, we would need a new integer power function. >> >> I think it's better to preserve the existing behavior when it gives >> sensible results, and error when it doesn't. Adding another function >> float_power for the case that is currently broken seems like the right way >> to go. >> > I actually suspect that the amount of code broken by int**int->float may be relatively small (though extremely annoying for those that it happens to, and it would definitely be good to have statistics). I mean, Numpy silently transitioned to int32+uint64->float64 not so long ago which broke my code, but the world didn’t end. If the primary argument against int**int->float seems to be the difficulty of managing the transition, with int**int->Error being the seen as the required yet *very* painful intermediate step for the large fraction of the int**int users who didn’t care if it was int or float (e.g. the output is likely to be cast to float in the next step anyway), and fail loudly for those users who need int**int->int, then if you are prepared to risk a less conservative transition (i.e. we think that latter group is small enough) you could skip the error on users and just throw a warning for a couple of releases, along the lines of: WARNING int**int -> int is going to be deprecated in favour of int**int->float in Numpy 1.16. To avoid seeing this message, either use “from numpy import __future_float_power__” or explicitly set the type of one of your inputs to float, or use the new ipower(x,y) function for integer powers. Peter

5 7

Does numpy.bincount support numpy.float128 type weights?
by Wei, Huayi 01 Dec '16

01 Dec '16

Hi, There, Here is a sample code using `numpy.bincount` import numpy as np a = np.array([1.0, 2.0, 3.0], dtype=np.float128) b = np.array([1, 2, 0], dtype=np.int) c = np.bincount(b, weights=a) If run it, I get the following error report: ----> 1 c = np.bincount(b, weights=a) TypeError: Cannot cast array data from dtype('float128') to dtype('float64') according to the rule 'safe' Is it a bug of `np.bincount`? Does there exist any similar function which I can use to do the similar thing with numpy.float128 type weights? Best Huayi

4 3

Re: [Numpy-discussion] Wheel files for PPC64
by Leonardo Bianconi 29 Nov '16

29 Nov '16

Hi. Can anyone help me with this? > > From: Leonardo Bianconi > Sent: quarta-feira, 23 de novembro de 2016 12:47 > To: 'numpy-discussion(a)scipy.org' <numpy-discussion(a)scipy.org> > Subject: Wheel files for PPC64 > > Hi all! > > I realized that there is no "whl" files for PPC64 (https://pypi.python.org/pypi/numpy/1.12.0b1), > which makes numpy be compiled when installing it with pip. It is causing a low performance on > this architecture when the libopenblas is not previously installed, while for x86_64 it is installed > as a lib, which is in the "whl" file. > > What must to be done to add a build of numpy for PPC64, and upload the "whl" files to pypi > link?

2 1

Wheel files for PPC64
by Leonardo Bianconi 24 Nov '16

24 Nov '16

Hi all! I realized that there is no "whl" files for PPC64 (https://pypi.python.org/pypi/numpy/1.12.0b1), which makes numpy be compiled when installing it with pip. It is causing a low performance on this architecture when the libopenblas is not previously installed, while for x86_64 it is installed as a lib, which is in the "whl" file. What must to be done to add a build of numpy for PPC64, and upload the "whl" files to pypi link?

2 1

PyPy wheels (was: NumPy 1.12.0b1 released)
by Ralf Gommers 19 Nov '16

19 Nov '16

On Sat, Nov 19, 2016 at 5:24 AM, Nathaniel Smith <njs(a)pobox.com> wrote: > Another thing to think about is that 1.12 on pypy won't pass its test > suite (though it's close), and we're not yet testing new PRs on pypy, so no > guarantees about 1.13 yet. I think on balance these probably aren't reasons > *not* to upload wheels, but it's a funny place where we're talking about > providing "official" builds even though it's not an "officially supported > platform". So we will at least want to be clear about that. And someone > will have to handle the bug reports about the test suite failing :-). > Those are good points. We could run PyPy on TravisCI; the PyPy install and numpy build aren't difficult anymore. Handling bug reports is mostly checking if it's PyPy specific, and if so refer to the PyPy tracker I'd think. It is some work, but given that PyPy has finally chosen a way to support Numpy that's not a dead end and has come quite a long way quite quickly, taking on that bit of extra work as Numpy maintainers is a good time investment imho. Many bug reports will go straight to PyPy though I expect, because often that is the obvious place to go. This is what I just got from downloading the OS X PyPy binary and pip installing numpy master: Python version 2.7.12 (aff251e54385, Nov 09 2016, 17:25:49)[PyPy 5.6.0 with GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] nose version 1.3.7 .................................S.......................................................E........................................................................................S.............................................................RPython traceback: File "pypy_interpreter.c", line 43348, in BuiltinCodePassThroughArguments1_funcrun_obj File "pypy_module_cpyext_4.c", line 16627, in generic_cpy_call__StdObjSpaceConst_funcPtr_SomeI_17 Fatal RPython error: AssertionError Abort trap: 6 So guess I'll go find out where that issue tracker is:) Ralf On Nov 18, 2016 01:14, "Ralf Gommers" <ralf.gommers(a)gmail.com> wrote: > > > > > > > > On Fri, Nov 18, 2016 at 9:08 PM, Matthew Brett <matthew.brett(a)gmail.com> > wrote: > >> > >> Hi, > >> > >> On Thu, Nov 17, 2016 at 3:24 PM, Matti Picus <matti.picus(a)gmail.com> > wrote: > >> > Congrats to all on the release.Two questions: > >> > > >> > Is there a guide to building standard wheels for NumPy? > >> > >> I don't think so - there is a repository that we use to build the > >> wheels, that has the Windows, OSX and manyllinux recipes for the > >> standard CPython build: > >> > >> https://github.com/MacPython/numpy-wheelso > >> > >> If you can work out a way to automate the PyPy builds and tests - > >> especially using the same repo - that would be very useful. > >> > >> > Assuming I can build standardized PyPy 2.7 wheels for Ubuntu, Win32 > and > >> > OSX64, how can I get them blessed and uploaded to PyPI? > >> > >> If you can automate the build and tests, I'm guessing there will be no > >> objections - but it's not my call... > > > > > > I'm in favor, assuming that the wheel tags and PyPy backwards > compatibility situation is OK. Can't really find any examples. What I mean > is that for CPython wheels contain tags like "cp27" or "cp35". PyPy wheels > should have tags "pp<something>". Are the PyPy cpyext layer and the > <something> defined such that a new PyPy release won't break older wheels? > >

2 2

Re: [Numpy-discussion] NumPy 1.12.0b1 released
by Matti Picus 18 Nov '16

18 Nov '16

Congrats to all on the release.Two questions: Is there a guide to building standard wheels for NumPy? Assuming I can build standardized PyPy 2.7 wheels for Ubuntu, Win32 and OSX64, how can I get them blessed and uploaded to PyPI? Matti On 17/11/16 07:47, numpy-discussion-request(a)scipy.org wrote: > Date: Wed, 16 Nov 2016 22:47:39 -0700 > From: Charles R Harris<charlesr.harris(a)gmail.com> > To: numpy-discussion<numpy-discussion(a)scipy.org>, SciPy Users List > <scipy-user(a)scipy.org>, SciPy Developers List<scipy-dev(a)scipy.org>, > python-announce-list(a)python.org > Subject: [Numpy-discussion] NumPy 1.12.0b1 released. > > Hi All, > > I'm pleased to annouce the release of NumPy 1.12.0b1. This release > supports Python 2.7 and 3.4 - 3.6 and is the result of 388 pull requests > submitted by 133 contributors. It is quite sizeable and rather than put the > release notes inline I've attached them as a file and they may also be > viewed at Github<https://github.com/numpy/numpy/releases/tag/v1.12.0b1>. > Zip files and tarballs may also be found the Github link. Wheels and source > archives may be downloaded from PyPI, which is the recommended method. > > This release is a large collection of fixes, enhancements, and improvements > and it is difficult to select just a few as highlights. However, the > following enhancements may be of particular interest > > - Order of operations in ``np.einsum`` now can be optimized for large > speed improvements. > - New ``signature`` argument to ``np.vectorize`` for vectorizing with > core dimensions. > - The ``keepdims`` argument was added to many functions. > - Support for PyPy 2.7 v5.6.0 has been added. While not complete, this > is a milestone for PyPy's C-API compatibility layer. > > Thanks to all, > > Chuck

6 6

NumPy-Discussion November 2016