Mailman 3 March 2018 - NumPy-Discussion

Re: [Numpy-discussion] numpy.random.randn
by Marko Asplund March 13, 2018

March 13, 2018

On Fri, 9 Mar 2018 11:38:55, Robert Kern wrote: > > Sorry for being a bit inaccurate. > > My Scala code actually mirrors the NumPy based random initialization, so > > I sample with Gaussian of mean = 0 and std dev = 1, then multiply with 0.01. > > Have you verified this? I.e. save out the Scala-initialized network and > load it up with numpy to check the mean and std dev? How about if you run > the numpy NN training with the Scala-initialized network? Does that also > diverge? I did what you suggested and it turned out my NumPy NN code was behaving exactly as the Scala code when using Scala-initialized network. After digging deeper into this I managed to find and fix a bug in how I was doing the random initilization and it's working correctly now. Thanks a lot for your help! Marko

1 0

New NEP: merging multiarray and umath
by Nathaniel Smith March 12, 2018

March 12, 2018

Hi all, Well, this is something that we've discussed for a while and I think generally has consensus already, but I figured I'd write it down anyway to make sure. There's a rendered version here: https://github.com/njsmith/numpy/blob/nep-0015-merge-multiarray-umath/doc/n… ----- ============================ Merging multiarray and umath ============================ :Author: Nathaniel J. Smith <njs(a)pobox.com> :Status: Draft :Type: Standards Track :Created: 2018-02-22 Abstract -------- Let's merge ``numpy.core.multiarray`` and ``numpy.core.umath`` into a single extension module, and deprecate ``np.set_numeric_ops``. Background ---------- Currently, numpy's core C code is split between two separate extension modules. ``numpy.core.multiarray`` is built from ``numpy/core/src/multiarray/*.c``, and contains the core array functionality (in particular, the ``ndarray`` object). ``numpy.core.umath`` is built from ``numpy/core/src/umath/*.c``, and contains the ufunc machinery. These two modules each expose their own separate C API, accessed via ``import_multiarray()`` and ``import_umath()`` respectively. The idea is that they're supposed to be independent modules, with ``multiarray`` as a lower-level layer with ``umath`` built on top. In practice this has turned out to be problematic. First, the layering isn't perfect: when you write ``ndarray + ndarray``, this invokes ``ndarray.__add__``, which then calls the ufunc ``np.add``. This means that ``ndarray`` needs to know about ufuncs – so instead of a clean layering, we have a circular dependency. To solve this, ``multiarray`` exports a somewhat terrifying function called ``set_numeric_ops``. The bootstrap procedure each time you ``import numpy`` is: 1. ``multiarray`` and its ``ndarray`` object are loaded, but arithmetic operations on ndarrays are broken. 2. ``umath`` is loaded. 3. ``set_numeric_ops`` is used to monkeypatch all the methods like ``ndarray.__add__`` with objects from ``umath``. In addition, ``set_numeric_ops`` is exposed as a public API, ``np.set_numeric_ops``. Furthermore, even when this layering does work, it ends up distorting the shape of our public ABI. In recent years, the most common reason for adding new functions to ``multiarray``\'s "public" ABI is not that they really need to be public or that we expect other projects to use them, but rather just that we need to call them from ``umath``. This is extremely unfortunate, because it makes our public ABI unnecessarily large, and since we can never remove things from it then this creates an ongoing maintenance burden. The way C works, you can have internal API that's visible to everything inside the same extension module, or you can have a public API that everyone can use; you can't have an API that's visible to multiple extension modules inside numpy, but not to external users. We've also increasingly been putting utility code into ``numpy/core/src/private/``, which now contains a bunch of files which are ``#include``\d twice, once into ``multiarray`` and once into ``umath``. This is pretty gross, and is purely a workaround for these being separate C extensions. Proposed changes ---------------- This NEP proposes three changes: 1. We should start building ``numpy/core/src/multiarray/*.c`` and ``numpy/core/src/umath/*.c`` together into a single extension module. 2. Instead of ``set_numeric_ops``, we should use some new, private API to set up ``ndarray.__add__`` and friends. 3. We should deprecate, and eventually remove, ``np.set_numeric_ops``. Non-proposed changes -------------------- We don't necessarily propose to throw away the distinction between multiarray/ and umath/ in terms of our source code organization: internal organization is useful! We just want to build them together into a single extension module. Of course, this does open the door for potential future refactorings, which we can then evaluate based on their merits as they come up. It also doesn't propose that we break the public C ABI. We should continue to provide ``import_multiarray()`` and ``import_umath()`` functions – it's just that now both ABIs will ultimately be loaded from the same C library. Due to how ``import_multiarray()`` and ``import_umath()`` are written, we'll also still need to have modules called ``numpy.core.multiarray`` and ``numpy.core.umath``, and they'll need to continue to export ``_ARRAY_API`` and ``_UFUNC_API`` objects – but we can make one or both of these modules be tiny shims that simply re-export the magic API object from where-ever it's actually defined. (See ``numpy/core/code_generators/generate_{numpy,ufunc}_api.py`` for details of how these imports work.) Backward compatibility ---------------------- The only compatibility break is the deprecation of ``np.set_numeric_ops``. Alternatives ------------ n/a Discussion ---------- TBD Copyright --------- This document has been placed in the public domain. -- Nathaniel J. Smith -- https://vorpus.org

