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

ate(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 wrote: > &

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),

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] 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

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" <sebast...@sipsolutions.net > > wrote: > On Fri, 2017-07-21 at 16:58 +0200, Julian Taylor wrote: > > On 21.07.2017 08:52, Ralf Gommers wrote: > Also

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

ode maintainers.  > > Thanks again, and best regards, > Martin > > > > > On Mon, 17 Jul 2017 11:41 Sebastian Berg <sebast...@sipsolutions.net> > write > > > Yes, I guess ones bug is someone elses feature :(, if it is very > > bad, we could delay th

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 > >

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

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

oseph 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 > > Martin Thoma > > Martino Sor

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

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]  >

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).

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

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

[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

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] 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

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

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." > >

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

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

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

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 > >

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

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: > > > >

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] 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 >

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] 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 > >

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:

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

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

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] 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

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] 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,

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

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] 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

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] PR to add an initializer kwarg to ufunc.reduce (and similar functions)

n 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 11:16 AM, S

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

d. > > 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 <

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

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 > <sebast...@sipsolutions.net> wrote: OK, the new documentation is > actually clear: initializer : scalar, optional The v

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

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] 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] 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 > >

Re: [Numpy-discussion] Vectorized version of numpy.linspace

On Wed, 2018-11-14 at 14:46 -0800, Stephan Hoyer wrote: > > > On Wed, Nov 14, 2018 at 2:35 PM Sebastian Berg < > sebast...@sipsolutions.net> wrote: > > On Wed, 2018-11-14 at 14:32 -0500, Marten van Kerkwijk wrote: > > some old issue or even PR somewhere. > >

[Numpy-discussion] Add guaranteed no-copy to array creation and reshape?

Hi all, In https://github.com/numpy/numpy/pull/11897 I am looking into the addition of a `copy=np.never_copy` argument to: * np.array * arr.reshape/np.reshape * arr.astype Which would cause an error to be raised when numpy cannot guarantee that the returned array is a view of the input

Re: [Numpy-discussion] Add guaranteed no-copy to array creation and reshape?

On Wed, 2018-12-26 at 16:40 -0800, Ralf Gommers wrote: > > > On Wed, Dec 26, 2018 at 3:29 PM Sebastian Berg < > sebast...@sipsolutions.net> wrote: > > Hi all, > > > > In https://github.com/numpy/numpy/pull/11897 I am looking into the > > a

Re: [Numpy-discussion] Add guaranteed no-copy to array creation and reshape?

On Mon, 2019-01-07 at 20:04 +0100, Matthias Geier wrote: > On Wed, Jan 2, 2019 at 2:24 PM Sebastian Berg wrote: > > On Wed, 2019-01-02 at 11:27 +0100, Matthias Geier wrote: > > > Hi Sebastian. > > > > > > Thanks for the clarification. > > >

Re: [Numpy-discussion] Pairwise summation

On Mon, 2019-01-07 at 12:15 -0800, Keith Goodman wrote: > Numpy uses pairwise summation along the fast axis if that axis > contains no more than 8192 elements. How was 8192 chosen? > It is simply a constant used throughout the ufunc machinery (and iteration) for cache friendliness. However,

Re: [Numpy-discussion] Add guaranteed no-copy to array creation and reshape?

On Fri, 2019-01-11 at 13:57 +1100, Juan Nunez-Iglesias wrote: > > > > On 10 Jan 2019, at 6:35 pm, Todd wrote: > > > > Could this approach be used to deprecate `ravel` and let us just > > use `flatten`? > > > Could we not? `.ravel()` is everywhere and it matches > `ravel_multi_index` and

Re: [Numpy-discussion] summation along a non-fast axis

On Fri, 2019-01-11 at 12:32 -0800, Keith Goodman wrote: > I remember back when a.sum(axis=0) was much slower than a.sum(axis=1) > for something like a=np.ones((1000, 1000)). But now it runs in about > the same time. How does numpy do it? > "now" is since numpy 1.7 or so :). > Does numpy do

Re: [Numpy-discussion] Add guaranteed no-copy to array creation and reshape?

On Sun, 2018-12-30 at 16:03 +0100, Matthias Geier wrote: > On Sat, Dec 29, 2018 at 6:00 PM Sebastian Berg wrote: > > On Sat, 2018-12-29 at 17:16 +0100, Matthias Geier wrote: > > > Hi Sebastian. > > > > > > I don't have an opinion (yet) about this

Re: [Numpy-discussion] Add guaranteed no-copy to array creation and reshape?

