[Numpy-discussion] Re: Dealing with static local variables in Numpy

On Tue, 2023-08-29 at 08:01 +, Nicolas Holzschuch wrote: > Hello, > > This is my first post to this group; I'd like to start by expressing > my appreciation for the amazing work in developing and maintaining > Numpy. > > I have a question. Numpy has quite a lot of static local variables  > (

[Numpy-discussion] Re: Curious performance different with np.unique on arrays of characters

On Fri, 2023-09-29 at 11:39 +0200, Klaus Zimmermann wrote: > Hi, > > one thing that's been on my mind about this discussion: > > Isn't sorting strings simply a much harder job? Particularly Unicode > strings? Yes, but in theory if they are length 1 it is just sorting integers (8 or 64bit) for

[Numpy-discussion] Merging very limited weights support for quantiles/percentiles

Hi all, there is a PR to merge very limited support for weights in quantiles, which given no further input I will probably merge based on sklearn devs saying that they will use it. This means, adding a `weights` kwarg [1]. See: https://github.com/numpy/numpy/pull/24254 Limited here means th

[Numpy-discussion] Windows default integer now 64bit in main

Hi all, just a heads up, the PR to change the default integer is merged on main. This may cause issues, especially with Cython code because `np.int_t` cannot be reasonably defined anymore. Other code may also want to vet usage of "long" in any variation. Much code (like SciPy) simply supports a

[Numpy-discussion] Re: Windows default integer now 64bit in main

e. There is no 1.27 planned as of now, if it happens it would be a (big) backport release, though. (Due to files having been moved around backports seem to be getting harder, though.) - Sebastian > > Best, Michael > > > On 2. Nov 2023, at 16:25, Sebastian Berg < > > seb

[Numpy-discussion] Re: Switching default order to column-major

Few things in the Python API care about order, but there are also quite a few places that will return C-order (and are faster for C-order inputs) whether you change those defaults or not. The main issue is that e.g. some cython wrappers will probably assume that the newly created array is C-order.

[Numpy-discussion] Re: Fixing definition of reduceat for Numpy 2.0?

On Fri, 2023-12-22 at 18:01 -0500, Marten van Kerkwijk wrote: > Hi Martin, > > I agree it is a long-standing issue, and I was reminded of it by your > comment.  I have a draft PR at > https://github.com/numpy/numpy/pull/25476 > that does not change the old behaviour, but allows you to pass in a >

[Numpy-discussion] Re: Fixing definition of reduceat for Numpy 2.0?

On Sat, 2023-12-23 at 09:56 -0500, Marten van Kerkwijk wrote: > Hi Sebastian, > > > That looks nice, I don't have a clear feeling on the order of > > items, if > > we think of it in terms of `(start, stop)` there was also the idea > > voiced to simply add another name in which case you would allow

[Numpy-discussion] Re: Fixing definition of reduceat for Numpy 2.0?

On Sat, 2023-12-23 at 09:56 -0500, Marten van Kerkwijk wrote: > Hi Sebastian, > > > That looks nice, I don't have a clear feeling on the order of > > items, if > > we think of it in terms of `(start, stop)` there was also the idea > > voiced to simply add another name in which case you would allow

[Numpy-discussion] Re: Proposal to accept NEP 55: Add a UTF-8 variable-width string DType to NumPy

On Mon, 2024-01-22 at 17:08 -0700, Nathan wrote: > Hi all, > > I propose we accept NEP 55 and merge PR #25347 implementing the NEP > in time > for the NumPy 2.0 RC: I really like this work and I think it is a big improvement! At this point we probably have to expect some things to be still bugg

[Numpy-discussion] Re: Automatic Clipping of array to upper / lower bounds of dtype

On Mon, 2024-03-25 at 13:49 +, percynichols...@gmail.com wrote: > Many thanks! > > Just one more inquiry along those lines, if I may. The code asserts > that clip should outpace np.maximum(mp.minumum(arr, max), min). > Despite this: > *time a = np.arange(100)it.clip(4, 20)    # 8.48 µs > %time

