Mailman 3 March 2018 - NumPy-Discussion

Right way to do fancy indexing from argsort() result?
by Benjamin Root 27 Mar '18

27 Mar '18

I seem to be losing my mind... I can't seem to get this to work right. I have a (N, k) array `distances` (along with a bunch of other arrays of the same shape). I need to resort the rows, so I do: indexs = np.argsort(distances, axis=1) How do I use this index array correctly to get back distances sorted along rows? Note, telling me to use `np.sort()` isn't going to work because I need to apply the same indexing to a couple of other arrays. new_dists = distances[indexs] gives me a (N, k, k) array, while new_dists = np.take(indexs, axis=1) gives me a (N, N, k) array. What am I missing? Thanks! Ben Root

3 3

nditer as a context manager
by Matti Picus 26 Mar '18

26 Mar '18

|Hello all, PR #9998 (https://github.com/numpy/numpy/pull/9998/) proposes an update to the nditer API, both C and python. The issue (link) is that |||sometimes nditer uses temp arrays via the "writeback" mechanism, the data is copied back to the original arrays "when finished". However "when finished" was implemented using nditer deallocation. |This mechanism is implicit and unclear, and relies on refcount semantics which do not work on non-refcount python implementations like PyPY. It also leads to lines of code like "iter=None" to trigger the writeback resolution. On the c-api level the agreed upon solution is to add a new |||`NpyIter_Close` function in C, this is to be called before `NpyIter_Dealloc`. The reviewers and I would like to ask the wider NumPy community for opinions about the proposed python-level solution: |turning the python nditer object into a context manager. This way "writeback" occurs at context manager exit via a call to `NpyIter_Close`, instead of like before when it occurred at nditer deallocation (which might not happen until much later in Pypy, and could be delayed by GC even in Cpython). Another solution that was rejected (https://github.com/numpy/numpy/pull/10184) was to add an nditer.close() python-level function that would not require a context manager It was felt that this is more error-prone since it requires users to add the line for each iterator created. The back-compat issues are that: 1. We are adding a new function to the numpy API, `NpyIter_Close` (pretty harmless) 2. We want people to update their C code using nditer, to call `NpyIter_Close` before they call `NpyIter_Dealloc` and will start raising a deprecation warning if misuse is detected 3. We want people to update their Python code to use the nditer object as a context manager, and will warn if they do not. We tried to minimize back-compat issues, in the sense that old code (which didn't work in PyPy anyway) will still work, although it will now emit deprecation warnings. In the future we also plan to raise an error if an nditer is used in Python without a context manager (when it should have been). For C code, we plan to leave the deprecation warning in place probably forever, as we can only detect the deprecated behavior in the deallocator, where exceptions cannot be raised. Anybody who uses nditers should take a look and please reply if it seems the change will be too painful. For more details, please see the updated docs in that PR Matti (and reviewers) |

2 2

ANN: SciPy 1.0.1 released
by Ralf Gommers 25 Mar '18

25 Mar '18

