Mailman 3 December 2015 - NumPy-Discussion

random integers
by Charles R Harris Dec. 31, 2015

Dec. 31, 2015

Hi All, I've implemented several new random integer functions in #6910 <https://github.com/numpy/numpy/pull/6910>, to wit - np.random.random_int32 - np.random.random_int64 - np.random.random_intp These are the minimum functions that I think we need for the numpy 1.11.0 release, most especially the random_intp function for fuzz testing the mem_overlap functions. However, there is the question of the best way to expose the functions. Currently, they are all separately exposed, but it would also be possible to expose them through a new dtype argument to the current np.random.random_integers function. Note that all all the new functions would still be there, but they could be hidden as private functions. Also, there is the option of adding a complete set comprising booleans, int8, int16, and the unsigned versions. So the two, not mutually exclusive, proposed enhancements are - expose the new functions through a dtype argument to random_integers, hide the other functions - expose the new functions through a dtype argument to random_integers, not hide the other functions - make a complete set of random integer types There is currently no easy way to specify the complete range, so a proposal for that would be to generate random numbers over the full possible range of the type if no arguments are specified. That seems like a fairly natural extension. Finally, there is also a proposal to allow broadcasting/element wise selection of the range. This is the most complicated of the proposed enhancements and I am not really in favor, but it would be good to hear from others. Thoughts? Chuck

2 1

How to find indices of values in an array (indirect in1d) ?
by Nicolas P. Rougier Dec. 30, 2015

Dec. 30, 2015

I’m scratching my head around a small problem but I can’t find a vectorized solution. I have 2 arrays A and B and I would like to get the indices (relative to B) of elements of A that are in B: >>> A = np.array([2,0,1,4]) >>> B = np.array([1,2,0]) >>> print (some_function(A,B)) [1,2,0] # A[0] == 2 is in B and 2 == B[1] -> 1 # A[1] == 0 is in B and 0 == B[2] -> 2 # A[2] == 1 is in B and 1 == B[0] -> 0 Any idea ? I tried numpy.in1d with no luck. Nicolas

5 11

Re: [Numpy-discussion] How to find indices of values in an array (indirect in1d) ?
by Peter Creasey Dec. 30, 2015

Dec. 30, 2015

