NumPy-Discussion September 2015

numpy-discussion@python.org

69 participants
66 discussions

Start a nNew thread

facebook, twitter, and g+

by Charles R Harris

Hi All, Just posting to elicit thoughts about scipy.org having a presence in social media for announcements. Chuck

6 years, 4 months

Commit rights for Allan Haldane

by Charles R Harris

Hi All, Allan Haldane has been given commit rights. Here's to the new member of the team. Chuck

6 years, 4 months

1.10.0rc1 coming tomorrow, 22 Sept.

by Charles R Harris

Hi All, Just a heads up. The lack of reported problems in 1.10.0b1 has been stunning. Chuck

6 years, 4 months

ANN: Numpy 1.9.3 bugfix release

by Matthew Brett

Hi, We have just released numpy 1.9.3, a small bugfix release to fix a bug on Python 3.5, as well as some build issues. You likely only need to upgrade from 1.9.2 if you are on Python 3.5. There are source and OSX wheels up on pypi. We currently have no plans to add 1.9.3 to the sourceforge site, because we cannot yet build a Python 3.5 installer with the standard mingw compiler. Issues fixed ============ * `#5866 <https://github.com/numpy/numpy/pull/5866>`__: fix error finding Python headers when ``build_ext`` ``--include-dirs`` is set; * `#6016 <https://github.com/numpy/numpy/pull/6016>`__: fix ``np.loadtxt`` error on Python 3.5 when reading from gzip files; * `#5555 <https://github.com/numpy/numpy/pull/5555>`__: Replace deprecated options for ifort; * `#6096 <https://github.com/numpy/numpy/pull/6096>`__: remove /GL for VS2015 in check_long_double_representation; * `#6141 <https://github.com/numpy/numpy/pull/6141>`__: enable Visual Studio 2015 C99 features; * `#6171 <https://github.com/numpy/numpy/pull/6171>`__: revert C99 complex for MSVC14. Cheers, Matthew Brett - for the numpy developers.

6 years, 4 months

Update on the recent mailing list outage

by Nathaniel Smith

Hi all, I'm sure you all noticed that numpy-discussion was down for 4-5 days this week. Apparently this was due to some unnoticed misconfigurations that were triggered when moving it from the ancient and unmaintainable server that it's been on for the last umpteen years. Some more details are here: https://github.com/numpy/numpy/issues/6325 There's some hope that this should reduce the frequency of outages going forward, though it's still not entirely clear how stable this new setup is or who is responsible for maintaining the list now or in the future -- if you know then please speak up :-). -n -- Nathaniel J. Smith -- http://vorpus.org

6 years, 4 months

method to calculate the magnitude squared

by Phillip Feldman

In communications and signal processing, it is frequently necessary to calculate the power of a signal. This can be done with a function like the following: def magsq(z): """ Return the magnitude squared of the real- or complex-valued input. """ return z.real**2 + z.imag**2 A high percentage of the scripts that I write contain or import a function like this. It would be great if there were a built-in method in NumPy, preferably with a name like `magsq`, `mag2`, or `msq`. Phillip

6 years, 4 months

Re: [Numpy-discussion] [Python-ideas] Should our default random number generator be secure?

by Robert Kern