On behalf of the SciPy development team I am pleased to announce the availability of Scipy 1.0.1. This is a maintenance release, no new features with respect to 1.0.0. See the release notes below for details. Wheels and sources can be found on PyPI (https://pypi.python.org/pypi/scipy) and on Github (https://github.com/scipy/scipy/releases/tag/v1.0.1). The conda-forge channel will be up to date within a couple of hours. Thanks to everyone who contributed to this release! Cheers, Ralf SciPy 1.0.1 Release Notes ==================== SciPy 1.0.1 is a bug-fix release with no new features compared to 1.0.0. Probably the most important change is a fix for an incompatibility between SciPy 1.0.0 and ``numpy.f2py`` in the NumPy master branch. Authors ======= * Saurabh Agarwal + * Alessandro Pietro Bardelli * Philip DeBoer * Ralf Gommers * Matt Haberland * Eric Larson * Denis Laxalde * Mihai Capotă + * Andrew Nelson * Oleksandr Pavlyk * Ilhan Polat * Anant Prakash + * Pauli Virtanen * Warren Weckesser * @xoviat * Ted Ying + A total of 16 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 1.0.1 ----------------------- - `#7493 <https://github.com/scipy/scipy/issues/7493>`__: `ndimage.morphology` functions are broken with numpy 1.13.0 - `#8118 <https://github.com/scipy/scipy/issues/8118>`__: minimize_cobyla broken if `disp=True` passed - `#8142 <https://github.com/scipy/scipy/issues/8142>`__: scipy-v1.0.0 pdist with metric=`minkowski` raises `ValueError:... - `#8173 <https://github.com/scipy/scipy/issues/8173>`__: `scipy.stats.ortho_group` produces all negative determinants... - `#8207 <https://github.com/scipy/scipy/issues/8207>`__: gaussian_filter seg faults on float16 numpy arrays - `#8234 <https://github.com/scipy/scipy/issues/8234>`__: `scipy.optimize.linprog` `interior-point` presolve bug with trivial... - `#8243 <https://github.com/scipy/scipy/issues/8243>`__: Make csgraph importable again via `from scipy.sparse import*` - `#8320 <https://github.com/scipy/scipy/issues/8320>`__: scipy.root segfaults with optimizer 'lm' Pull requests for 1.0.1 ----------------------- - `#8068 <https://github.com/scipy/scipy/pull/8068>`__: BUG: fix numpy deprecation test failures - `#8082 <https://github.com/scipy/scipy/pull/8082>`__: BUG: fix solve_lyapunov import - `#8144 <https://github.com/scipy/scipy/pull/8144>`__: MRG: Fix for cobyla - `#8150 <https://github.com/scipy/scipy/pull/8150>`__: MAINT: resolve UPDATEIFCOPY deprecation errors - `#8156 <https://github.com/scipy/scipy/pull/8156>`__: BUG: missing check on minkowski w kwarg - `#8187 <https://github.com/scipy/scipy/pull/8187>`__: BUG: Sign of elements in random orthogonal 2D matrices in "ortho_group_gen"... - `#8197 <https://github.com/scipy/scipy/pull/8197>`__: CI: uninstall oclint - `#8215 <https://github.com/scipy/scipy/pull/8215>`__: Fixes Numpy datatype compatibility issues - `#8237 <https://github.com/scipy/scipy/pull/8237>`__: BUG: optimize: fix bug when variables fixed by bounds are inconsistent... - `#8248 <https://github.com/scipy/scipy/pull/8248>`__: BUG: declare "gfk" variable before call of terminate() in newton-cg - `#8280 <https://github.com/scipy/scipy/pull/8280>`__: REV: reintroduce csgraph import in scipy.sparse - `#8322 <https://github.com/scipy/scipy/pull/8322>`__: MAINT: prevent scipy.optimize.root segfault closes #8320 - `#8334 <https://github.com/scipy/scipy/pull/8334>`__: TST: stats: don't use exact equality check for hdmedian test - `#8477 <https://github.com/scipy/scipy/pull/8477>`__: BUG: signal/signaltools: fix wrong refcounting in PyArray_OrderFilterND - `#8530 <https://github.com/scipy/scipy/pull/8530>`__: BUG: linalg: Fixed typo in flapack.pyf.src. - `#8566 <https://github.com/scipy/scipy/pull/8566>`__: CI: Temporarily pin Cython version to 0.27.3 - `#8573 <https://github.com/scipy/scipy/pull/8573>`__: Backports for 1.0.1 - `#8581 <https://github.com/scipy/scipy/pull/8581>`__: Fix Cython 0.28 build break of qhull.pyx

1 0

[ANN] 11ᵗʰ Advanced Scientific Programming in Python in Camerino, Italy, 3—8 September, 2018
by Python School Organizers 23 Mar '18

23 Mar '18

11ᵗʰ Advanced Scientific Programming in Python ============================================== a Summer School by the G-Node and the University of Camerino https://python.g-node.org Scientists spend more and more time writing, maintaining, and debugging software. While techniques for doing this efficiently have evolved, only few scientists have been trained to use them. As a result, instead of doing their research, they spend far too much time writing deficient code and reinventing the wheel. In this course we will present a selection of advanced programming techniques and best practices which are standard in the industry, but especially tailored to the needs of a programming scientist. Lectures are devised to be interactive and to give the students enough time to acquire direct hands-on experience with the materials. Students will work in pairs throughout the school and will team up to practice the newly learned skills in a real programming project — an entertaining computer game. We use the Python programming language for the entire course. Python works as a simple programming language for beginners, but more importantly, it also works great in scientific simulations and data analysis. We show how clean language design, ease of extensibility, and the great wealth of open source libraries for scientific computing and data visualization are driving Python to become a standard tool for the programming scientist. This school is targeted at Master or PhD students and Post-docs from all areas of science. Competence in Python or in another language such as Java, C/C++, MATLAB, or Mathematica is absolutely required. Basic knowledge of Python and of a version control system such as git, subversion, mercurial, or bazaar is assumed. Participants without any prior experience with Python and/or git should work through the proposed introductory material before the course. We are striving hard to get a pool of students which is international and gender-balanced: see how far we got in previous years <https://python.g-node.org/wiki/archives#stats>! Date & Location =============== 3–8 September, 2018. Camerino, Italy. Application =========== You can apply online: https://python.g-node.org/wiki/applications Application deadline: 23:59 UTC, 31 May, 2018. There will be no deadline extension, so be sure to apply on time. Be sure to read the FAQ before applying: https://python.g-node.org/wiki/faq Participation is for free, i.e. no fee is charged! Participants however should take care of travel, living, and accommodation expenses by themselves. Program ======= • Version control with git and how to contribute to open source projects with GitHub • Best practices in data visualization • Organizing, documenting, and distributing scientific code • Testing scientific code • Profiling scientific code • Advanced NumPy • Advanced scientific Python: decorators, context managers, generators, and elements of object oriented programming • Writing parallel applications in Python • Speeding up scientific code with Cython and numba • Memory-bound computations and the memory hierarchy • Programming in teams Also see the detailed day-by-day schedule: https://python.g-node.org/wiki/schedule Faculty ======= • Ashwin Trikuta Srinath, Cyberinfrastructure Technology Integration, Clemson University, SC USA • Jenni Rinker, Department of Wind Energy, Technical University of Denmark, Roskilde Denmark • Juan Nunez-Iglesias, Melbourne Bioinformatics, University of Melbourne Australia • Nicolas P. Rougier, Inria Bordeaux Sud-Ouest, Institute of Neurodegenerative Disease, University of Bordeaux France • Pietro Berkes, NAGRA Kudelski, Lausanne Switzerland • Rike-Benjamin Schuppner, Institute for Theoretical Biology, Humboldt-Universität zu Berlin Germany • Tiziano Zito, freelance consultant, Berlin Germany • Zbigniew Jędrzejewski-Szmek, Red Hat Inc., Warsaw Poland Organizers ========== For the German Neuroinformatics Node of the INCF (G-Node) Germany: • Tiziano Zito, freelance consultant, Berlin Germany • Caterina Buizza, Personal Robotics Lab, Imperial College London UK • Zbigniew Jędrzejewski-Szmek, Red Hat Inc., Warsaw Poland • Jakob Jordan, Department of Physiology, University of Bern, Switzerland Switzerland For the University of Camerino Italy: • Flavio Corradini, Computer Science Division, School of Science and Technology, University of Camerino Italy • Barbara Re, Computer Science Division, School of Science and Technology, University of Camerino Italy Website: https://python.g-node.org Contact: python-info(a)g-node.org

1 0

3D array slicing bug?
by Michael Himes 22 Mar '18

22 Mar '18

Hi, I have discovered what I believe is a bug with array slicing involving 3D (and higher) dimension arrays. When slicing a 3D array by a single value for axis 0, all values for axis 1, and a list to slice axis 2, the dimensionality of the resulting 2D array is flipped. However, slicing more than a single index for axis 0 or performing the slicing in two steps results in the correct dimensionality. Below is a quick example to demonstrate this behavior. import numpy as np arr = np.arange(54).reshape(2, 3, 9) list = [0, 2, 4, 5, 8] print(arr.shape) # (2, 3, 9) print(arr[0, :, list].shape) # (5, 3) -- but it should be (3, 5)? print(arr[0][:, list].shape) # (3, 5), as expected print(arr[0:1, :, list].shape) # (1, 3, 5), as expected This behavior carries over to 4D arrays as well, where the axis sliced with a list becomes the 0th axis regardless of order. Below demonstrates that. arr2 = np.arange(324).reshape(2, 3, 6, 9) print(arr2[0, :, :, list].shape) # (5, 3, 6), but I expect (3, 6, 5) arr3 = np.arange(324).reshape(2, 3, 9, 6) print(arr3[0, :, list].shape) # (5, 3, 6), expected (3, 5, 6) print(arr3[0, :, list, :].shape) # same as above Can anyone explain this behavior, or is this a bug? Best, Michael

3 3

new NEP: np.AbstractArray and np.asabstractarray
by Nathaniel Smith 22 Mar '18

22 Mar '18

Hi all, Here's a more substantive NEP: trying to define how to define a standard way for functions to say that they can accept any "duck array". Biggest open question for me: the name "asabstractarray" kinda sucks (for reasons described in the NEP), and I'd love to have something better. Any ideas? Rendered version: https://github.com/njsmith/numpy/blob/nep-16-abstract-array/doc/neps/nep-00… -n ---- ==================================================== An abstract base class for identifying "duck arrays" ==================================================== :Author: Nathaniel J. Smith <njs(a)pobox.com> :Status: Draft :Type: Standards Track :Created: 2018-03-06 Abstract -------- We propose to add an abstract base class ``AbstractArray`` so that third-party classes can declare their ability to "quack like" an ``ndarray``, and an ``asabstractarray`` function that performs similarly to ``asarray`` except that it passes through ``AbstractArray`` instances unchanged. Detailed description -------------------- Many functions, in NumPy and in third-party packages, start with some code like:: def myfunc(a, b): a = np.asarray(a) b = np.asarray(b) ... This ensures that ``a`` and ``b`` are ``np.ndarray`` objects, so ``myfunc`` can carry on assuming that they'll act like ndarrays both semantically (at the Python level), and also in terms of how they're stored in memory (at the C level). But many of these functions only work with arrays at the Python level, which means that they don't actually need ``ndarray`` objects *per se*: they could work just as well with any Python object that "quacks like" an ndarray, such as sparse arrays, dask's lazy arrays, or xarray's labeled arrays. However, currently, there's no way for these libraries to express that their objects can quack like an ndarray, and there's no way for functions like ``myfunc`` to express that they'd be happy with anything that quacks like an ndarray. The purpose of this NEP is to provide those two features. Sometimes people suggest using ``np.asanyarray`` for this purpose, but unfortunately its semantics are exactly backwards: it guarantees that the object it returns uses the same memory layout as an ``ndarray``, but tells you nothing at all about its semantics, which makes it essentially impossible to use safely in practice. Indeed, the two ``ndarray`` subclasses distributed with NumPy – ``np.matrix`` and ``np.ma.masked_array`` – do have incompatible semantics, and if they were passed to a function like ``myfunc`` that doesn't check for them as a special-case, then it may silently return incorrect results. Declaring that an object can quack like an array ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There are two basic approaches we could use for checking whether an object quacks like an array. We could check for a special attribute on the class:: def quacks_like_array(obj): return bool(getattr(type(obj), "__quacks_like_array__", False)) Or, we could define an `abstract base class (ABC) <https://docs.python.org/3/library/collections.abc.html>`__:: def quacks_like_array(obj): return isinstance(obj, AbstractArray) If you look at how ABCs work, this is essentially equivalent to keeping a global set of types that have been declared to implement the ``AbstractArray`` interface, and then checking it for membership. Between these, the ABC approach seems to have a number of advantages: * It's Python's standard, "one obvious way" of doing this. * ABCs can be introspected (e.g. ``help(np.AbstractArray)`` does something useful). * ABCs can provide useful mixin methods. * ABCs integrate with other features like mypy type-checking, ``functools.singledispatch``, etc. One obvious thing to check is whether this choice affects speed. Using the attached benchmark script on a CPython 3.7 prerelease (revision c4d77a661138d, self-compiled, no PGO), on a Thinkpad T450s running Linux, we find:: np.asarray(ndarray_obj) 330 ns np.asarray([]) 1400 ns Attribute check, success 80 ns Attribute check, failure 80 ns ABC, success via subclass 340 ns ABC, success via register() 700 ns ABC, failure 370 ns Notes: * The first two lines are included to put the other lines in context. * This used 3.7 because both ``getattr`` and ABCs are receiving substantial optimizations in this release, and it's more representative of the long-term future of Python. (Failed ``getattr`` doesn't necessarily construct an exception object anymore, and ABCs were reimplemented in C.) * The "success" lines refer to cases where ``quacks_like_array`` would return True. The "failure" lines are cases where it would return False. * The first measurement for ABCs is subclasses defined like:: class MyArray(AbstractArray): ... The second is for subclasses defined like:: class MyArray: ... AbstractArray.register(MyArray) I don't know why there's such a large difference between these. In practice, either way we'd only do the full test after first checking for well-known types like ``ndarray``, ``list``, etc. `This is how NumPy currently checks for other double-underscore attributes <https://github.com/numpy/numpy/blob/master/numpy/core/src/private/get_attr_…>`__ and the same idea applies here to either approach. So these numbers won't affect the common case, just the case where we actually have an ``AbstractArray``, or else another third-party object that will end up going through ``__array__`` or ``__array_interface__`` or end up as an object array. So in summary, using an ABC will be slightly slower than using an attribute, but this doesn't affect the most common paths, and the magnitude of slowdown is fairly small (~250 ns on an operation that already takes longer than that). Furthermore, we can potentially optimize this further (e.g. by keeping a tiny LRU cache of types that are known to be AbstractArray subclasses, on the assumption that most code will only use one or two of these types at a time), and it's very unclear that this even matters – if the speed of ``asarray`` no-op pass-throughs were a bottleneck that showed up in profiles, then probably we would have made them faster already! (It would be trivial to fast-path this, but we don't.) Given the semantic and usability advantages of ABCs, this seems like an acceptable trade-off. .. CPython 3.6 (from Debian):: Attribute check, success 110 ns Attribute check, failure 370 ns ABC, success via subclass 690 ns ABC, success via register() 690 ns ABC, failure 1220 ns Specification of ``asabstractarray`` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Given ``AbstractArray``, the definition of ``asabstractarray`` is simple:: def asabstractarray(a, dtype=None): if isinstance(a, AbstractArray): if dtype is not None and dtype != a.dtype: return a.astype(dtype) return a return asarray(a, dtype=dtype) Things to note: * ``asarray`` also accepts an ``order=`` argument, but we don't include that here because it's about details of memory representation, and the whole point of this function is that you use it to declare that you don't care about details of memory representation. * Using the ``astype`` method allows the ``a`` object to decide how to implement casting for its particular type. * For strict compatibility with ``asarray``, we skip calling ``astype`` when the dtype is already correct. Compare:: >>> a = np.arange(10) # astype() always returns a view: >>> a.astype(a.dtype) is a False # asarray() returns the original object if possible: >>> np.asarray(a, dtype=a.dtype) is a True What exactly are you promising if you inherit from ``AbstractArray``? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This will presumably be refined over time. The ideal of course is that your class should be indistinguishable from a real ``ndarray``, but nothing enforces that except the expectations of users. In practice, declaring that your class implements the ``AbstractArray`` interface simply means that it will start passing through ``asabstractarray``, and so by subclassing it you're saying that if some code works for ``ndarray``\s but breaks for your class, then you're willing to accept bug reports on that. To start with, we should declare ``__array_ufunc__`` to be an abstract method, and add the ``NDArrayOperatorsMixin`` methods as mixin methods. Declaring ``astype`` as an ``@abstractmethod`` probably makes sense as well, since it's used by ``asabstractarray``. We might also want to go ahead and add some basic attributes like ``ndim``, ``shape``, ``dtype``. Adding new abstract methods will be a bit trick, because ABCs enforce these at subclass time; therefore, simply adding a new `@abstractmethod` will be a backwards compatibility break. If this becomes a problem then we can use some hacks to implement an `@upcoming_abstractmethod` decorator that only issues a warning if the method is missing, and treat it like a regular deprecation cycle. (In this case, the thing we'd be deprecating is "support for abstract arrays that are missing feature X".) Naming ~~~~~~ The name of the ABC doesn't matter too much, because it will only be referenced rarely and in relatively specialized situations. The name of the function matters a lot, because most existing instances of ``asarray`` should be replaced by this, and in the future it's what everyone should be reaching for by default unless they have a specific reason to use ``asarray`` instead. This suggests that its name really should be *shorter* and *more memorable* than ``asarray``... which is difficult. I've used ``asabstractarray`` in this draft, but I'm not really happy with it, because it's too long and people are unlikely to start using it by habit without endless exhortations. One option would be to actually change ``asarray``\'s semantics so that *it* passes through ``AbstractArray`` objects unchanged. But I'm worried that there may be a lot of code out there that calls ``asarray`` and then passes the result into some C function that doesn't do any further type checking (because it knows that its caller has already used ``asarray``). If we allow ``asarray`` to return ``AbstractArray`` objects, and then someone calls one of these C wrappers and passes it an ``AbstractArray`` object like a sparse array, then they'll get a segfault. Right now, in the same situation, ``asarray`` will instead invoke the object's ``__array__`` method, or use the buffer interface to make a view, or pass through an array with object dtype, or raise an error, or similar. Probably none of these outcomes are actually desireable in most cases, so maybe making it a segfault instead would be OK? But it's dangerous given that we don't know how common such code is. OTOH, if we were starting from scratch then this would probably be the ideal solution. We can't use ``asanyarray`` or ``array``, since those are already taken. Any other ideas? ``np.cast``, ``np.coerce``? Implementation -------------- 1. Rename ``NDArrayOperatorsMixin`` to ``AbstractArray`` (leaving behind an alias for backwards compatibility) and make it an ABC. 2. Add ``asabstractarray`` (or whatever we end up calling it), and probably a C API equivalent. 3. Begin migrating NumPy internal functions to using ``asabstractarray`` where appropriate. Backward compatibility ---------------------- This is purely a new feature, so there are no compatibility issues. (Unless we decide to change the semantics of ``asarray`` itself.) Rejected alternatives --------------------- One suggestion that has come up is to define multiple abstract classes for different subsets of the array interface. Nothing in this proposal stops either NumPy or third-parties from doing this in the future, but it's very difficult to guess ahead of time which subsets would be useful. Also, "the full ndarray interface" is something that existing libraries are written to expect (because they work with actual ndarrays) and test (because they test with actual ndarrays), so it's by far the easiest place to start. Links to discussion ------------------- TBD Appendix: Benchmark script -------------------------- .. literal-include:: nep-0016-benchmark.py Copyright --------- This document has been placed in the public domain. -n -- Nathaniel J. Smith -- https://vorpus.org

11 22

NEP sprint: 21 and 22 March
by Stefan van der Walt 20 Mar '18

20 Mar '18

Hi everyone, As you may have noticed, there's been quite a bit of movement recently around NumPy Enhancement Proposals---on setting specifications, building infrastructure, as well as writing new proposals. To further support this work, we will be hosting an informal NEP sprint at Berkeley on 21 and 22 March. Our aim is to bring core contributors and interested community members together to discuss proposal ideas, write up new NEPs, and polish existing ones. Some potential topics of discussion are: - Duck arrays - Array concatenation - Random number generator seed versioning - User defined dtypes - Deprecation pathways for `np.matrix` - What to do about nditer? All community members are welcome to attend. If you are a core contributor, we may be able to fund some travel costs as well; please let me know. Best regards Stéfan

4 4

PR to add a function to calculate histogram edges without calculating the histogram
by Kirit Thadaka 16 Mar '18

16 Mar '18

Hi! I've created a PR to add a function called "histogram_bin_edges" which will allow a user to calculate the bins used by the histogram for some data without requiring the entire histogram to be calculated. https://github.com/numpy/numpy/pull/10591#issuecomment-371863472 This function allows one set of bins to be computed, and reused across multiple histograms which gives more easily comparable results than using separate bins for each histogram. Please let me know if you have any suggestions on how to improve this PR. Thanks! - Kirit

5 10

NumPy 1.15 release schedule
by Charles R Harris 16 Mar '18

16 Mar '18

Hi All, I'm thinking of branching NumPy in the middle/end of April. That is quicker than usual, but there don't seem to be any major changes proposed for the near future, we have merged a reasonable number of PRs, and a Python 3.7 compatible release of Cython looks to be forthcoming. An early release will also give us time for possibly two following releases before we drop Python 2.7 support. With that schedule, I also propose to drop Python 3.4 support in NumPy 1.16. Thoughts? Chuck

2 1

ENH: softmax
by Kulick, Johannes 15 Mar '18

15 Mar '18

Hi, I regularly need the softmax function (https://en.wikipedia.org/wiki/Softmax_function) for my code. I have a quite efficient pure python implementation (credits to Nolan Conaway). I think it would be a valuable enhancement of the ndarray class. But since it is kind of a specialty function I wanted to ask you if you would consider it to be part of the numpy core (alongside ndarray.max and ndarray.argmax) or rather in scipy (e.g. scipy.stats seems also an appropriate place). Best Johannes Amazon Development Center Germany GmbH Berlin - Dresden - Aachen main office: Krausenstr. 38, 10117 Berlin Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger Ust-ID: DE289237879 Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

6 7