[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0

On Mon, 2024-05-06 at 09:17 +1000, Matti Picus wrote: > On 05/05/2024 11:32, Mark Harfouche wrote: > > > > > Thank you for considering this last minute request. I know it adds > > work at this stage. > > > > Mark > > > I think NumPy should not be the leader in dropping versions, rather > sh

[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0

On Tue, 2024-05-07 at 15:46 +1000, Juan Nunez-Iglesias wrote: > On Tue, 7 May 2024, at 7:04 AM, Ralf Gommers wrote: > > This problem could have been avoided by proper use of upper bounds. > > Scikit-image 0.22 not including a `numpy<2.0` upper bound is a bug > > in scikit-image (definitely for ABI

[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0

On Tue, 2024-05-07 at 11:41 +0200, Gael Varoquaux wrote: > On Tue, May 07, 2024 at 11:31:02AM +0200, Ralf Gommers wrote: > > make `pip install scikit-image==0.22` work if that version of > > scikit-image depends on an unconstrained numpy version. > > Would an option be for the scikit-image maintai

[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0

On Mon, 2024-05-06 at 22:39 +, Henry Schreiner wrote: > This will be messier for projects building wheels and wanting to > support non-EoL Python versions. To build a wheel with anything other > than pybind11, you now need the oldest supported NumPy for Python < > 3.9, the latest NumPy 1 for Py

[Numpy-discussion] Re: Unexpected return values for np.mod with x2=np.inf and similar

On Mon, 2024-06-10 at 10:49 +0300, Matti Picus wrote: > What operating system? > > > If I recall correctly, NumPy tries to be compatible with CPython for > these edge cases. > Right, and there seems nothing odd here to me. Try using `divmod()` on a few numbers (not infinities) to realize that

[Numpy-discussion] Re: Mysterious issue to build pyFFTW with Numpy 2.0 on Windows

The most probably change seems to me that NumPy now includes `complex.h`. But not sure that is the right direction or why it would lead to cryptic errors. - Sebastian On Wed, 2024-07-03 at 10:30 +0200, PIERRE AUGIER wrote: > Hi, > > We have a strange issue with building pyFFTW with Numpy 2.0

[Numpy-discussion] Re: Enhancement for generalized ufuncs

On Thu, 2024-07-11 at 19:31 -0400, Warren Weckesser wrote: > I have implemented quite a few generalized ufuncs over in ufunclab > (https://github.com/WarrenWeckesser/ufunclab), and in the process I > have accumulated a gufunc "wish list". Two items on that list are: > > (1) the ability to impose c

[Numpy-discussion] Re: Enhancement for generalized ufuncs

On Fri, 2024-07-12 at 09:56 -0400, Warren Weckesser wrote: > On Fri, Jul 12, 2024 at 7:47 AM Sebastian Berg > wrote: > > > > > (You won't be able to know these relations from reading the > > signature, > > but I doubt it's worth worrying about

[Numpy-discussion] Welcome Joren Hammudoglu to the NumPy Maintainers Team

Hi all, please join me in welcoming Joren (https://github.com/jorenham) to the NumPy maintainers team. Joren has done a lot of work recently contributing, reviewing, and maintaining typing related improvements to NumPy. We are looking forward to see new momentum to improve NumPy typing. Thanks f

[Numpy-discussion] Re: ENH: Uniform interface for accessing minimum or maximum value of a dtype

On Mon, 2024-08-26 at 11:26 -0400, Marten van Kerkwijk wrote: > I think a NEP is a good idea.  It would also seem to make sense to > consider how the dtype itself can hold/calculate this type of > information, since that will be the only way a generic ``info()`` > function can get information for a

Re: [Numpy-discussion] Optimize evaluation of function on matrix

On Sat, 2017-03-25 at 18:46 +0100, Florian Lindner wrote: > Hello, > > I have this function: > > def eval_BF(self, meshA, meshB): > """ Evaluates single BF or list of BFs on the meshes. """ > if type(self.basisfunction) is list: > A = np.empty((len(meshA), len(meshB)))

[Numpy-discussion] heads up: gufuncs on empty arrays and NpyIter removal of empty axis

Hi all, just a small heads up for gufunc hackers and low level iterator users. We will probably very soon put in a commit into master that will allow the removal of empty axis from NpyIter/nditer, effectively removing the error: "ValueError: cannot remove a zero-sized axis from an iterator" and

Re: [Numpy-discussion] Optimize evaluation of function on matrix

in enumerate(meshB): # possibly insert np.newaxis/None or a reshape in [??]     A[:, j] = self.basisfunction[j](meshA[??] - col) - Sebastian > > Best, > Florian > > Am 25.03.2017 um 22:31 schrieb Sebastian Berg: > > On Sat, 2017-03-25 at 18:46 +0100, Florian Lindner wro

Re: [Numpy-discussion] Fwd: SciPy2017 Sprints FinAid for sprint leaders/core devs

On Thu, 2017-03-30 at 22:46 +1300, Ralf Gommers wrote: > > > Agreed, and I would call that productive. Getting even one new > maintainer involved is worth organizing multiple sprints for. > > That said, also +1 to a developer meeting this year. It'd be good if > we could combine it with the Num

Re: [Numpy-discussion] proposal: smaller representation of string arrays

On Wed, 2017-04-26 at 19:43 +0200, Julian Taylor wrote: > On 26.04.2017 19:08, Robert Kern wrote: > > On Wed, Apr 26, 2017 at 2:15 AM, Julian Taylor > > mailto:jtaylor.deb...@googlemail.co > > m>> > > wrote: > > > > > Indeed, > > > Most of this discussion is irrelevant to numpy. > > > Numpy only r

Re: [Numpy-discussion] [SciPy-User] NumPy v1.13.0rc1 released.

gt; > Jonathan Tammo Siebert + > > Joseph Fox-Rabinovitz > > Joshua Loyal + > > Juan Nunez-Iglesias + > > Julian Taylor > > Kirill Balunov + > > Likhith Chitneni + > > Loïc Estève > > Mads Ohm Larsen > > Marein Könings + > > Marten van Kerkwijk

Re: [Numpy-discussion] failed to add routine to the core module

On Thu, 2017-05-18 at 15:04 +0200, marc wrote: > Dear Numpy developers, > I'm trying to add a routine to calculate the sum of a product of two > arrays (a dot product). But that would not increase the memory (from > what I saw np.dot is increasing the memory while it should not be > necessary). The

Re: [Numpy-discussion] UC Berkeley hiring developers to work on NumPy

On Mon, 2017-05-22 at 17:35 +0100, Matthew Brett wrote: > Hi, > > On Mon, May 22, 2017 at 4:52 PM, Marten van Kerkwijk > wrote: > > Hi Matthew, > > > > > it seems to me that we could get 80% of the way to a reassuring > > > blueprint with a relatively small amount of effort. > > > > My sentence

Re: [Numpy-discussion] Future of ufuncs

On Sun, 2017-05-28 at 14:53 -0600, Charles R Harris wrote: > Hi All, > This post is to open a discussion of the future of ufuncs. There are > two contradictory ideas that have floated about regarding ufuncs > evolution. One is to generalize ufuncs to operate on buffers, > essentially separating the

Re: [Numpy-discussion] np.diff on boolean arrays now raises

On Thu, 2017-06-15 at 22:35 +1200, Ralf Gommers wrote: > > > On Thu, Jun 15, 2017 at 7:08 PM, Jaime Fernández del Río gmail.com> wrote: > > There is an ongoing discussion on github: > > > > https://github.com/numpy/numpy/issues/9251 > > > > In 1.13 np.diff has started raising on boolean arrays

Re: [Numpy-discussion] [SciPy-Dev] PyRSB: Python interface to librsb sparse matrices library

On Sat, 2017-06-24 at 15:47 -0400, josef.p...@gmail.com wrote: > > > On Sat, Jun 24, 2017 at 3:16 PM, Nathaniel Smith > wrote: > > On Jun 24, 2017 7:29 AM, "Sylvain Corlay" > > wrote: > > > > Also, one quick question: is the LGPL license a deliberate choice > > or is it not important to you? M

Re: [Numpy-discussion] [SciPy-Dev] PyRSB: Python interface to librsb sparse matrices library

ency (i.e. `import package`). - Sebastian > Carl > > 2017-06-24 22:07 GMT+02:00 Sebastian Berg >: > > On Sat, 2017-06-24 at 15:47 -0400, josef.p...@gmail.com wrote: > > > > > > > > > On Sat, Jun 24, 2017 at 3:16 PM, Nathaniel Smith > > > w

Re: [Numpy-discussion] Boolean binary '-' operator

On Sun, 2017-06-25 at 18:59 +0200, Julian Taylor wrote: > On 25.06.2017 18:45, Stefan van der Walt wrote: > > Hi Chuck > > > > On Sun, Jun 25, 2017, at 09:32, Charles R Harris wrote: > > > The boolean binary '-' operator was deprecated back in NumPy 1.9 > > > and > > > changed to an error in 1.13.

Re: [Numpy-discussion] why a[0][0].__mul__(a[0][0]) where a is np.array, gives 'missing 1 required positional argument'?

On Tue, 2017-06-27 at 04:54 -0500, Larry Evans wrote: > The following code: > > --{--cut here-- > #Purpose: > #  Demonstrate class with __add__ and __mult__ methods > #  to demonstrate shortestPath calculations. > #OriginalSource: > #  ./shortestPath.py > #References: > #  [1]  > http://www.marina

Re: [Numpy-discussion] Array blitting (pasting one array into another)

On Fri, 2017-06-30 at 02:16 +0200, Mikhail V wrote: > Hello all > > I often need to copy one array into another array, given an offset. > This is how the "blit" function can be understood, i.e. in > every graphical lib there is such a function. > The common definition is like: > blit ( dest, src,

Re: [Numpy-discussion] proposed changes to array printing in 1.14

On Fri, 2017-06-30 at 17:55 +1000, Juan Nunez-Iglesias wrote: > To reiterate my point on a previous thread, I don't think this should > happen until NumPy 2.0. This *will* break a massive number of > doctests, and what's worse, it will do so in a way that makes it > difficult to support doctesting

Re: [Numpy-discussion] Scipy 2017 NumPy sprint

On Sun, 2017-07-02 at 10:49 -0400, Allan Haldane wrote: > On 07/02/2017 10:03 AM, Charles R Harris wrote: > > Updated list below. > > > > On Sat, Jul 1, 2017 at 7:08 PM, Benjamin Root >   > > > wrote: > > > > Just a heads-up. There is now a sphinx-gallery plugin.

Re: [Numpy-discussion] reshape 2D array into 3D

On Mon, 2017-07-10 at 16:16 +0300, eat wrote: > Hi, > > On Mon, Jul 10, 2017 at 3:20 PM, wrote: > > Dear All > > I'm looking in a way to reshape a 2D matrix into a 3D one ; in my > > example I want to move the columns from the 4th to the 8th in the > > 2nd plane  (3rd dimension i guess) > > a =  

Re: [Numpy-discussion] pytest and degrees of separation.

On Tue, 2017-07-11 at 14:49 -0600, Charles R Harris wrote: > Hi All, > > Just looking for opinions and feedback on the need to keep NumPy from > having a hard nose/pytest dependency. The options as I see them are: > > pytest is never imported until the tests are run -- current practice > with nos

Re: [Numpy-discussion] How to compare an array of arrays elementwise to None in Numpy 1.13 (was easy before)?

On Mon, 2017-07-17 at 09:13 +, martin.gfel...@swisscom.com wrote: > Dear all > > I have object array of arrays, which I compare element-wise to None > in various places: > > > > > a = > > > > numpy.array([numpy.arange(5),None,numpy.nan,numpy.arange(6),Non > > > > e],dtype=numpy.object) > > >

Re: [Numpy-discussion] How to compare an array of arrays elementwise to None in

; understanding by code maintainers.  > > Thanks again, and best regards, > Martin > > > > > On Mon, 17 Jul 2017 11:41 Sebastian Berg > write > > > Yes, I guess ones bug is someone elses feature :(, if it is very > > bad, we could delay the deprecation p

Re: [Numpy-discussion] NumPy steering councils members

On Fri, 2017-07-21 at 16:58 +0200, Julian Taylor wrote: > On 21.07.2017 08:52, Ralf Gommers wrote: > > Hi all, > > > > It has been well over a year since we put together the governance > > structure and steering council > > (https://docs.scipy.org/doc/numpy-dev/dev/governance/people.html#go > > ve

Re: [Numpy-discussion] NumPy steering councils members

On Fri, 2017-07-21 at 12:59 -0700, Nathaniel Smith wrote: > On Jul 21, 2017 9:36 AM, "Sebastian Berg" > wrote: > On Fri, 2017-07-21 at 16:58 +0200, Julian Taylor wrote: > > On 21.07.2017 08:52, Ralf Gommers wrote: > Also FWIW, the jupyter steering council i

Re: [Numpy-discussion] Slice nested arrays, How to

On Mon, 2017-07-24 at 16:37 +0200, Bob wrote: > Hello, > > I created the following array by converting it from a nested list: > > a = np.array([np.array([ > 17.56578416,  16.82712825,  16.57992292,  > 15.83534836]), >    np.array([ 17.9002445 > ,  17.35024876,  16.69733472,  15.78809856])

Re: [Numpy-discussion] NumPy steering councils members

the governance docs say). Regards, Sebastian [1] Two of whom may be appointed with some delay due to the one year rule. We may have to hash out details here. On Fri, 2017-07-21 at 22:18 +0200, Sebastian Berg wrote: > On Fri, 2017-07-21 at 12:59 -0700, Nathaniel Smith wrote: > >

Re: [Numpy-discussion] np.array, copy=False and memmap

On Thu, 2017-08-10 at 12:27 -0400, Allan Haldane wrote: > On 08/07/2017 05:01 PM, Nisoli Isaia wrote: > > Dear all, > > I have a question about the behaviour of > > > > y = np.array(x, copy=False, dtype='float32') > > > > when x is a memmap. If we check the memmap attribute of mmap > > > > print

Re: [Numpy-discussion] Tensor Contraction (HPTT) and Tensor Transposition (TCL)

On Thu, 2017-08-17 at 00:33 +0200, Paul Springer wrote: > Am 8/16/17 um 6:08 PM schrieb Anne Archibald: > > > If you wanted to integrate HPTT into numpy, I think the best > > approach might be to wire it into the assignment machinery, so that > > when users do things like a[::2,:] = b[:,::3].T H

[Numpy-discussion] Github overview change

Hi all, probably silly, but is anyone else annoyed at not seeing comments anymore in the github overview/start page? I stopped getting everything as mails and had a (bad) habit of glancing at them which would spot at least bigger discussions going on, but now it only shows actual commits, which ho

Re: [Numpy-discussion] Github overview change

nt ;). - Sebastian > On Wed, Oct 18, 2017 at 11:49 AM Charles R Harris > wrote: > > On Wed, Oct 18, 2017 at 7:23 AM, Sebastian Berg > ions.net> wrote: > > > Hi all, > > > > > > probably silly, but is anyone else annoyed at not seeing comments >

Re: [Numpy-discussion] Proposal of timeline for dropping Python 2.7 support

On Wed, 2017-11-08 at 18:15 +0100, Ilhan Polat wrote: > I was about to send the same thing. I think this matter became a > vim/emacs issue and Py2 supporters won't take any arguments anymore. > But if Instagram can do it, it means that legacy code argument is a > matter of will but not a technicali

Re: [Numpy-discussion] Is there a way that indexing a matrix of data with a matrix of indices?

On Wed, 2017-11-29 at 14:56 +, ZHUO QL (KDr2) wrote: > Hi, all > > suppose: > > - D, is the data matrix, its shape is  M x N > - I, is the indices matrix, its shape is M x K,  K<=N > > Is there a efficient way to get a Matrix R with the same shape of I > so that R[x,y] = D[x, I[x,y]] ? > >

Re: [Numpy-discussion] Which rule makes x[np.newaxis, :] and x[np.newaxis] equivalent?

On Tue, 2017-12-12 at 14:19 +0100, Joe wrote: > Ah, ok, now that I knew what to look for I guess I found it: > > "If the number of objects in the selection tuple is less than N , > then :  > is assumed for any subsequent dimensions." > > https://docs.scipy.org/doc/numpy-1.13.0/reference/arrays.in

Re: [Numpy-discussion] Does x[True] trigger basic or advanced indexing?

On Thu, 2017-12-14 at 16:24 +, Eric Wieser wrote: > It sounds like you're using an old version of numpy, where boolean > scalars were interpreted as integers. > What version are you using? > Eric > Indeed, you are maybe using a pre 1.9 version (post 1.9 should at least have a DeprecationWarni

Re: [Numpy-discussion] Applying logical operations along an axis of a boolean array?

On Mon, 2017-12-18 at 12:02 +0100, hanno_li...@gmx.net wrote: > Hi, >   > is it possible, to apply a logical operation, such as AND or OR along > a particular axis of a numpy array? > As mentioned, `np.any` and `np.all` work. However, what is more/also interesting to you is maybe that: `np.logic

Re: [Numpy-discussion] GSoC'18 participation

On Tue, 2017-12-26 at 08:19 -0700, Charles R Harris wrote: > > > On Mon, Dec 25, 2017 at 7:12 PM, Ralf Gommers > wrote: > > Hi all, > > > > It's the time of the year again where projects start preparing for > > GSoC. So I wanted to bring it up here. Last year I wrote: "in > > practice working o

Re: [Numpy-discussion] array - dimension size of 1-D and 2-D examples

On Tue, 2018-01-09 at 12:27 +, martin.gfel...@swisscom.com wrote: > Hi Derek > > I have a related question: > > Given: > > a = numpy.array([[0,1,2],[3,4]]) > assert a.ndim == 1 > b = numpy.array([[0,1,2],[3,4,5]]) > assert b.ndim == 2 > > Is there an elegant way to

Re: [Numpy-discussion] NumPy 1.14.0 release

On Sun, 2018-01-14 at 11:35 +, Matthew Brett wrote: > Hi, > > On Sun, Jan 14, 2018 at 3:35 AM, Eric Wieser > wrote: > > Did recarrays change? I didn’t see anything in the release notes. > > > > Not directly, but structured arrays did, for which recarrays are > > really just > > a thin and so

Re: [Numpy-discussion] NumPy 1.14.1 released

lable on github. > > Contributors > > A total of 14 people contributed to this release. People with a "+" > by their names contributed a patch for the first time. > > * Allan Haldane > * Charles Harris > * Daniel Smith > * Dennis Weyland + > * Eric Larson

Re: [Numpy-discussion] improving arange()? introducing fma()?

On Thu, 2018-02-22 at 14:33 -0500, Benjamin Root wrote: > Sorry, I have been distracted with xarray improvements the past > couple of weeks. > > Some thoughts on what has been discussed: > > First, you are right...Decimal is not the right module for this. I > think instead I should use the 'fract

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

On Thu, 2018-03-08 at 18:56 +, Stephan Hoyer wrote: > Hi Nathaniel, > > Thanks for starting the discussion! > > Like Marten says, I think it would be useful to more clearly define > what it means to be an abstract array. ndarray has lots of > methods/properties that expose internal implementa

Re: [Numpy-discussion] 3D array slicing bug?

This NEP draft has some more hints/explanations if you are interested: https://github.com/seberg/numpy/blob/5becd12914d0402967205579d6f59a9815 1e0d98/doc/neps/indexing.rst#examples Plus, it tries to avoid the word "subspace" hehehe. - Sebastian On Thu, 2018-03-22 at 10:41 +0100, Pauli Virtanen

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

Initializer or this sounds fine to me. As an other data point which I think has been mentioned before, `sum` uses start and min/max use default. `start` does not work, unless we also change the code to always use the identity if given (currently that is not the case), in which case it might be nice

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

> > This was the reason to call it initializer in the first place. I like > `initial` and `initial_value` as well, and `start` also makes sense > but isn’t descriptive enough. > > Hameer > Sent from Astro for Mac > > > On Mar 26, 2018 at 12:06, Sebastian Berg > t&g

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

ed a huge hullabeloo a few > years ago when we changed it from returning NaN to returning zero. > Ben > Root On Mon, Mar 26, 2018 at 11:16 AM, Sebastian Berg > wrote: OK, the new documentation is > actually clear: initializer : scalar, optional The value with which &g

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

5, Benjamin wrote: Hmm, > this is neat. I imagine it would finally give some people a choice on > what np.nansum([np.nan]) should return? It caused a huge hullabeloo a > few years ago when we changed it from returning NaN to returning > zero. > Ben Root On Mon, Mar 26, 2018 at

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

On Mon, 2018-03-26 at 18:48 +0200, Sebastian Berg wrote: > On Mon, 2018-03-26 at 11:53 -0400, Hameer Abbasi wrote: > > It'll need to be thought out for object arrays and subclasses. But > > for > > Regular numeric stuff, Numpy uses fmin and this would have the > > d

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

e note, but I see your emails as a single block of text with no/broken new-lines. > On 26/03/2018 at 18:54, > Sebastian wrote: On Mon, 2018-03-26 at 18:48 +0200, Sebastian Berg > wrote: On Mon, 2018-03-26 at 11:53 -0400, Hameer Abbasi wrote: It'll > need to be thought out for obj

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

. - Sebastian > > On Mon, 26 Mar 2018 at 10:10 Sebastian Berg et> wrote: > > On Mon, 2018-03-26 at 12:59 -0400, Hameer Abbasi wrote: > > > That may be complicated. Currently, the identity isn't used in > > object > > > dtype reductions. We may ne

Re: [Numpy-discussion] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

d the object case important, if someone seriously argues the opposite I might be swayed possibly. - Sebastian > > Hameer > > On Mon, Mar 26, 2018 at 8:09 PM, Sebastian Berg ns.net> wrote: > > On Mon, 2018-03-26 at 17:40 +, Eric Wieser wrote: > > > The difficulty i

Re: [Numpy-discussion] Introduction: NumPy developers at BIDS

On Tue, 2018-04-10 at 12:29 +0300, Matti Picus wrote: > On 08/04/18 21:02, Eric Firing wrote: > > On 2018/04/07 9:19 PM, Stefan van der Walt wrote: > > > We would love community input on identifying the best areas & > > > issues to > > > pay attention to, > > > > Stefan, > > > > What is the best

Re: [Numpy-discussion] Adding a return value to np.random.shuffle

On Thu, 2018-04-12 at 13:36 -0400, Joseph Fox-Rabinovitz wrote: > Would it break backwards compatibility to add the input as a return > value to np.random.shuffle? I doubt anyone out there is relying on > the None return value. > Well, python discourages this IIRC, and opts to not do these things

Re: [Numpy-discussion] Adding fweights and aweights to numpy.corrcoef

I seem to recall that there was a discussion on this and it was a lot trickier then expected. I think statsmodels might have options in this direction. - Sebastian On Thu, 2018-04-26 at 15:44 +, Corin Hoad wrote: > Hello, > > Would it be possible to add the fweights and aweights keyword > a

Re: [Numpy-discussion] Short-circuiting equivalent of np.any or np.all?

On Thu, 2018-04-26 at 09:51 -0700, Hameer Abbasi wrote: > Hi Nathan, > > np.any and np.all call np.or.reduce and np.and.reduce respectively, > and unfortunately the underlying function (ufunc.reduce) has no way > of detecting that the value isn’t going to change anymore. It’s also > used for (for

Re: [Numpy-discussion] Short-circuiting equivalent of np.any or np.all?

On Thu, 2018-04-26 at 19:26 +0200, Sebastian Berg wrote: > On Thu, 2018-04-26 at 09:51 -0700, Hameer Abbasi wrote: > > Hi Nathan, > > > > np.any and np.all call np.or.reduce and np.and.reduce respectively, > > and unfortunately the underlying function (ufunc.reduce)

Re: [Numpy-discussion] Splitting MaskedArray into a separate package

On Wed, 2018-05-23 at 17:33 -0400, Allan Haldane wrote: > On 05/23/2018 04:02 PM, Eric Firing wrote: > > Bad or missing values (and situations where one wants to use a mask > > to > > operate on a subset of an array) are found in many domains of real > > life; > > do you really want python users in

Re: [Numpy-discussion] Splitting MaskedArray into a separate package

On Wed, 2018-05-23 at 23:48 +0200, Sebastian Berg wrote: > On Wed, 2018-05-23 at 17:33 -0400, Allan Haldane wrote: > > If we do not plan to replace it within numpy, we need to discuss a > bit > how it might affect infrastructure (multiple implementations). > &g

Re: [Numpy-discussion] Allowing broadcasting of code dimensions in generalized ufuncs

> > > > I'm currently -0.5 on both fixed dimensions and this broadcasting > > dimension idea. My reasoning is: > > > > - The use cases seem fairly esoteric. For fixed dimensions, I guess > > the motivating example is cross-product (are there any others?). > > But > > would it be so bad for a c

Re: [Numpy-discussion] Forcing new dimensions to appear at front in advanced indexing

On Tue, 2018-06-19 at 19:37 -0400, Michael Lamparski wrote: > Hi all, > > So, in advanced indexing, numpy decides where to put new axes based > on whether the "advanced indices" are all next to each other. > > >>> np.random.random((3,4,5,6,7,8))[:, [[0,0],[0,0]], 1, :].shape > (3, 2, 2, 6, 7, 8)

Re: [Numpy-discussion] Forcing new dimensions to appear at front in advanced indexing

On Wed, 2018-06-20 at 09:15 -0400, Michael Lamparski wrote: > > There is a way that will generally work using triple indexing: > > > > arr[..., None, None][orig_indx + (slice(None), np.array(0))][..., > 0] > > Impressive! (note: I fixed the * typo in the quote) > > > The first and last indexing o

Re: [Numpy-discussion] Remove sctypeNA and typeNA from numpy core

On Thu, 2018-06-21 at 09:25 -0700, Matti Picus wrote: > numpy.core has many ways to catalogue dtype names: sctypeDict, > typeDict > (which is precisely sctypeDict), typecodes, and typename. We also > generate sctypeNA and typeNA but, as issue 11241 shows, it is > sometimes > wrong. They are also

Re: [Numpy-discussion] NEP 21: Simplified and explicit advanced indexing

On Tue, 2018-06-26 at 17:30 +1000, Andrew Nelson wrote: > On Tue, 26 Jun 2018 at 17:12, Eric Wieser m> wrote: > > > I don't think it should be relegated to the "officially > > discouraged" ghetto of `.legacy_index` > > > > The way I read it, the new spelling lof that would be the explicit > > but

Re: [Numpy-discussion] NEP 21: Simplified and explicit advanced indexing

On Tue, 2018-06-26 at 01:21 -0700, Robert Kern wrote: > On Tue, Jun 26, 2018 at 12:58 AM Sebastian Berg > wrote: > > > > Yes, that is true, but I doubt you will find a lot of code path > > that > > need the current indexing as opposed to vindex here, > &g

Re: [Numpy-discussion] NEP 21: Simplified and explicit advanced indexing

On Tue, 2018-06-26 at 04:23 -0400, Hameer Abbasi wrote: > > Boolean indices are not supported. All indices must be integers, > integer arrays or slices. > > I would hope that there’s at least some way to do boolean indexing. I > often find myself needing it. I realise that > `arr.vindex[np.nonzero

Re: [Numpy-discussion] NEP 21: Simplified and explicit advanced indexing

On Tue, 2018-06-26 at 02:27 -0700, Robert Kern wrote: > On Tue, Jun 26, 2018 at 1:36 AM Sebastian Berg s.net> wrote: > > On Tue, 2018-06-26 at 01:21 -0700, Robert Kern wrote: > > > On Tue, Jun 26, 2018 at 12:58 AM Sebastian Berg > > > wrote: > > > > &g

Re: [Numpy-discussion] NEP 21: Simplified and explicit advanced indexing

On Tue, 2018-06-26 at 04:01 -0400, Hameer Abbasi wrote: > I second this design. If we were to consider the general case of a > tuple `idx`, then we’d not be moving forward at all. Design changes > would be impossible. I’d argue that this newer model would be easier > for library maintainers overall

Re: [Numpy-discussion] NEP 21: Simplified and explicit advanced indexing

On Tue, 2018-06-26 at 22:26 -0700, Robert Kern wrote: > On Tue, Jun 26, 2018 at 10:21 PM Juan Nunez-Iglesias com> wrote: > > Let me start by thanking Robert for articulating my viewpoints far > > better than I could have done myself. I want to explicitly flag the > > following statements for endor

Re: [Numpy-discussion] update to numpy-1.5.0 gives new warnings from scipy

On Wed, 2018-07-25 at 07:44 -0400, Neal Becker wrote: > After update to numpy-1.5.0, I'm getting warnings from scipy. > These probably come from my code using convolve. Does scipy need > updating? > Probably yes, I am a bit surprised we did not notice it before if it is in scipy (or maybe scipy

Re: [Numpy-discussion] Roadmap proposal, v3

On Thu, 2018-08-02 at 05:47 -0700, Ralf Gommers wrote: > > > On Tue, Jul 24, 2018 at 12:04 PM, Stefan van der Walt ey.edu> wrote: > > Hi everyone, > > > > Please take a look at the latest roadmap proposal: > > > > https://github.com/numpy/numpy/pull/11611 > > > > This is a living document, so

Re: [Numpy-discussion] Adoption of a Code of Conduct

On Thu, 2018-08-02 at 12:04 +0200, Sylvain Corlay wrote: > The "political belief" was recently removed from the Jupyter CoC. > > One reason for this decision is that Racism and Sexism are > increasingly considered as mainstream "political beliefs", and we > wanted to make it clear that people can

Re: [Numpy-discussion] Taking back control of the #numpy irc channel

On Mon, 2018-08-06 at 21:52 -0700, Ralf Gommers wrote: > > > On Mon, Aug 6, 2018 at 7:15 PM, Nathan Goldbaum m> wrote: > > Hi, > > > > I idle in #scipy and have op in there. I’m happy start idling in > > #numpy and be op if the community is willing to let me. > > > > Thanks Nathan. Sounds use

Re: [Numpy-discussion] Taking back control of the #numpy irc channel

On Tue, 2018-08-07 at 22:07 -0700, Ralf Gommers wrote: > > > On Tue, Aug 7, 2018 at 4:34 AM, Sebastian Berg s.net> wrote: > > On Mon, 2018-08-06 at 21:52 -0700, Ralf Gommers wrote: > > > > > > > > > On Mon, Aug 6, 2018 at 7:15 PM, Natha

Re: [Numpy-discussion] Taking back control of the #numpy irc channel

On Wed, 2018-08-08 at 08:55 -0700, Ralf Gommers wrote: > > > On Wed, Aug 8, 2018 at 1:23 AM, Sebastian Berg s.net> wrote: > > On Tue, 2018-08-07 at 22:07 -0700, Ralf Gommers wrote: > > > > > > > > > On Tue, Aug 7, 2018 at 4:34 AM, Sebastian Be

Re: [Numpy-discussion] Stacklevel for warnings.

On Fri, 2018-08-10 at 16:05 -0600, Charles R Harris wrote: > Hi All, > > Do we have a policy for the stacklevel that should be used in NumPy? > How far back should the stack be displayed? I note that the optimum > stacklevel may vary between users and developers. > I thought it was so that it wi

Re: [Numpy-discussion] Stacklevel for warnings.

On Sat, 2018-08-11 at 11:11 -0700, Ralf Gommers wrote: > > > On Sat, Aug 11, 2018 at 1:22 AM, Sebastian Berg ns.net> wrote: > > On Fri, 2018-08-10 at 16:05 -0600, Charles R Harris wrote: > > > Hi All, > > > > > > Do we have a policy for th

Re: [Numpy-discussion] Adoption of a Code of Conduct

On Tue, 2018-08-14 at 21:30 -0700, Ralf Gommers wrote: > > > On Fri, Aug 3, 2018 at 1:02 PM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > > > > On Fri, Aug 3, 2018 at 1:45 PM, Peter Creasey < > > p.e.creasey...@googlemail.com> wrote: > > > +1 for keeping the same CoC as Scipy, making

Re: [Numpy-discussion] count_nonzero axis argument?

On Mon, 2018-09-17 at 12:37 +0100, Matthew Brett wrote: > Hi, > > Is there any reason that np.count_nonzero should not take an axis > argument? As in: > No, sounds like an obvious improvement, but as also with those, someone has to volunteer to do it... Coding it will probably mean adding the N

Re: [Numpy-discussion] Exact semantics of ufunc.reduce

On Fri, 2018-10-12 at 17:34 +0200, Hameer Abbasi wrote: > Hello! > > I’m trying to investigate the exact way ufunc.reduce works when given > a custom dtype. Does it cast before or after the operation, or > somewhere in between? How does this differ from ufunc.reduceat, for > example? > I am not

Re: [Numpy-discussion] Removing priority labels from github

On Fri, 2018-10-19 at 11:02 +0300, Matti Picus wrote: > We currently have highest, high, normal, low, and lowest priority > labels > for github issues/PRs. At the recent status meeting, we proposed > consolidating these to a single "high" priority label. Anything > "low" > priority should be mer

Re: [Numpy-discussion] Depreciating asfortranarray and ascontiguousarray

On Fri, 2018-10-26 at 13:25 -0700, Stephan Hoyer wrote: > On Fri, Oct 26, 2018 at 12:55 PM Alex Rogozhnikov < > alex.rogozhni...@yandex.ru> wrote: > > > > The conservative way to handle this would be to do a deprecation > > cycle, specifically by issuing FutureWarning when scalars or 0d > > array

  1   2   3   4   5   6   7   >