Mailman 3 December 2017 - NumPy-Discussion

mixed mode arithmetic
by Neal Becker 11 Jul '23

11 Jul '23

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 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

building numpy with python3.7
by Hannes Breytenbach 18 Jan '18

18 Jan '18

Hi devs! This is my first post to the discussion list! Has anyone tried to build numpy with python3.7.0a3? I get the following gcc errors during compile: . . . compiling C sources C compiler: gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -Inumpy/core/include -Ibuild/src.linux-x86_64-3.7/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -I/usr/local/include/python3.7m -Ibuild/src.linux-x86_64-3.7/numpy/core/src/private -Ibuild/src.linux-x86_64-3.7/numpy/core/src/npymath -Ibuild/src.linux-x86_64-3.7/numpy/core/src/private -Ibuild/src.linux-x86_64-3.7/numpy/core/src/npymath -Ibuild/src.linux-x86_64-3.7/numpy/core/src/private -Ibuild/src.linux-x86_64-3.7/numpy/core/src/npymath -c' gcc: numpy/random/mtrand/mtrand.c numpy/random/mtrand/mtrand.c: In function ‘__Pyx__ExceptionSave’: numpy/random/mtrand/mtrand.c:40970:19: error: ‘PyThreadState {aka struct _ts}’ has no member named ‘exc_type’; did you mean ‘curexc_type’? *type = tstate->exc_type; ^~ . . . error: Command "gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -Inumpy/core/include -Ibuild/src.linux-x86_64-3.7/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -I/usr/local/include/python3.7m -Ibuild/src.linux-x86_64-3.7/numpy/core/src/private -Ibuild/src.linux-x86_64-3.7/numpy/core/src/npymath -Ibuild/src.linux-x86_64-3.7/numpy/core/src/private -Ibuild/src.linux-x86_64-3.7/numpy/core/src/npymath -Ibuild/src.linux-x86_64-3.7/numpy/core/src/private -Ibuild/src.linux-x86_64-3.7/numpy/core/src/npymath -c numpy/random/mtrand/mtrand.c -o build/temp.linux-x86_64-3.7/numpy/random/mtrand/mtrand.o -MMD -MF build/temp.linux-x86_64-3.7/numpy/random/mtrand/mtrand.o.d" failed with exit status 1 Version info: ------------- gcc --version: gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 2017040 numpy version: 1.15.0.dev0+d233e1f The same error comes up when building via pip. I don't know enough about the underlying C code to know how to debug this. Any help would be greatly appreciated! Cheers, -- Hannes Breytenbach PhD Candidate South African Astronomical Observatory +27 82 726 9311

5 10

array - dimension size of 1-D and 2-D examples
by Vinodhini Balusamy 08 Jan '18

08 Jan '18

Hi, I am new to bumpy and started working on basics. I need clarification for the below behaviour. case 1: >>> x12 = np.array([[1,2,3]]) >>> print(x12) [[1 2 3]] >>> x12.ndim 2 >>> Tried creating a 2-D array. also, >>> x12 = np.array([[1,2,3],[0,0,0]]) >>> print(x12) [[1 2 3] [0 0 0]] >>> x12.ndim 2 >>> Case 2: >>> >>> x12 = np.array([[1,2,3],[]]) >>> x12.ndim 1 >>> print(x12) [list([1, 2, 3]) list([])] >>> In case 2, I am trying to understand why it becomes 1 dimentional ?!?! Case 3: >>> >>> x12 = np.array([1,2,3]) >>> x12.ndim 1 >>> print(x12) [1 2 3] >>> This seems reasonable to me to be considered as 1 dimensional. Would like to understand case 2 a bit more to get to know if i am missing something. Will be much appreciated if someone to explain me a bit. Thanks in advance. Regards, Vinodhini B

2 4

NEP process PR
by Jarrod Millman 04 Jan '18

04 Jan '18