On Wed, 2019-01-02 at 11:27 +0100, Matthias Geier wrote: > Hi Sebastian. > > Thanks for the clarification. > > > print(arr.shape) # also (5, 2) > > > > so the arr container (shape, dtype) is changed/muted. I think we > > expect > > that for content here, but not for the shape. > > Thanks for

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

Re: [Numpy-discussion] Introducing myself

Hello Malika and welcome, On Sat, 2019-03-23 at 02:08 +0100, Brinda wrote: > Hello, I am called Malika. > My outreachy initial application has been recently approved. I am new > to this community and I'm really eager to work on this project. > Please I wish someone explains to me how to get

Re: [Numpy-discussion] Outreachy applicant introduction

On Sat, 2019-03-30 at 19:21 +0530, Parul Unofficial wrote: > Hello! > > I'm Parul Aggarwal, a pre-final year student from India pursuing my > bachelor's in Computer Science. I'm comfortable programming in C++ > and Python and have also worked previously on some projects based on > flask, Django.

Re: [Numpy-discussion] Beginner Help: Generating HTML using Sphinx

Hi Sanchi, On Sat, 2019-03-30 at 15:58 +0530, Sanchi Vaishnavi wrote: > I was learning to get to $ make html to work. These are the final > steps that I used on my test branch in my numpy repo: > > > $ sphinx-build -b html doc/source builddir > > >> build succeeded, 165 warnings. > > $ make

[Numpy-discussion] Adding count parameter to unpackbits (PR-10855)

Hi all, I was about to merge it, but was noot sure it was really discussed before (and it would be a long time ago). The pull requests: https://github.com/numpy/numpy/pull/10855 Proposes to add a count parameter to unpackbits: ``count`` allows subsetting the number of bits that will be

Re: [Numpy-discussion] NEP-18 comment

On Wed, 2019-03-06 at 12:41 -0800, Stephan Hoyer wrote: > On Wed, Mar 6, 2019 at 10:10 AM Frederic Bastien > wrote: > > Hi, > > > > I was told recently about the NEP-18. I like it, but I have a > > comment. > > > > At first, it is enabled in a release by setting an environment > > variable. >

Re: [Numpy-discussion] NEP-18 comment

On Thu, 2019-03-07 at 18:24 +, Frederic Bastien wrote: > I see speed changes vs behavior changes as different category of > changes in my mind. > > I understand that now importing library can slow down NumPy for small > arrays. > But I have the impression you tell this can also give behavior

Re: [Numpy-discussion] casting from datetime64

Hi Alex, On Mon, 2019-05-13 at 00:35 -0400, Alex Samuel wrote: > Hi, > > When registering a custom cast function from datetime64 to another > dtype, how can I get the units? > > I am calling PyArray_RegisterCastFunc from NPY_DATETIME. Ideally, > I'd like to register a separate cast function

[Numpy-discussion] Histgrom density estimation (density kwarg) with out of range values

Hi all, unfortunately it was noticed in Issue 13604 [0] that when histogram is given used with a specified range and the `density=True` keyword argument out of bound values are simply discarded [1]. Discarding out of bound values makes sense when the density/normed option is not used, since in

Re: [Numpy-discussion] Moving forward with value based casting

On Fri, 2019-06-07 at 07:18 +0200, Ralf Gommers wrote: > > > On Fri, Jun 7, 2019 at 1:37 AM Nathaniel Smith wrote: > > My intuition is that what users actually want is for *native Python > > types* to be treated as having 'underspecified' dtypes, e.g. int is > > happy to coerce to

Re: [Numpy-discussion] Moving forward with value based casting

On Fri, 2019-06-07 at 13:19 -0500, Sebastian Berg wrote: > On Fri, 2019-06-07 at 07:18 +0200, Ralf Gommers wrote: > > > > On Fri, Jun 7, 2019 at 1:37 AM Nathaniel Smith > > wrote: > > > My intuition is that what users actually want is for *native > > > Pyth

Re: [Numpy-discussion] Moving forward with value based casting

On Thu, 2019-06-06 at 19:34 -0400, Allan Haldane wrote: > On 6/6/19 12:46 PM, Sebastian Berg wrote: > > On Thu, 2019-06-06 at 11:57 -0400, Allan Haldane wrote: > > > I think dtype-based casting makes a lot of sense, the problem is > > > backward compatibility. > >

Re: [Numpy-discussion] defining a NumPy API standard?

On Sun, 2019-06-02 at 08:42 +0200, Ralf Gommers wrote: > > > > > > > > > This sounds like a restructuring or factorization of the API, in > > order to make it smaller, and thus easier to learn and use. > > It may start with the docs, by paying more attention to the "core" > > or important