[Tim, ping me if you want to get dropped from the reply chain, as we are liable to get more into numpy decision-making. I've dropped python-ideas.] On Mon, Sep 14, 2015 at 4:34 AM, Tim Peters <tim.peters(a)gmail.com> wrote: > > [Robert Kern <robert.kern(a)gmail.com>] > >> ... > >> I'll also recommend the PCG paper (and algorithm) as the author's > >> cross-PRNGs comparisons have been bandied about in this thread already. The > >> paper lays out a lot of the relevant issues and balances the various > >> qualities that are important: statistical quality, speed, and security (of > >> various flavors). > >> > >> http://www.pcg-random.org/paper.html > >> > >> I'm actually not that impressed with Random123. The core idea is nice and > >> clean, but the implementation is hideously complex. > > [Nathaniel Smith <njs(a)pobox.com>] > > I'm curious what you mean by this? In terms of the code, or...? In terms of the code that would be necessary to implement this in a simultaneously performant and cross-platform way in numpy.random. > > I haven't looked at the code, I recommend it! Approach it with the practical goal of "how do I stick this in as a new core PRNG for numpy.random?" > > but the simplest generator they > > recommend in the paper is literally just > > > > def rng_stream(seed): > > counter = 0 > > while True: > > # AES128 takes a 128 bit key and 128 bits of data and returns > > 128 bits of encrypted data > > val = AES128(key=seed, data=counter) > > yield low_64_bits(val) > > yield high_64_bits(val) > > counter += 1 > > I assume it's because if you expand what's required to _implement_ > AES128() in C, it does indeed look pretty hideously complex. On HW > implementing AES primitives, of course the code can be much simpler. > > But to be fair, if integer multiplication and/or addition weren't > implemented in HW, and we had to write to C code emulating them via > bit-level fiddling, the code for any of the PCG algorithms would look > hideously complex too. > > But being fair isn't much fun ;-) Actually, I meant all of the crap *around* it, the platform-compatibility testing to see if you have such a hardware instruction or not, and C++ template shenanigans in the surrounding code. It's possible that the complexity is only due to flexibility, but it was too complex for me to begin understanding *why* it's so complex before I succumbed to ennui and moved on to some other productive use of my free time. At least some of the complexity is due to needing software implementations of reduced-round crypto for decent performance in the absence of the hardware instruction. Performing well in the absence of the hardware instruction is very important to me as I do not seem to have the AES-NI instruction available on my mid-2012 Macbook Pro. Exposing counter-mode AES128 as a core PRNG is a nice idea, but it's just low on my wishlist. I want fast, multiple independent streams on my current hardware first, and PCG gives that to me. On the "if I had to implement all of the bit-fiddling myself" count, I'd still prefer PCG. It has a similar problem with 128-bit integers that may or may not be natively provided (should you want a 128-bit state), and I have to say that the software implementation of that bit-fiddling is much nicer to work with than reduced-round Threefry. It's reference implementation is also overly complex for practical use as it is showing off the whole parameterized PCG family to support the paper, even the explicitly unrecommended members. But it's relatively straightforward to disentangle the desirable members; their implementations, including the supporting 128-bit arithmetic code, are small and clean. -- Robert Kern

6 years, 4 months

Re: [Numpy-discussion] method to calculate the magnitude squared

by R Schumacher

At 10:01 AM 9/20/2015, you wrote: >Is that not the same as >Â Â np.abs(z)**2 ? > >It is, but since that involves taking sqrt, it is *much* slower. Even now, >``` >In [32]: r = np.arange(10000)*(1+1j) > >In [33]: %timeit np.abs(r)**2 >1000 loops, best of 3: 213 Âµs per loop > >In [34]: %timeit r.real**2 + r.imag**2 >10000 loops, best of 3: 47.5 Âµs per loop > >-- Marten Ahh yes, a full extra step, "back" Assuming these are spectra, how does timeit do with scipy.signal.periodogram (using appropriate n and scaling)? - Ray

6 years, 4 months

Compiling NumPy for iOS PyQt app?

by David Morris

I have a PyQt app running on iOS and would like to add NumPy to improve calculation speed. I see a few python interpreters in the app store which use NumPy so it must be possible, however I have not been able to find any information on the build process for the iOS cross compile. We are building a python with all libraries static linked. Here is the environment: iOS 8.0+ Python 3.4 PyQt 5.5 Qt 5.5 pyqtdeploy Any help getting NumPy compiled into the iOS app? Thank you, David

6 years, 4 months

Re: [Numpy-discussion] method to calculate the magnitude squared

by R Schumacher

At 09:16 PM 9/18/2015, you wrote: >In communications and signal processing, it is >frequently necessary to calculate the power of a >signal.Â This can be done with a function like the following: > >def magsq(z): >Â Â """ >Â Â Return the magnitude squared of the real- or complex-valued input. >Â Â """ >Â Â return z.real**2 + z.imag**2 Is that not the same as np.abs(z)**2 ? - Ray

6 years, 4 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

NumPy-Discussion September 2015