Mailman 3 September 2015 - NumPy-Discussion

Tentative numpy tutorial
by Dan Patterson Sept. 23, 2015

Sept. 23, 2015

Bryan is this the tutorial to which you refer? http://docs.scipy.org/doc/scipy/reference/tutorial/index.html

2 1

ANN: SfePy 2015.3
by Robert Cimrman Sept. 23, 2015

Sept. 23, 2015

I am pleased to announce release 2015.3 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 (preliminary support). It is distributed under the new BSD license. Home page: http://sfepy.org Mailing list: http://groups.google.com/group/sfepy-devel Git (source) repository, issue tracker, wiki: http://github.com/sfepy Highlights of this release -------------------------- - preliminary support for parallel computing - unified evaluation of basis functions (= isogeometric analysis fields can be evaluated in arbitrary points) - (mostly) fixed finding of reference element coordinates of physical points - several new or improved examples For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1 (rather long and technical). Best regards, Robert Cimrman on behalf of the SfePy development team --- Contributors to this release in alphabetical order: Robert Cimrman Vladimir Lukes

1 0

facebook, twitter, and g+
by Charles R Harris Sept. 23, 2015

Sept. 23, 2015

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

3 2

Commit rights for Allan Haldane
by Charles R Harris Sept. 22, 2015

Sept. 22, 2015

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

4 3

1.10.0rc1 coming tomorrow, 22 Sept.
by Charles R Harris Sept. 22, 2015

Sept. 22, 2015

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

4 4

ANN: Numpy 1.9.3 bugfix release
by Matthew Brett Sept. 21, 2015

Sept. 21, 2015

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.

1 0

Update on the recent mailing list outage
by Nathaniel Smith Sept. 21, 2015

Sept. 21, 2015

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

1 0

method to calculate the magnitude squared
by Phillip Feldman Sept. 20, 2015

Sept. 20, 2015

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

2 1

Re: [Numpy-discussion] [Python-ideas] Should our default random number generator be secure?
by Robert Kern Sept. 20, 2015

Sept. 20, 2015

[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

4 9

Re: [Numpy-discussion] method to calculate the magnitude squared
by R Schumacher Sept. 20, 2015

Sept. 20, 2015

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

1 0