Re: [Numpy-discussion] Moving forward with value based casting

On Wed, 2019-06-05 at 14:14 -0700, Stephan Hoyer wrote: > On Wed, Jun 5, 2019 at 1:43 PM Sebastian Berg < > sebast...@sipsolutions.net> wrote: > > Hi all, > > > > > > Because `uint8(127)` can also be a `int8`, but uint8(128) it is not > > as >

[Numpy-discussion] Moving forward with value based casting

Hi all, TL;DR: Value based promotion seems complex both for users and ufunc- dispatching/promotion logic. Is there any way we can move forward here, and if we do, could we just risk some possible (maybe not-existing) corner cases to break early to get on the way? --- Currently when you

Re: [Numpy-discussion] Moving forward with value based casting

, 2019-06-05 at 15:41 -0500, Sebastian Berg wrote: > Hi all, > > TL;DR: > > Value based promotion seems complex both for users and ufunc- > dispatching/promotion logic. Is there any way we can move forward > here, > and if we do, could we just risk some possible (maybe not-

Re: [Numpy-discussion] Moving forward with value based casting

On Wed, 2019-06-05 at 21:35 -0400, Marten van Kerkwijk wrote: > Hi Sebastian, > > Tricky! It seems a balance between unexpected memory blow-up and > unexpected wrapping (the latter mostly for integers). > > Some comments specifically on your message first, then some more > general related ones.

Re: [Numpy-discussion] Moving forward with value based casting

functions inside numpy), lookup could be simplified. For those loops with all the same dtype, the issue is fairly straight forward anyway, because I can just decide how to handle the scalar before hand. Best, Sebastian > > Tyler > > On Wed, 5 Jun 2019 at 15:37, Sebastian Berg &

Re: [Numpy-discussion] Moving forward with value based casting

is tricky. Users can pass `dtype` explicitly, but that is a huge kludge... Will think about if there is a solution to that, because if there is not, you are right. It has to be a "big step" kind of release. Although, even then it would be nice to have warnings that can be enabled to ease th

Re: [Numpy-discussion] defining a NumPy API standard?

On Sun, 2019-06-02 at 08:38 +0200, Ralf Gommers wrote: > > > On Sun, Jun 2, 2019 at 3:18 AM Marten van Kerkwijk < > m.h.vankerkw...@gmail.com> wrote: > > > Our API is huge. A simple count: > > > main namespace: 600 > > > fft: 30 > > > linalg: 30 > > > random: 60 > > > ndarray: 70 > > > lib: 20 >

Re: [Numpy-discussion] Planning for 1.18

On Thu, 2019-06-13 at 19:09 -0600, Charles R Harris wrote: > Hi All, > > With the 1.17 branch coming soon, this might be a good time to make > plans about 1.18 development. A couple of possibilities are: > > Expiring old deprecations, Good plan. > Removing Python 2.7 compatibility code,

Re: [Numpy-discussion] Extent to which to work around matrix and other duck/subclass limitations

On Tue, 2019-06-11 at 10:56 +0200, Ralf Gommers wrote: > > > On Mon, Jun 10, 2019 at 7:47 PM Marten van Kerkwijk < > m.h.vankerkw...@gmail.com> wrote: > > Hi All, > > > > In https://github.com/numpy/numpy/pull/12801, Tyler has been trying > > to use the new `where` argument for reductions to

Re: [Numpy-discussion] Moving forward with value based casting

Hi Hameer, On Tue, 2019-06-18 at 04:28 +0200, Hameer Abbasi wrote: > On Wed, 2019-06-12 at 12:55 -0500, Sebastian Berg wrote: > > On Wed, 2019-06-05 at 15:41 -0500, Sebastian Berg wrote: > > > Hi all, > > > > A type is safely castable to another if all of these

[Numpy-discussion] NumPy Community Meeting June 19

Hi all, There will be a NumPy Community meeting on June 12 at 11 am Pacific Time. Everyone is invited to join in and edit the work-in-progress meeting notes: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both Best wishes Sebastian signature.asc Description: This is a digitally signed message part

[Numpy-discussion] NumPy Community Meeting Thursday, June 26

Hi all, There will be a NumPy Community meeting on _Thursday_ June 26 at 11 am Pacific Time. Everyone is invited to join in and edit the work-in- progress meeting notes: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both Best wishes Sebastian PS: We decided to move to Thursday, since at least

Re: [Numpy-discussion] NumPy Community Meeting Thursday, June 27