7 16

NumPy 1.14.2 released
by Charles R Harris March 12, 2018

March 12, 2018

Hi All, I am pleased to announce the release of NumPy 1.14.2. This is a bugfix release for some bugs reported following the 1.14.1 release. The major problems dealt with are as follows. - Residual bugs in the new array printing functionality. - Regression resulting in a relocation problem with shared library. - Improved PyPy compatibility. This release supports Python 2.7 and 3.4 - 3.6. Wheels for the 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.14.2>. The Python 3.6 wheels available from PIP are built with Python 3.6.2 and should be compatible with all previous versions of Python 3.6. The source releases were cythonized with Cython 0.26.1, which is known to *not* support the upcoming Python 3.7 release. People who wish to run Python 3.7 should check out the NumPy repo and try building with the, as yet, unreleased master branch of Cython. Contributors ============ A total of 4 people contributed to this release. People with a "+" by their names contributed a patch for the first time. * Allan Haldane * Charles Harris * Eric Wieser * Pauli Virtanen Pull requests merged ==================== A total of 5 pull requests were merged for this release. * `#10674 <https://github.com/numpy/numpy/pull/10674>`__: BUG: Further back-compat fix for subclassed array repr * `#10725 <https://github.com/numpy/numpy/pull/10725>`__: BUG: dragon4 fractional output mode adds too many trailing zeros * `#10726 <https://github.com/numpy/numpy/pull/10726>`__: BUG: Fix f2py generated code to work on PyPy * `#10727 <https://github.com/numpy/numpy/pull/10727>`__: BUG: Fix missing NPY_VISIBILITY_HIDDEN on npy_longdouble_to_PyLong * `#10729 <https://github.com/numpy/numpy/pull/10729>`__: DOC: Create 1.14.2 notes and changelog. Cheers, Charles Harris

1 0

NumPy 1.14.2 release
by Charles R Harris March 9, 2018

March 9, 2018

Hi All, I'm looking to make a NumPy soonish, possibly at the beginning of next week. The only change planned is a fix for the printing problem that the astropy folks reported. The fix for that problem is also in master, so if you test against master you should be able check if the fix works for you. If you have experienced any other problems with 1.14.1, please report them, and also mention them here so that they don't fall through the cracks. Chuck

2 1

Re: [Numpy-discussion] numpy.random.randn
by Marko Asplund March 9, 2018

March 9, 2018

On Wed, 7 Mar 2018 13:14:36, Robert Kern wrote: > > With NumPy I'm simply using the following random initilization code: > > > > np.random.randn(n_h, n_x) * 0.01 > > > > I'm trying to emulate the same behaviour in my Scala code by sampling > from a > > Gaussian distribution with mean = 0 and std dev = 1. > `np.random.randn(n_h, n_x) * 0.01` gives a Gaussian distribution of mean=0 > and stdev=0.01 Sorry for being a bit inaccurate. My Scala code actually mirrors the NumPy based random initialization, so I sample with Gaussian of mean = 0 and std dev = 1, then multiply with 0.01. Despite the extra step the result should be the same as with the NumPy code above. Is there anything else that could be different with the random initilization methods? marko

2 1

Endian dtype specifier without using character codes?
by Matthew Brett March 9, 2018

March 9, 2018

Hi, We (over at https://github.com/nipy/nibabel) often want to do stuff like this: ``` dtype_type = 'i' size = 8 endianness = '<' dtype = np.dtype('{}{}{}'.format(endianness, dtype_type, size)) ``` I see that """ Use of the character codes, however, is discouraged. """ https://docs.scipy.org/doc/numpy-1.14.0/reference/arrays.scalars.html What is the recommended way of specifying endianness in my dtype, if I am not using the character codes? Do I have to use something like: ``` np.dtype('int64').newbyteorder(endianness) ``` ? Cheers, Matthew

1 0

numpy.random.randn
by Marko Asplund March 7, 2018

March 7, 2018

I've some neural network code in NumPy that I'd like to compare with a Scala based implementation. My problem is currently random initialization of the neural net parameters. I'd like to be able to get the same results from both implementations when using the same random seed. One approach I've though of would be to use the NumPy random generator also with the Scala implementation, but unfortunately the linear algebra library I'm using doesn't provide an equivalent for this. Could someone give pointers to implementing numpy.random.randn? Or alternatively, is there an equivalent random generator for Scala or Java? marko

2 3

ANN: SfePy 2018.1
by Robert Cimrman March 6, 2018

March 6, 2018

I am pleased to announce release 2018.1 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 -------------------------- - major update of time-stepping solvers and solver handling - Newmark and Bathe elastodynamics solvers - interface to MUMPS linear solver - new examples: - iron plate impact problem (elastodynamics) - incompressible Mooney-Rivlin material model (hyperelasticity) as a script 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 Jan Kopacka Vladimir Lukes

1 0

Request for review: PR #10689
by Russell Keith-Magee March 4, 2018

March 4, 2018

Hi all, I’ve just submitted PR #10689, making some small changes to allow NumPy to be compiled on iOS. https://github.com/numpy/numpy/pull/10689 <https://github.com/numpy/numpy/pull/10689> The changes are described in detail on the PR description. For the most part, they’re changes to differentiate between building *on* macOS, and building *for* macOS. Yours, Russ Magee %-)

1 0