Mailman 3 June 2017 - 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

Scipy 2017 NumPy sprint
by Charles R Harris July 8, 2017

July 8, 2017

Hi All, I will be running the NumPy sprint at Scipy 2017 and I'm trying to put together a suitable list of things to sprint on. In my experience, sprinting on NumPy is hard, enhancements generally need lengthy review and even finding and doing simple bug fixes can take time. What I have in mind at this point, apart from what might be a getting started tutorial, could mostly be classified as janitorial work. 1. Triage issues and close those that no longer apply. This is mind numbing work, but it has been almost three years since the last pass. 2. Move the contents of `numpy/doc` into `doc/source` and make them normal *.rst files. 3. Convert the doctest in `numpy/lib/tests/test_polynomial.py` to regular tests. Might be tricky as it mostly checks print formatting.

17 31

proposed changes to array printing in 1.14
by Allan Haldane July 1, 2017

July 1, 2017

Hello all, There are various updates to array printing in preparation for numpy 1.14. See https://github.com/numpy/numpy/pull/9139/ Some are quite likely to break other projects' doc-tests which expect a particular str or repr of arrays, so I'd like to warn the list in case anyone has opinions. The current proposed changes, from most to least painful by my reckoning, are: 1. For float arrays, an extra space previously used for the sign position will now be omitted in many cases. Eg, `repr(arange(4.))` will now return 'array([0., 1., 2., 3.])' instead of 'array([ 0., 1., 2., 3.])'. 2. The printing of 0d arrays is overhauled. This is a bit finicky to describe, please see the release note in the PR. As an example of the effect of this, the `repr(np.array(0.))` now prints as 'array(0.)` instead of 'array(0.0)'. Also the repr of 0d datetime arrays is now like "array('2005-04-04', dtype='datetime64[D]')" instead of "array(datetime.date(2005, 4, 4), dtype='datetime64[D]')". 3. User-defined dtypes which did not properly implement their `repr` (and `str`) should do so now. Otherwise it now falls back to `object.__repr__`, which will return something ugly like `<mytype object at 0x7f37f1b4e918>`. (Previously you could depend on only implementing the `item` method and the repr of that would be printed. But no longer, because this risks infinite recursions.). 4. Bool arrays of size 1 with a 'True' value will now omit a space, so that `repr(array([True]))` is now 'array([True])' instead of 'array([ True])'. Allan

9 14

Array blitting (pasting one array into another)
by Mikhail V June 30, 2017

June 30, 2017

Hello all I often need to copy one array into another array, given an offset. This is how the "blit" function can be understood, i.e. in every graphical lib there is such a function. The common definition is like: blit ( dest, src, offset ): where dest is destination array, src is source array and offset is coordinates in destination where the src should pe blitted. Main feature of such function is that it never gives an error, so if the source does not fit into the destination array, it is simply trimmed. And respectively if there is no intersection area then nothing happens. Hope this is clear. So to make it work with Numpy arrays one need to calculate the slices before copying the data. I cannot find any Numpy or Python method to help with that so probably it does not exist yet. If so, my proposal is to add a Numpy method which helps with that. Namely the proposal will be to add a method which returns the slices for the intersection areas of two arbitrary arrays, given an offset, so then one can "blit" the array into another with simple assignment =. Here is a Python function I use for 2d arrays now: def interslice ( dest, src, offset ): y,x = offset H,W = dest.shape h,w = src.shape dest_starty = max (y,0) dest_endy = min (y+h,H) dest_startx = max (x,0) dest_endx = min (x+w,W) src_starty = 0 src_endy = h if y<0: src_starty = -y by = y+h - H # Y bleed if by>0: src_endy = h - by src_startx = 0 src_endx = w if x<0: src_startx = -x bx = x+w - W # X bleed if bx>0: src_endx = w - bx dest_sliceY = slice(dest_starty,dest_endy) dest_sliceX = slice(dest_startx,dest_endx) src_sliceY = slice(src_starty, src_endy) src_sliceX = slice(src_startx, src_endx) if dest_endy <= dest_starty: print "No Y intersection !" dest_sliceY = ( slice(0, 0) ) src_sliceY = ( slice(0, 0) ) if dest_endx <= dest_startx: print "No X intersection !" dest_sliceX = ( slice(0, 0) ) src_sliceX = ( slice(0, 0) ) dest_slice = ( dest_sliceY, dest_sliceX ) src_slice = ( src_sliceY, src_sliceX ) return ( dest_slice, src_slice ) ------ I have intentionally made it expanded and without contractions so that it is better understandable. It returns the intersection area of two arrays given an offset. First returned tuple element is the slice for DEST array and the second element is the slice for SRC array. If there is no intersection along one of the axis at all it returns the corresponding slice as (0,0) With this helper function one can blit arrays easily e.g. example code: W = 8; H = 8 DEST = numpy.ones([H,W], dtype = "uint8") w = 4; h = 1 SRC = numpy.zeros([h,w], dtype = "uint8") SRC[:]=8 offset = (0,9) ds, ss = interslice (DEST, SRC, offset ) # blit SRC into DEST DEST[ds] = SRC[ss] So changing the offset one can observe how the SRC array is trimmed if it is crosses the DEST boundaries. I think it is very useful function in general and it has well defined behaviour. It has usage not only for graphics, but actually any data copying-pasting between arrays. So I am looking forward to comments on this proposal. Mikhail