Sorry, Thursday is the 27th of course. On Mon, 2019-06-24 at 11:02 -0700, Sebastian Berg wrote: > Hi all, > > There will be a NumPy Community meeting on _Thursday_ June 26 at 11 > am > Pacific Time. Everyone is invited to join in and edit the work-in- > progress meeting notes:

Re: [Numpy-discussion] Syntax Improvement for Array Transpose

On Tue, 2019-06-25 at 17:00 -0400, Marten van Kerkwijk wrote: > Hi Kirill, others, > > Indeed, it is becoming long! That said, while initially I was quite > charmed by Eric's suggestion of deprecating and then changing `.T`, I > think the well-argued opposition to it has changed my opinion. >

Re: [Numpy-discussion] (Value Based Promotion) Current Behaviour

; those are likely to come up again later). > > > > All the Best, > > > > Sebastian > > > > > > - > > > > PS: Below a copy of what I wrote: > > > > --- > > title: Numpy Value Based Promotio

[Numpy-discussion] New release note strategy after branching 1.17.

Hi all, we had discussed trying a new strategy to gather release notes on the last community call, but not followed up on it on the list yet. For the next release, we decided to try a strategy of using a wiki page to gather release notes. The main purpose for this is to avoid merge conflicts in

Re: [Numpy-discussion] (Value Based Promotion) Current Behaviour

On Wed, 2019-06-12 at 12:03 -0500, Sebastian Berg wrote: > On Tue, 2019-06-11 at 22:08 -0400, Marten van Kerkwijk wrote: > > HI Sebastian, > > > > Thanks for the overview! In the value-based casting, what perhaps > > surprises me most is that it is done w

Re: [Numpy-discussion] New release note strategy after branching 1.17.

n. - Sebastian > On Wed, Jun 12, 2019, 07:59 Sebastian Berg < > sebast...@sipsolutions.net> wrote: > > Hi all, > > > > we had discussed trying a new strategy to gather release notes on > > the > > last community call, but not followed up on it on the l

Re: [Numpy-discussion] (Value Based Promotion) Current Behaviour

ed special "minimum value" rules. And of course it also means that resolvers need to handle such scalar(?) objects, but in many cases they do not need more than "can cast" anyway. Best, Sebastian > Best Regards, > Hameer Abbasi > > > On Wednesday, Jun 12, 2019 a

Re: [Numpy-discussion] Moving forward with value based casting

On Wed, 2019-06-05 at 21:35 -0400, Marten van Kerkwijk wrote: > Hi Sebastian, > > Tricky! It seems a balance between unexpected memory blow-up and > unexpected wrapping (the latter mostly for integers). > > Some comments specifically on your message first, then some more > general related ones.

[Numpy-discussion] Better way to create multiple independent random number generators

Hi all, since this is going to be a new addition as part of the randomgen, I thought I would just mention it on the mailing list. The Pull Request: https://github.com/numpy/numpy/pull/13780 Implements a new SeedSequence object based on Robert Kern's proposal and especially the work by Prof.

Re: [Numpy-discussion] Syntax Improvement for Array Transpose

On Sun, 2019-06-23 at 19:51 +, Hameer Abbasi wrote: > +1 for this. I have often seen (and sometimes written) code that does > this automatically, and it is a common mistake. Yeah, likely worth a short. I doubt many uses for the n-dimensional axis transpose, so maybe a futurewarning approach

Re: [Numpy-discussion] Syntax Improvement for Array Transpose

On Sun, 2019-06-23 at 23:03 +0200, Andras Deak wrote: > On Sun, Jun 23, 2019 at 10:37 PM Sebastian Berg > wrote: > > Yeah, likely worth a short. I doubt many uses for the n-dimensional > > axis transpose, so maybe a futurewarning approach can work. If not, > > I

Re: [Numpy-discussion] Syntax Improvement for Array Transpose

ror is good, which is nice, because we can just tag on a warning and not worry about it for a while ;). > > All the best, > > Marten > > On Sun, Jun 23, 2019 at 4:37 PM Sebastian Berg < > sebast...@sipsolutions.net> wrote: > > On Sun, 2019-06-23

[Numpy-discussion] (Value Based Promotion) Current Behaviour

signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] New release note strategy after branching 1.17.

On Wed, 2019-06-12 at 17:34 -0700, Nathaniel Smith wrote: > On Wed, Jun 12, 2019 at 12:58 PM Marten van Kerkwijk > wrote: > > Overall, in favour of splitting the large files, but I don't like > > that the notes stop being under version control (e.g., a follow-up > > PR slightly changes things,

  1   2   3   4   5   6   >