> > In the end, I?ve only the list comprehension to work as expected > > A = [0,0,1,3] > B = np.arange(8) > np.random.shuffle(B) > I = [list(B).index(item) for item in A if item in B] > > > But Mark's and Sebastian's methods do not seem to work... > The function you want is also in the open source astronomy package iccpy ( https://github.com/Lowingbn/iccpy ), which essentially does a variant of Sebastian’s code (which I also couldn’t quite get working), and handles a few things like old numpy versions (pre 1.4) and allows you to specify if B is already sorted. >>> from iccpy.utils import match >>> print match(A,B) [ 1 2 0 -1] Peter

1 0

Support of @= in numpy?
by Hans Larsen Dec. 27, 2015

Dec. 27, 2015

I have a Python3.5.1 64bits on Windows 10 same bit-length! I want to knowing when and what version of numpy, that support @= ? I have a functional numpy-1-10-1!=-O -- Hans Larsen Galgebakken Sønder 4-11A 2620 Albertslund Danmark/Danio

3 3

Problem writing array with savetxt (python3.5)
by Maxim Mayzel Dec. 26, 2015

Dec. 26, 2015

Dear all, I’m having a problem writing an array with np.savetxt, see below. (python3.5, numpy 1.10.1) import numpy as np a=np.ones(5,dtype=int) np.savetxt('t.txt',a) Works fine, but the content of ’t.txt’ is overwritten. But, passing file handle gives an error, while it works fine on python2.7 ! with open('t.txt','w') as t: np.savetxt(t,a,fmt='%i') ...: --------------------------------------------------------------------------- TypeError Traceback (most recent call last) /Users/may/anaconda/lib/python3.5/site-packages/numpy/lib/npyio.py in savetxt(fname, X, fmt, delimiter, newline, header, footer, comments) 1155 try: -> 1156 fh.write(asbytes(format % tuple(row) + newline)) 1157 except TypeError: TypeError: write() argument must be str, not bytes During handling of the above exception, another exception occurred: TypeError Traceback (most recent call last) <ipython-input-4-cce5156eb1e6> in <module>() 1 with open('t.txt','w') as t: ----> 2 np.savetxt(t,a,fmt='%i') 3 /Users/may/anaconda/lib/python3.5/site-packages/numpy/lib/npyio.py in savetxt(fname, X, fmt, delimiter, newline, header, footer, comments) 1158 raise TypeError("Mismatch between array dtype ('%s') and " 1159 "format specifier ('%s')" -> 1160 % (str(X.dtype), format)) 1161 if len(footer) > 0: 1162 footer = footer.replace('\n', '\n' + comments) TypeError: Mismatch between array dtype ('int64') and format specifier ('%i’) Best, Dr. Maxim Mayzel

2 1

Re: [Numpy-discussion] [SciPy-Dev] ANN: first release candidate for scipy 0.17.0
by Matthew Brett Dec. 24, 2015

Dec. 24, 2015

Hi, On Wed, Dec 23, 2015 at 12:34 PM, Evgeni Burovski <evgeny.burovskiy(a)gmail.com> wrote: > Hi, > > I'm pleased to announce the availability of the first release > candidate for Scipy 0.17.0. 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.0rc1 > > Please note that this is a source-only release. We do not provide > win32 installers for this release. See the email thread starting from > <https://mail.scipy.org/pipermail/scipy-dev/2015-December/021103.html> > for the rationale and discussion. > > The updated release schedule is as follows: > 10 Jan 2016: rc2 (if needed) > 17 Jan 2016: final release. > > Thanks to everyone who contributed to this release! Thanks for this. Wheels for rc1 at wheels.scipy.org, built via https://travis-ci.org/MacPython/scipy-wheels pip install --trusted-host wheels.scipy.org -f http://wheels.scipy.org --pre scipy Cheers, Matthew

1 0

packaging of numpy for windows
by jo Dec. 23, 2015

Dec. 23, 2015

Hi I would like to package python + numpy and our app for windows using pynsist in such a way that the user does not need to compile anything. Although pynsist made a package numpy did not start after installation due to some missing libraries. Obviously including the numpy directory is not enough. Is there an nsi script or filelist for numpy what I should deliver ? Do I need msft redistributables? tx

1 0

numpy-1.11.0.dev0 windows wheels compiled with mingwpy available
by Carl Kleffner Dec. 23, 2015

Dec. 23, 2015

I made numpy master (numpy-1.11.0.dev0 , https://github.com/numpy/numpy/commit/0243bce23383ff5e894b99e40df2f8fd806ad…) windows binary wheels available for testing. Install it with pip: > pip install -i https://pypi.anaconda.org/carlkl/simple numpy These builds are compiled with OPENBLAS trunk for BLAS/LAPACK support and the mingwpy compiler toolchain. OpenBLAS is deployed within the numpy wheels. To be performant on all usual CPU architectures OpenBLAS is configured with it's 'dynamic architecture' and automatic CPU detection. This version of numpy fakes long double as double just like the MSVC builds. Some test statistics: win32 (32 bit) numpy-1.11.0.dev0, python-2.6: errors=8, failures=1 numpy-1.11.0.dev0, python-2.7: errors=8, failures=1 numpy-1.11.0.dev0, python-3.3: errors=9 numpy-1.11.0.dev0, python-3.4: errors=9 amd64 (64bit) numpy-1.11.0.dev0, python-2.6: errors=9, failures=6 numpy-1.11.0.dev0, python-2.7: errors=9, failures=6 numpy-1.11.0.dev0, python-3.3: errors=10, failures=6 numpy-1.11.0.dev0, python-3.4: errors=10, failures=6 Carl

6 7

Re: [Numpy-discussion] PR for complex np.interp, question about assert_almost_equal
by Peter Creasey Dec. 22, 2015

Dec. 22, 2015

>>> The tests pass on my machine, but I see that the TravisCI builds are >>> giving assertion fails (on my own test) with python 3.3 and 3.5 of the >>> form: >>> > assert_almost_equal >>> > TypeError: Cannot cast array data from dtype('complex128') to >>> dtype('float64') according to the rule 'safe' >>> > > The problem then is probably here > <https://github.com/numpy/numpy/pull/6872/files#diff-45aacfd88a495829ee10815…> > . > > You may want to throw in a PyErr_Clear() > <https://docs.python.org/3/c-api/exceptions.html#c.PyErr_Clear> when the > conversion of the fp array to NPY_DOUBLE fails before trying with > NPY_CDOUBLE, and check if it goes away. > Thanks for your tip Jaime, you were exactly right. Unfortunately I only saw your message after and addressed the problem in a different way to your suggestion (passing in a flag instead). It'd be great to have your input on the PR though (maybe github or pm me, to avoid flooding the mailing list). Best, Peter

1 0

Proposal: stop providing official win32 downloads (for now)
by Nathaniel Smith Dec. 22, 2015

Dec. 22, 2015

Hi all, I'm wondering what people think of the idea of us (= numpy) stopping providing our "official" win32 builds (the "superpack installers" distributed on sourceforge) starting with the next release. These builds are: - low quality: they're linked to an old & untuned build of ATLAS, so linear algebra will be dramatically slower than builds using MKL or OpenBLAS. They're win32 only and will never support win64. They're using an ancient version of gcc. They will never support python 3.5 or later. - a dead end: there's a lot of work going on to solve the windows build problem, and hopefully we'll have something better in the short-to-medium-term future; but, any solution will involve throwing out the current system entirely and switching to a new toolchain, wheel-based distribution, etc. - a drain on our resources: producing these builds is time-consuming and finicky; I'm told that these builds alone are responsible for a large proportion of the energy spent preparing each release, and take away from other things that our release managers could be doing (e.g. QA and backporting fixes). So the idea would be that for 1.11, we create a 1.11 directory on sourceforge and upload one final file: a README explaining the situation, a pointer to the source releases on pypi, and some links to places where users can find better-supported windows builds (Gohlke's page, Anaconda, etc.). I think this would serve our users better than the current system, while also freeing up a drain on our resources. Thoughts? -n -- Nathaniel J. Smith -- http://vorpus.org

11 20