Hi all, I've started working on the proposal discussed in this thread: https://mail.python.org/pipermail/numpy-discussion/2017-December/077481.html here: https://github.com/numpy/numpy/pull/10213 You can see how I modified PEP 1 here: https://github.com/numpy/numpy/pull/10213/commits/eaf788940dee7d0f1c7922fac… I used numbers (i.e., ``nep-0000.rst``) in the file names, since it seems more standard and numbers are easier to refer to in discussions. I don't have a strong preference, so I am happy to change it. If using numbers seems reasonable, I will number the existing NEPs. Moreover, if the preamble seems reasonable, I will go through the existing NEPs and make sure they all have compliant headers. For now, I think auto-generating the index is unnecessary. Once we are happy with the purpose and template NEPs as well as automatically publish to GH pages, we can always go back and write a little script to autogenerate the index using the preamble information. Finally, I started preparing to host the NEPs online at: http://numpy.github.io/neps If that seems reasonable, I will need someone to create a neps repo. We also need to decide whether to move ``numpy/doc/neps`` to the master branch of the new neps repo or whether to leave it where it is. I don't have a strong opinion either way. However, if no one else minds leaving it where it is, not moving it is slightly less work. Either way, the work is trivial. Regardless of where the source resides, we can host the generated web page in the same location (i.e., http://numpy.github.io/neps). It is probably also worth having https://docs.scipy.org/doc/numpy/neps/ redirect to http://numpy.github.io/neps Best regards, Jarrod

3 2

ANN: SfePy 2017.4
by Robert Cimrman 29 Dec '17

29 Dec '17

I am pleased to announce release 2017.4 of SfePy. Description ----------- SfePy (simple finite elements in Python) is a software for solving systems of coupled partial differential equations by the finite element method or by the isogeometric analysis (limited support). It is distributed under the new BSD license. Home page: http://sfepy.org Mailing list: https://mail.python.org/mm3/mailman3/lists/sfepy.python.org/ Git (source) repository, issue tracker: https://github.com/sfepy/sfepy Highlights of this release -------------------------- - basic support for penalty-based contacts - support for user-defined contexts in all solvers and preconditioners - new example: dispersion analysis of heterogeneous periodic materials For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1 (rather long and technical). Cheers, Robert Cimrman --- Contributors to this release in alphabetical order: Robert Cimrman Jan Heczko Lubos Kejzlar Jan Kopacka Vladimir Lukes Matyas Novak

1 0

GSoC'18 participation
by Ralf Gommers 27 Dec '17

27 Dec '17

Hi all, It's the time of the year again where projects start preparing for GSoC. So I wanted to bring it up here. Last year I wrote: "in practice working on NumPy is just far too hard for most GSoC students. Previous years we've registered and generated ideas, but not gotten any students. We're also short on maintainer capacity. So I propose to not participate this year." I think that's still the case, so I won't be mentoring or organizing. In case anyone is interested to do one of those things, please speak up! Cheers, Ralf

3 2

Directives in numpy docstring convention
by Marc Garcia 26 Dec '17

26 Dec '17

Hi there, Is there a reason why the numpy docstring convention doesn't use the sphinx directives .. deprecated:: [1] and .. seealso:: [2]? I see that the numpy convention [3] uses the .. note:: directive for the deprecation notes, and for the "See also" it uses a section in this form: See also ------------- I guess those directives were added to the sphinx after the numpy docstring convention was created. And in this case, while is probably not worth to update numpy docstrings, I think they should be used for new projects that want to follow the numpy convention. Is that the case, or is there a reason why new projects shouldn't use them? Thanks! 1. http://www.sphinx-doc.org/en/stable/markup/para.html#directive-deprecated 2. http://www.sphinx-doc.org/en/stable/markup/para.html#directive-seealso 3. https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt

3 2

Another grant update, & numpy job ad is up!
by Nathaniel Smith 22 Dec '17

22 Dec '17

Hi all, Two exciting bits of news: 1) We just posted the announcement of a second grant to BIDS for NumPy, this time from the Sloan Foundation: https://bids.berkeley.edu/news/bids-receives-sloan-foundation-grant-contrib… This is for $659,359 over two years, very similar to the previously-announced Moore Foundation grant. These two grants were originally written together as one, then split in half between the two foundations, then the schedules drifted apart... I'm excited to finally have this all sorted out so we can move ahead with the original plan! 2) We have successfully navigated UC Berkeley's administrative systems and posted an actual job opening, which you can apply to *right now*: https://jobsprod.is.berkeley.edu/psp/jobsprod/EMPLOYEE/HRMS/c/HRS_HRAM.HRS_… We're hoping to hire 2-3 people under that job description, so please tell your friends, relatives, enemies, whoever. This is a fully open search and we want our candidate pool to be as large and diverse (in all senses) as possible, so if you're on the fence about applying, why not give it a shot? Or if you want to know more, feel free to send any questions to me (njs(a)berkeley.edu) and/or Stéfan van der Walt (stefanv(a)berkeley.edu) -- we'd love to chat. We'll also do another round of publicity/reminders in the new year after everyone's had a chance to recover from the holidays, but wanted to at least get this out now so those who are interested can start putting their application together... -n -- Nathaniel J. Smith -- https://vorpus.org

2 2