3 4

Boolean binary '-' operator
by Charles R Harris June 28, 2017

June 28, 2017

Hi All, The boolean binary '-' operator was deprecated back in NumPy 1.9 and changed to an error in 1.13. This caused a number of failures in downstream projects. The choices now are to continue the deprecation for another couple of releases, or simply give up on the change. For booleans, `a - b` was implemented as `a xor b`, which leads to the somewhat unexpected identity `a - b == b - a`, but it is a handy operator that allows simplification of some functions, `numpy.diff` among therm. At this point I'm inclined to give up on the deprecation and retain the old behavior. It is a bit impure but perhaps we can consider it a feature rather than a bug. The unary `-` operator for booleans, now an error, was also deprecated in 1.9 and changed to an error in 1.13. There have been no complaints about that (yet), and it seems like a reasonable thing to do, so I am inclined to leave that error in place. What do others think the correct way forward is? Chuck

13 16

why a[0][0].__mul__(a[0][0]) where a is np.array, gives 'missing 1 required positional argument'?
by Larry Evans June 27, 2017

June 27, 2017

The following code: --{--cut here-- #Purpose: # Demonstrate class with __add__ and __mult__ methods # to demonstrate shortestPath calculations. #OriginalSource: # ./shortestPath.py #References: # [1] http://www.marinamele.com/2014/04/modifying-add-method-of-python-class.html # [2] https://docs.scipy.org/doc/numpy/reference/c-api.types-and-structures.html#… # [3] https://www.abebooks.com/book-search/title/graphs-networks/author/carre-ber… # Table 3.1, path algebra P2. # [4] https://docs.python.org/3/library/abc.html ########################################### import numpy as np from abc import ABCMeta, abstractmethod class PathAbstract(metaclass=ABCMeta): @abstractmethod def __repr__(self): pass @abstractmethod def __add__(self, other): pass @abstractmethod def __radd__(self, other): pass @abstractmethod def __mul__(self, other): pass @abstractmethod def __rmul__(self, other): pass class ShortestNull(PathAbstract): '''Null object in ShortestPath algebra[3]''' def __str__(self): return "<0>" def __repr__(self): return self.__str__() def __addreal__(self, other): return other def __add__(self, other): return other def __radd__(self, other): return other def __mulreal__(self, other): return self def __mul__(self, other): return self def __rmul__(self, other): return self class ShortestUnit(PathAbstract): '''Unit object in ShortestPath algebra[3]''' def __str__(self): return "<1>" def __repr__(self): return self.__str__() def __addreal__(self, other): return self def __add__(self, other): return self def __radd__(self, other): return self def __mulreal__(self, other): return other def __mul__(self, other): return other def __rmul__(self, other): return other class ShortestPath(PathAbstract): def __init__(self, distance): self.distance = distance def __str__(self): return "{0:4.1f}".format(self.distance) def __repr__(self): return self.__str__() def __addreal__(self, other): #paths composed of following shortest of self path or other path. min_dist=min(self.distance,other.distance) return ShortestPath(min_dist) def __add__(self, other): #paths composed of following shortest of self path or other path. if(other == 0): n=ShortestNull() return n.__addreal__(self) else: return other.__addreal__(self) def __radd__(self, other): return self.__add__(other) def __mulreal__(self, other): #path composed of self path followed by other path. min_dist=self.distance+other.distance return ShortestPath(min_dist) def __mul__(self, other): return other.__mulreal__(self) def __rmul__(self, other): return other.__mulreal__(self) d0=ShortestNull() d1=ShortestUnit() d2=ShortestPath(3) d3=ShortestPath(6) print(' d0=',d0,' d1=',d1,' d2=',d2,' d3=',d3) print(' type(d0)=',type(d0).__name__) d4=d0+d2+d3 print('d4=',d4) d5=d2*d3 print('d5=',d5) d6=d0*d2 print('d6=',d6) d7=d1*d2 print('d7=',d7) d8=d2*d0 print('d8=',d8) d9=d2*d1 print('d9=',d9) a=np.array([[ShortestNull,ShortestPath(12)],[ShortestPath(12),ShortestNull()]],dtype=object) print('a=',a,sep='\n') print('a[0]=',a[0],sep='\n') print('a[0][0]=',a[0][0],sep='\n') #a00mul=a[0][0]*a[0][0] a00mul=a[0][0].__mul__(a[0][0]) print('a00mul=',a00mul,sep='\n') #at=a.transpose() #print('at=',at,sep='\n') #aat=a.dot(at) print('aat=',aat,sep='\n') #mp=np.matmul(a,at)#this gives error about Object arrays not supported. #print('mp=',mp) --}--cut here-- When run by make, gives this result: --{--cut here-- make -k python3 shortestPathABC.py d0= <0> d1= <1> d2= 3.0 d3= 6.0 type(d0)= ShortestNull d4= 3.0 d5= 9.0 d6= <0> d7= 3.0 d8= <0> d9= 3.0 a= [[<class '__main__.ShortestNull'> 12.0] [12.0 <0>]] a[0]= [<class '__main__.ShortestNull'> 12.0] a[0][0]= <class '__main__.ShortestNull'> Traceback (most recent call last): File "shortestPathABC.py", line 123, in <module> a00mul=a[0][0].__mul__(a[0][0]) TypeError: __mul__() missing 1 required positional argument: 'other' Makefile:7: recipe for target 'all' failed make: *** [all] Error 1 --}--cut here-- I don't understand why. Apparently, a[0][0] is not a ShortestNull because otherwise, the .__mul__ would have the positional argument, 'other' equal to a[0][0]. What am I missing? TIA. -regards, Larry

3 2

EuroSciPy 2017 call for contributions - extension of deadline
by Pierre de Buyl June 26, 2017

June 26, 2017

(Apologies if you receive multiple copies of this message) 10th European Conference on Python in Science August 28 - September 1, 2017 in Erlangen, Germany The Call for Papers is extended to July 02, 2017 23:00 CEST Description: The EuroSciPy meeting is a cross-disciplinary gathering focused on the use and development of the Python language in scientific research. This event strives to bring together both users and developers of scientific tools, as well as academic research and state of the art industry. Erlangen is one of Germany's major science hubs and located north of Munich (90 minutes by train). The Call for Papers is extended to July 02, 2017 23:00 CEST Regards, The EuroSciPy team https://www.euroscipy.org/2017/

1 0

PyRSB: Python interface to librsb sparse matrices library
by Michele Martone June 25, 2017

June 25, 2017

Hi. I'm the author of the high performance multithreaded sparse matrix library `librsb' (mostly C, LGPLv3): http://librsb.sourceforge.net/ I'm *not* a user of SciPy/NumPy/Python, but using Cython I have written a proof-of-concept interface to librsb, named `PyRSB': https://github.com/michelemartone/pyrsb PyRSB is in a prototypal state; e.g. still lacks good error handling. Its interface is trivial, as it mimicks that of SciPy's 'csr_matrix'. Advantages over csr_matrix are in fast multithreaded multiplication of huge sparse matrices. Intended application area is iterative solution of linear systems; particularly fast if with symmetric matrices and many rhs. With this email I am looking for prospective: - users/testers - developers (any interest to collaborate/adopt/include the project?) Looking forward for your feedback, Michele

6 10

ANN: SciPy 0.19.1 release
by Ralf Gommers June 23, 2017

June 23, 2017

On behalf of the Scipy development team I am pleased to announce the availability of Scipy 0.19.1. This is a bugfix-only release, no new features are included. This release requires Python 2.7 or 3.4-3.6 and NumPy 1.8.2 or greater. Source tarballs and release notes can be found at https://github.com/scipy/scipy/releases/tag/v0.19.1. OS X and Linux wheels are available from PyPI: https://pypi.python.org/pypi/scipy/0.19.1 Thanks to everyone who contributed! Cheers, Ralf -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ========================== SciPy 0.19.1 Release Notes ========================== SciPy 0.19.1 is a bug-fix release with no new features compared to 0.19.0. The most important change is a fix for a severe memory leak in ``integrate.quad``. Authors ======= * Evgeni Burovski * Patrick Callier + * Yu Feng * Ralf Gommers * Ilhan Polat * Eric Quintero * Scott Sievert * Pauli Virtanen * Warren Weckesser A total of 9 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.19.1 - ------------------------ - - `#7214 <https://github.com/scipy/scipy/issues/7214>`__: Memory use in integrate.quad in scipy-0.19.0 - - `#7258 <https://github.com/scipy/scipy/issues/7258>`__: ``linalg.matrix_balance`` gives wrong transformation matrix - - `#7262 <https://github.com/scipy/scipy/issues/7262>`__: Segfault in daily testing - - `#7273 <https://github.com/scipy/scipy/issues/7273>`__: ``scipy.interpolate._bspl.evaluate_spline`` gets wrong type - - `#7335 <https://github.com/scipy/scipy/issues/7335>`__: scipy.signal.dlti(A,B,C,D).freqresp() fails Pull requests for 0.19.1 - ------------------------ - - `#7211 <https://github.com/scipy/scipy/pull/7211>`__: BUG: convolve may yield inconsistent dtypes with method changed - - `#7216 <https://github.com/scipy/scipy/pull/7216>`__: BUG: integrate: fix refcounting bug in quad() - - `#7229 <https://github.com/scipy/scipy/pull/7229>`__: MAINT: special: Rewrite a test of wrightomega - - `#7261 <https://github.com/scipy/scipy/pull/7261>`__: FIX: Corrected the transformation matrix permutation - - `#7265 <https://github.com/scipy/scipy/pull/7265>`__: BUG: Fix broken axis handling in spectral functions - - `#7266 <https://github.com/scipy/scipy/pull/7266>`__: FIX 7262: ckdtree crashes in query_knn. - - `#7279 <https://github.com/scipy/scipy/pull/7279>`__: Upcast half- and single-precision floats to doubles in BSpline... - - `#7336 <https://github.com/scipy/scipy/pull/7336>`__: BUG: Fix signal.dfreqresp for StateSpace systems - - `#7419 <https://github.com/scipy/scipy/pull/7419>`__: Fix several issues in ``sparse.load_npz``, ``save_npz`` - - `#7420 <https://github.com/scipy/scipy/pull/7420>`__: BUG: stats: allow integers as kappa4 shape parameters Checksums ========= MD5 ~~~ 72415e8da753eea97eb9820602931cb5 scipy-0.19.1-cp27-cp27m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl e0022540df2735eb0475071b266d5d71 scipy-0.19.1-cp27-cp27m-manylinux1_i686.whl f513eb4ea2086de169a502df7efb91c7 scipy-0.19.1-cp27-cp27m-manylinux1_x86_64.whl 906c3c59209d6249b5d8ce14cfa01382 scipy-0.19.1-cp27-cp27mu-manylinux1_i686.whl afbf8ffb4a4fe7c18e34cb8a313c18ee scipy-0.19.1-cp27-cp27mu-manylinux1_x86_64.whl 5ba945b3404644244ab469883a1723f0 scipy-0.19.1-cp34-cp34m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 9c02cdd79e4ffadddcce7b2212039816 scipy-0.19.1-cp34-cp34m-manylinux1_i686.whl 79c0ba3618466614744de9a2f5362bbc scipy-0.19.1-cp34-cp34m-manylinux1_x86_64.whl 602a741a54190e16698ff8b2fe9fd27c scipy-0.19.1-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl d6c2ecadd4df36eb61870227fae42d3a scipy-0.19.1-cp35-cp35m-manylinux1_i686.whl e7167c0a9cf270f89437e2fd09731636 scipy-0.19.1-cp35-cp35m-manylinux1_x86_64.whl fc2e4679e83590ff19c1a5c5b1aa4786 scipy-0.19.1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 458615e9a56429a72038531dd5dcb3cb scipy-0.19.1-cp36-cp36m-manylinux1_i686.whl 65b1667ac56861da4cbc609960ed735b scipy-0.19.1-cp36-cp36m-manylinux1_x86_64.whl b704ebe9a28b8fe83d9f238d40031266 scipy-0.19.1.tar.gz cad6bac0638b176f72c00fe81ed54d19 scipy-0.19.1.tar.xz eb69261e5026ef2f3b9ae827caa7e5b8 scipy-0.19.1.zip SHA256 ~~~~~~ 1e8fedf602859b541ebae78667ccfc53158edef58d9ee19ee659309004565952 scipy-0.19.1-cp27-cp27m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 023ee29faa76c184a607e21076f097dc32f3abba7c71ece374588f95920aa993 scipy-0.19.1-cp27-cp27m-manylinux1_i686.whl 2a26d06a642e3c9107ca06df125f5dc5507abe2b87fd7865415d03ab654b0b43 scipy-0.19.1-cp27-cp27m-manylinux1_x86_64.whl b3e97be2cd9f052d984fc5ba2d441897971b744c64d658617944c47bc366f8ff scipy-0.19.1-cp27-cp27mu-manylinux1_i686.whl 78713101b32af384c564837fd7ae665a2a72cb6d49edbd8f32148d74724a65a8 scipy-0.19.1-cp27-cp27mu-manylinux1_x86_64.whl 2c9e87d556b83a8e11de7a064856c3997bbaff7f9cf62bf63ff0623751549e4c scipy-0.19.1-cp34-cp34m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl b87a923ed390ba0aafcbbcc6f0e023d495f19d2bd22ae59bdef3b0aec6485b39 scipy-0.19.1-cp34-cp34m-manylinux1_i686.whl 2dc9bcfaa585d9d941fb1add0d160556fe8587c3800264a77643695565a2d279 scipy-0.19.1-cp34-cp34m-manylinux1_x86_64.whl 93825cc80c638d901099f657dfff852ad2421beb51cb7d1d3f91157741ebe287 scipy-0.19.1-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 4118647273c907ed984da52b71fa2bbb30229f1820fb79b1ed087c8bc9a20cca scipy-0.19.1-cp35-cp35m-manylinux1_i686.whl 4c26ef44e8bb2cd2aef11c60d163caa04670d6f42996789b209526677310ded2 scipy-0.19.1-cp35-cp35m-manylinux1_x86_64.whl 2a3b6ceadbb58d8b8d4a329f8219f9e6f17757ec6c85baf03987bbd2b728c263 scipy-0.19.1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 909be30bdd1d8cd57609760ea72a1499543169ed6ea5c66fad50946582682cf8 scipy-0.19.1-cp36-cp36m-manylinux1_i686.whl 4de84e3870228e8afd55a6e63e762aa7c9d1e3bd9a9ef5ab716835a69c77d257 scipy-0.19.1-cp36-cp36m-manylinux1_x86_64.whl 9147f7b8b5ed4b80fefe82057a6d0d4bf3a50375a1d573407f84686d3b82c3bb scipy-0.19.1.tar.gz 0dca04c4860afdcb066cab4fd520fcffa8c85e9a7b5aa37a445308e899d728b3 scipy-0.19.1.tar.xz 2cc1baed85f7f702d958ad19e5d11c9dad917e981d3d0c299a7f0fd15027516a scipy-0.19.1.zip -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZTTG2AAoJEO2+o3i/Gl69V8gH/3S199hh1Fcl0a05VOCgt7aZ zRKvdZhYkqGvWoWX+YwJBaZn0aXThJfIDE2lAGt4S9PyxObBKzsujI8OLIZF4zU5 PtAARrooOqDEH1CC39k2gscF9GBhxAlxwntM2Hd8h+4xsklAhFVxn4UT0M8igBoX txpaIqghzBJnenkMq6lqrj7vhupuulz0zrMnJU4LetpdSxX1lb5sGvWmZDTKd/nr xmthQ4TmHPbf9jAYCtLI4V6OUGFGLQ+d7IqiYvU+DVKNZFEgyPMnvN9QvSdu6diR JBEIBcijxM0BqjPwRoavCQjCHk37kR/G3UsgcEyHO2tr5zuOXogjjBo3Bei8jnI= =lFXD -----END PGP SIGNATURE-----

1 0

[SciPy-Dev] PyRSB: Python interface to librsb sparse matrices library
by Michele Martone June 21, 2017

June 21, 2017

Hi. I'm the author of the high performance multithreaded sparse matrix library `librsb' (mostly C, LGPLv3): http://librsb.sourceforge.net/ I'm *not* a user of SciPy/NumPy/Python, but using Cython I have written a proof-of-concept interface to librsb, named `PyRSB': https://github.com/michelemartone/pyrsb PyRSB is in a prototypal state; e.g. still lacks good error handling. Its interface is trivial, as it mimicks that of SciPy's 'csr_matrix'. Advantages over csr_matrix are in fast multithreaded multiplication of huge sparse matrices. Intended application area is iterative solution of linear systems; particularly fast if with symmetric matrices and many rhs. With this email I am looking for prospective: - users/testers - developers (any interest to collaborate/adopt/include the project?) Looking forward for your feedback, Michele

1 0

Controlling NumPy __mul__ method or forcing it to use __rmul__ of the "other"
by Ilhan Polat June 19, 2017

June 19, 2017

I will assume some simple linear systems knowledge but the question can be generalized to any operator that implements __mul__ and __rmul__ methods. Motivation: I am trying to implement a gain matrix, say 3x3 identity matrix, for time being with a single input single output (SISO) system that I have implemented as a class modeling a Transfer or a state space representation. In the typical usecase, suppose you would like to create an n-many parallel connections with the same LTI system sitting at each branch. MATLAB implements this as an elementwise multiplication and returning a multi input multi output(MIMO) system. G = tf(1,[1,1]); eye(3)*G produces (manually compactified) ans = From input 1 to output... [ 1 ] [ ------ , 0 , 0 ] [ s + 1 ] [ 1 ] [ 0 , ------ , 0 ] [ s + 1 ] [ 1 ] [ 0 , 0 , ------ ] [ s + 1 ] Notice that the result type is of LTI system but, in our context, not a NumPy array with "object" dtype. In order to achieve a similar behavior, I would like to let the __rmul__ of G take care of the multiplication. In fact, when I do G.__rmul__(np.eye(3)) I can control what the behavior should be and I receive the exception/result I've put in. However the array never looks for this method and carries out the default array __mul__ behavior. The situation is similar if we go about it as left multiplication G*eye(3) has no problems since this uses directly the __mul__ of G. Therefore we get a different result depending on the direction of multiplication. Is there anything I can do about this without forcing users subclassing or just letting them know about this particular quirk in the documentation? What I have in mind is to force the users to create static LTI objects and then multiply and reject this possibility. But then I still need to stop NumPy returning "object" dtyped array to be able to let the user know about this. Relevant links just in case the library : https://github.com/ilayn/harold/ the issue discussion (monologue actually) : https://github.com/ilayn/harold/issues/7 The question I've asked on SO (but with a rather offtopic answer): https://stackoverflow.com/q/40694380/4950339 ilhan

3 5

np.diff on boolean arrays now raises
by Jaime Fernández del Río June 15, 2017

June 15, 2017

There is an ongoing discussion on github: https://github.com/numpy/numpy/issues/9251 In 1.13 np.diff has started raising on boolean arrays, since subtraction of boolean arrays is now deprecated. A decision has to be made whether: - raising an error is the correct thing to do, and only the docstring needs updating, or - backwards compatibility is more important and diff should still work on boolean arrays. If you have opinions on the subject, or enjoy arguing for the sake of it, please share your thoughts either here or on github. Thanks! -- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.

4 4

Taking NumPy in Stride workshop at PyData Barcelona
by Jaime Fernández del Río June 15, 2017

June 15, 2017

I ended up going to the PyData event in Barcelona last month and running a workshop there. The notebook I used can be found here: https://github.com/jaimefrio/pydatabcn2017/tree/master/taking_numpy_in_stri… I was afraid that the content would be too technical, but all the feedback I got from attendees was that they very much enjoyed it and want more of this deep technical dives into the belly of the beast. Of course IRL, contrary to the internet, it is easier to approach someone to tell them you like what they presented, than to tell them they suck. So maybe this is just a biased illusion, but until proven wrong I am encouraging anyone with the knowledge and the opportunity to go ahead and organize a similar workshop in any conference they go to. Jaime P.S. I also got a chance to catch up with Francesc Alted and Travis Oliphant, which is always great! -- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.

4 3

EuroSciPy 2017 call for contributions
by Pierre de Buyl June 12, 2017

June 12, 2017

(Apologies if you receive multiple copies of this message) 10th European Conference on Python in Science August 28 - September 1, 2017 in Erlangen, Germany Description: The EuroSciPy meeting is a cross-disciplinary gathering focused on the use and development of the Python language in scientific research. This event strives to bring together both users and developers of scientific tools, as well as academic research and state of the art industry. Erlangen is one of Germany's major science hubs and located north of Munich (90 minutes by train). Topics of Interest Presentations of scientific tools and libraries using the Python language, including but not limited to: - Vector and array manipulation - Parallel computing - Scientific visualization - Scientific data flow and persistence - Algorithms implemented or exposed in Python - Web applications and portals for science and engineering- - Reports on the use of Python in scientific achievements or ongoing projects. - General-purpose Python tools that can be of special interest to the scientific community. Submission Details: You can send your proposal by submitting your application here: https://www.papercall.io/euroscipy-2017 The Call for Papers closes on June 25, 2017 00:00 CEST Regards, The EuroSciPy team https://www.euroscipy.org/2017/

1 0

Add changelogs to repo
by Charles R Harris June 7, 2017

June 7, 2017

Hi All, I've made a PR <https://github.com/numpy/numpy/pull/9226> adding the NumPy `1.13.0-changelog.rst` to a new `doc/changelog` directory. The idea is to keep the lengthy changelogs separate from the release notes, but still easily accessible and permanently part to the NumPy history. If you hit the `rich diff` tag at the PR, you can see the rendered rst version. Thoughts? Chuck

1 0

NumPy 1.13.0 release
by Charles R Harris June 7, 2017

June 7, 2017

Hi All, On behalf of the NumPy team, I amn pleased to announce the NumPy 1.13.0 release. This release supports Python 2.7 and 3.4-3.6 and contains many new features. It is one of the most ambitious releases in the last several years. Some of the highlights and new functions are *Highlights* - Operations like ``a + b + c`` will reuse temporaries on some platforms, resulting in less memory use and faster execution. - Inplace operations check if inputs overlap outputs and create temporaries to avoid problems. - New __array_ufunc__ attribute provides improved ability for classes to override default ufunc behavior. - New np.block function for creating blocked arrays. *New functions* - New ``np.positive`` ufunc. - New ``np.divmod`` ufunc provides more efficient divmod. - New ``np.isnat`` ufunc tests for NaT special values. - New ``np.heaviside`` ufunc computes the Heaviside function. - New ``np.isin`` function, improves on ``in1d``. - New ``np.block`` function for creating blocked arrays. - New ``PyArray_MapIterArrayCopyIfOverlap`` added to NumPy C-API. Wheels for the pre-release are available on PyPI. Source tarballs, zipfiles, release notes, and the changelog are available on github <https://github.com/numpy/numpy/releases/tag/v1.13.0>. A total of 102 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - A. Jesse Jiryu Davis + - Alessandro Pietro Bardelli + - Alex Rothberg + - Alexander Shadchin - Allan Haldane - Andres Guzman-Ballen + - Antoine Pitrou - Antony Lee - B R S Recht + - Baurzhan Muftakhidinov + - Ben Rowland - Benda Xu + - Blake Griffith - Bradley Wogsland + - Brandon Carter + - CJ Carey - Charles Harris - Christoph Gohlke - Danny Hermes + - David Hagen + - David Nicholson + - Duke Vijitbenjaronk + - Egor Klenin + - Elliott Forney + - Elliott M Forney + - Endolith - Eric Wieser - Erik M. Bray - Eugene + - Evan Limanto + - Felix Berkenkamp + - François Bissey + - Frederic Bastien - Greg Young - Gregory R. Lee - Importance of Being Ernest + - Jaime Fernandez - Jakub Wilk + - James Cowgill + - James Sanders - Jean Utke + - Jesse Thoren + - Jim Crist + - Joerg Behrmann + - John Kirkham - Jonathan Helmus - Jonathan L Long - Jonathan Tammo Siebert + - Joseph Fox-Rabinovitz - Joshua Loyal + - Juan Nunez-Iglesias + - Julian Taylor - Kirill Balunov + - Likhith Chitneni + - Loïc Estève - Mads Ohm Larsen - Marein Könings + - Marten van Kerkwijk - Martin Thoma - Martino Sorbaro + - Marvin Schmidt + - Matthew Brett - Matthias Bussonnier + - Matthias C. M. Troffaes + - Matti Picus - Michael Seifert - Mikhail Pak + - Mortada Mehyar - Nathaniel J. Smith - Nick Papior - Oscar Villellas + - Pauli Virtanen - Pavel Potocek - Pete Peeradej Tanruangporn + - Philipp A + - Ralf Gommers - Robert Kern - Roland Kaufmann + - Ronan Lamy - Sami Salonen + - Sanchez Gonzalez Alvaro - Sebastian Berg - Shota Kawabuchi - Simon Gibbons - Stefan Otte - Stefan Peterson + - Stephan Hoyer - Søren Fuglede Jørgensen + - Takuya Akiba - Tom Boyd + - Ville Skyttä + - Warren Weckesser - Wendell Smith - Yu Feng - Zixu Zhao + - Zè Vinícius + - aha66 + - drabach + - drlvk + - jsh9 + - solarjoe + - zengi + Cheers, Chuck

1 0

Variance without temporary array
by marc June 7, 2017

June 7, 2017

Dear Numpy developers, I'm trying to write a version of the variance function that does not use temporary array. I got something that start to be functional (the branch is located here https://github.com/mbarbry/numpy/tree/sum_square_shift) but when running the tests I get the following memory error, Running unit tests for numpy NumPy version 1.14.0.dev0+f9db20b NumPy relaxed strides checking option: True NumPy is installed in /home/marc/programs/python/my_numpy/local/lib/python2.7/site-packages/numpy-1.14.0.dev0+f9db20b-py2.7-linux-x86_64.egg/numpy Python version 2.7.12 (default, Nov 19 2016, 06:48:10) [GCC 5.4.0 20160609] nose version 1.3.7 Program received signal SIGSEGV, Segmentation fault. 0x00007ffff1ef1f6d in inittest_rational () at numpy/core/src/umath/test_rational.c.src:1262 1262 REGISTER_UFUNC_BINARY_RATIONAL(add) This is weird because I didn't touch the umath module, I'm working in the multiarray one. Do you have a idea how I can debug this? Thanks for your help, Marc Barbry

1 0

Array and string interoperability
by Mikhail V June 7, 2017

June 7, 2017

Array and string interoperability Just sharing my thoughts and few ideas about simplification of casting strings to arrays. In examples assume Numpy is in the namespace (from numpy import *) Initialize array from a string currently looks like: s= "012 abc" A= fromstring(s,"u1") print A -> [48 49 50 32 97 98 99] Perfect. Now when writing values it will not work as IMO it should, namley consider this example: B= zeros(7,"u1") B[0]=s[1] print B -> [1 0 0 0 0 0 0] Ugh? It tries to parse the s[1] character "1" as integer and writes 1 to B[0]. First thing I would expect is a value error and I'd never expect it does that high-level manipulations with parsing. IMO ideally it would do the following instead: B[0]=s[1] print B -> [49 0 0 0 0 0 0] So it should just write ord(s[1]) to B. Sounds logical? For me very much. Further, one could write like this: B[:] = s print B-> [48 49 50 32 97 98 99] Namely cast the string into byte array. IMO this would be the logical expected behavior. Currently it just throws the value error if met non-digits in a string, so IMO current casting hardly can be of practical use. Furthermore, I think this code: A= array(s,"u1") Could act exactly same as: A= fromstring(s,"u1") But this is just a side-idea for spelling simplicty/generality. Not really necessary. Further thoughts: If trying to create "u1" array from a Pyhton 3 string, question is, whether it should throw an error, I think yes, and in this case "u4" type should be explicitly specified by initialisation, I suppose. And e.g. translation from unicode to extended ascii (Latin1) or whatever should be done on Python side or with explicit translation. Python3 assumes 4-byte strings but in reality most of the time we deal with 1-byte strings, so there is huge waste of resources when dealing with 4-bytes. For many serious projects it is just not needed. Furthermore I think some of the methods from "chararray" submodule should be possible to use directly on normal integer arrays without conversions to other array types. So I personally don't realy get why the need of additional chararray type, Its all numbers anyway and it's up to the programmer to decide what size of translation tables/value ranges he wants to use. There can be some convinience methods for ascii operations, like eg char.toupper(), but currently they don't seem to work with integer arrays so why not make those potentially useful methots usable and make them work on normal integer arrays? Or even migrate them to the root namespace to e.g. introduce names with prefixes: A=ascii_toupper(A) A=ascii_tolower(A) Many things can be be achieved with general numeric methods, e.g. translate/reduce the array. Here obviosly I mean not dynamical arrays, just fixed-sized arrays. How to deal with dynamically changing array sizes is another problematic, and it depends on how the software is designed in the first place and what it does with the data. For my own text-editing software project I consider fixed allocated 1D and 2D "uint8" arrays only. And specifically I experiment with own encodings, so just as a side-note, I don't think that encoding should be assumed much for creating new array types, it is up to the programmer to decide what 'meanings' the bytes have. Kind regards, Mikhail

3 9

Evaluate function of pairs from two meshgrids
by Florian Lindner June 2, 2017

June 2, 2017

Hello, I have 2*N arrays (let's say 2 arrays of length 4) that I combine using np.meshgrid xxA, yyA = np.meshgrid(xA, yA) xxB, yyB = np.meshgrid(xB, yB) which gives me two meshes xx.shape = yy.shape = (4,4) wish represent N-dimensional mesh with 16 elements. Now I want to evaluate a function f on every possible pair of N-dimensional points in the grid, resulting in a 16 x 16 matrix: in a flattened notation, pA = (xxA, yyA) f(pA[1]-pB[1]) f(pA[1]-pB[2]) f(pA[1]-pB[3]) ... f(pA[2]-pB[1]) f(pA[2]-pB[2]) f(pA[2]-pB[3]) ... f(pA[3]-pB[1]) f(pA[3]-pB[2]) f(pA[3]-pB[3]) ... . . . Let's say xA = yA = [1,2,3] and xB = yB = [10,20,30] that gives me a mesh A: (1,3) (2,3) (3,3) (1,2) (2,2) (3,2) (1,1) (2,1) (3,1) and a mesh B alike. My result matrix now should be of size 9 x 9: f( (1,3), (10,30) ) f( (2,3), (20,30) ) f( (3,3), (30, 30) ) f( (1,2), (10,20) ) f( (2,2), (20,20) ) f( (3,2), (30, 20) ) ... f always takes two N-dimensional vectors and returns a scalar. I hope I was able to explain what I want to achieve. What is the best way to do that in numpy? Thanks, Florian

1 0

Input on np.ma.polyfit default behaviour
by Joe P Ninan June 1, 2017

June 1, 2017

Hi numpy users, This email is regarding the discussion on how np.ma.polyfit should deal with non-uniform mask across columns in 2D data array. Github Issue#9193 [ https://github.com/numpy/numpy/issues/9193 ] Current behaviour of np.ma.polyfit is to union combine all the column masks across all the columns and do the polynomial fit for all columns using this same mask. This has the potentially undesired behaviour of masking out lots of data across the columns if just one column has a certain row masked out. Since the polynomial fit of data in each column is independent, it seems to be an undesired behaviour. We were thinking to change this behaviour by fitting columns with different mask, separately. What are the opinions on this in regards to backward compatibility? Was there any usecase for the previous behaviour? Also, any implementation ideas/suggestions on the plan currently being discussed in Issue#9193 page. Thanks, -cheers Joe -- /--------------------------------------------------------------- "GNU/Linux: because a PC is a terrible thing to waste" - GNU Generation ************************************************ Joe Philip Ninan Postdoctoral Researcher 406 Davey Lab, Dept. of Astronomy & Astrophysics The Pennsylvania State University University Park, PA-16802 ------------------------------------------------------------ Website: https://indiajoe.gitlab.io/ My GnuPG Public Key: https://indiajoe.gitlab.io/files/JPN_public.key

1 0