Re: [Numpy-discussion] PyData Barcelona this May

On Thu, 2017-03-09 at 15:45 +0100, Jaime Fernández del Río wrote: > There will be a PyData conference in Barcelona this May: > > http://pydata.org/barcelona2017/ > > I am planning on attending, and was thinking of maybe proposing to > organize a numpy-themed workshop or tutorial. > > My

Re: [Numpy-discussion] vectorization vs. numpy.linalg (shape (3, 3, 777) vs shape (777, 3, 3))

. - Sebastian > > Cheers, > Nico > > > On Sun, Mar 5, 2017 at 3:53 PM Sebastian Berg <sebastian@sipsolutions > .net> wrote: > > On Thu, 2017-03-02 at 10:27 +, Nico Schlömer wrote: > > > Hi everyone, > > > > > > When trying to

Re: [Numpy-discussion] vectorization vs. numpy.linalg (shape (3, 3, 777) vs shape (777, 3, 3))

On Thu, 2017-03-02 at 10:27 +, Nico Schlömer wrote: > Hi everyone, > > When trying to speed up my code, I noticed that simply by reordering > my data I could get more than twice as fast for the simplest > operations: > ``` > import numpy > a = numpy.random.rand(50, 50, 50) > > %timeit a[0] +

Re: [Numpy-discussion] Default type for functions that accumulate integers

On Mo, 2017-01-02 at 18:46 -0800, Nathaniel Smith wrote: > On Mon, Jan 2, 2017 at 6:27 PM, Charles R Harris > wrote: > > > > Hi All, > > > > Currently functions like trace use the C long type as the default > > accumulator for integer types of lesser precision: > >

Re: [Numpy-discussion] Casting to np.byte before clearing values

On Mo, 2016-12-26 at 10:34 +0100, Nicolas P. Rougier wrote: > Hi all, > > > I'm trying to understand why viewing an array as bytes before > clearing makes the whole operation faster. > I imagine there is some kind of special treatment for byte arrays but > I've no clue.  > Sure, if its a

Re: [Numpy-discussion] Does numpy.bincount support numpy.float128 type weights?

Fist off, a word of caution. float128 depends on your system and maps to whatever longdouble is (IIRC) or may not even exist. So I hope you don't expect IEEE 128 bit floats, if you are unsure, maybe check `np.finfo`. If speed does not matter ``` res = np.zeros(np.max(b), dtype=np.longdouble)

Re: [Numpy-discussion] Numpy 1.12.x branched

On Sa, 2016-11-05 at 17:04 -0600, Charles R Harris wrote: > Hi All, > > Numpy 1.12.x has been branched and the 1.13 development branch is > open. It would be helpful if folks could review the release notes as > it is likely I've missed something.  I'd like to make the first beta > release in a

Re: [Numpy-discussion] ufunc for sum of squared difference

perations look identical and I thought np.sum just calls > np.add.reduce, so the reduction step uses the same code and would > therefore have the same accuracy. > Sorry, did not read it carefully, I guess `c` is the mean, so you are doing the two pass method. - Sebastian > Thanks >

Re: [Numpy-discussion] ufunc for sum of squared difference

On Fr, 2016-11-04 at 13:11 -0400, Matthew Harrigan wrote: > I was reading this and got thinking about if a ufunc could compute > the sum of squared differences in a single pass without a temporary > array.  The python code below demonstrates a possible approach. > > import numpy as np > x =

Re: [Numpy-discussion] Intel random number package

On Mi, 2016-10-26 at 09:29 -0700, Robert Kern wrote: > On Wed, Oct 26, 2016 at 9:10 AM, Julian Taylor mail.com> wrote: > > > > On 10/26/2016 06:00 PM, Julian Taylor wrote: > > >> I prefer for the full functionality of numpy to stay available > with a > >> stack of

Re: [Numpy-discussion] fpower ufunc

On Fr, 2016-10-21 at 09:45 +0200, Sebastian Berg wrote: > On Do, 2016-10-20 at 21:38 -0600, Charles R Harris wrote: > > > > > > > > On Thu, Oct 20, 2016 at 9:11 PM, Nathaniel Smith <n...@pobox.com> > > wrote: > > > > > > On Thu, Oct

Re: [Numpy-discussion] fpower ufunc

On Do, 2016-10-20 at 21:38 -0600, Charles R Harris wrote: > > > On Thu, Oct 20, 2016 at 9:11 PM, Nathaniel Smith > wrote: > > On Thu, Oct 20, 2016 at 7:58 PM, Charles R Harris > > wrote: > > > Hi All, > > > > > > I've put up a preliminary PR for the

Re: [Numpy-discussion] how to name "contagious" keyword in np.ma.convolve

On Fr, 2016-10-14 at 13:00 -0400, Allan Haldane wrote: > Hi all, > > Eric Wieser has a PR which defines new functions np.ma.correlate and > np.ma.convolve: > > https://github.com/numpy/numpy/pull/7922 > > We're deciding how to name the keyword arg which determines whether > masked elements are

Re: [Numpy-discussion] Integers to negative integer powers, time for a decision.

On Fr, 2016-10-07 at 19:12 -0600, Charles R Harris wrote: > Hi All, > > The time for NumPy 1.12.0 approaches and I like to have a final > decision on the treatment of integers to negative integer powers with > the `**` operator. The two alternatives looked to be > > Raise an error for arrays and

Re: [Numpy-discussion] [7949] How to handle these deprecation Warning errors

On Mo, 2016-09-26 at 15:36 +0200, Saurabh Mehta wrote: > Hi > > I am working on issue #7949, and need to use "-3" switch while > running python 2.7 for my tests. > python -3 -c "import numpy as np; np.test()" > > Several errors are reported and all all of them are > DeprecationWarnings, which is

Re: [Numpy-discussion] String & unicode arrays vs text loading in python 3

On Di, 2016-09-13 at 15:02 +0200, Lluís Vilanova wrote: > Hi! I'm giving a shot to issue #3184 [1], based on the observation > that the > string dtype ('S') under python 3 uses byte arrays instead of unicode > (the only > readable string type in python 3). > > This brings two major problems: > >

Re: [Numpy-discussion] New iterator APIs (nditer / MapIter): Overlap detection in NumPy

On Mo, 2016-09-12 at 20:22 +, Pauli Virtanen wrote: > Mon, 12 Sep 2016 11:31:07 +0200, Sebastian Berg kirjoitti: > > > > > > > > * NPY_ITER_COPY_IF_OVERLAP, NPY_ITER_OVERLAP_NOT_SAME > > >   flags for NpyIter_New. > > > > > >

Re: [Numpy-discussion] New iterator APIs (nditer / MapIter): Overlap detection in NumPy

the worst API clutter in history. > > Continuation here: https://github.com/numpy/numpy/pull/8043 > > > > Wed, 07 Sep 2016 18:02:59 +0200, Sebastian Berg kirjoitti: > > > > > Hi all, > > > > Pauli just opened a nice pull request [1] to add overla

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On So, 2016-09-11 at 11:19 -0400, Marten van Kerkwijk wrote: > There remains the option to just let subclasses deal with new ndarray > features...  Certainly, for `Quantity`, I'll quite happily do that. > And if it alllows the ndarray code to remain simple and efficient, it > is probably the best

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Di, 2016-09-06 at 13:59 -0400, Marten van Kerkwijk wrote: > In a separate message, since perhaps a little less looney: yet > another > option would be work by analogy with np.ix_ and define pre-dispatch > index preparation routines np.ox_ and np.vx_ (say), which would be > used as in: > ``` >

Re: [Numpy-discussion] Continued New Indexing Methods Revival #N (subclasses!)

On Sa, 2016-09-10 at 12:01 +0200, Sebastian Berg wrote: > Hi all, > > from the discussion, I was thinking maybe something like this: > > class B(): >    def __numpy_getitem__(self, index, indexing_method="plain"): >        # do magic. >        return super().__n

[Numpy-discussion] Continued New Indexing Methods Revival #N (subclasses!)

Hi all, from the discussion, I was thinking maybe something like this: class B():    def __numpy_getitem__(self, index, indexing_method="plain"):        # do magic.        return super().__numpy_getitem__( index, indexing_method=indexing_method) as new API. There are some issues,

Re: [Numpy-discussion] New iterator API (nditer): Overlap detection in NumPy

On Mi, 2016-09-07 at 09:22 -0700, Nathaniel Smith wrote: > On Sep 7, 2016 9:03 AM, "Sebastian Berg" <sebast...@sipsolutions.net> > wrote: > > > > Hi all, > > > > Pauli just opened a nice pull request [1] to add overlap detection > to > >

[Numpy-discussion] New iterator API (nditer): Overlap detection in NumPy

Hi all, Pauli just opened a nice pull request [1] to add overlap detection to the new iterator, this means adding a new iterator flag: `NPY_ITER_COPY_IF_OVERLAP` If passed to the iterator (also exposed in python), the iterator will copy the operands such that reading and writing should only

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Di, 2016-09-06 at 13:59 -0400, Marten van Kerkwijk wrote: > In a separate message, since perhaps a little less looney: yet > another > option would be work by analogy with np.ix_ and define pre-dispatch > index preparation routines np.ox_ and np.vx_ (say), which would be > used as in: > ``` >

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Di, 2016-09-06 at 10:10 -0700, Stephan Hoyer wrote: > On Mon, Sep 5, 2016 at 6:02 PM, Marten van Kerkwijk gmail.com> wrote: > > p.s. Just to be clear: personally, I think we should have neither > > `__numpy_getitem__` nor a mixin; we should just get the quite > > wonderful

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Di, 2016-09-06 at 10:57 +0100, Robert Kern wrote: > On Tue, Sep 6, 2016 at 8:46 AM, Sebastian Berg <sebastian@sipsolution > s.net> wrote: > > > > On Di, 2016-09-06 at 09:37 +0200, Sebastian Berg wrote: > > > On Mo, 2016-09-05 at 18:31 -0400, Marten van Kerkwij

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Di, 2016-09-06 at 09:37 +0200, Sebastian Berg wrote: > On Mo, 2016-09-05 at 18:31 -0400, Marten van Kerkwijk wrote: > > > > Actually, on those names: an alternative to your proposal would be > > to > > introduce only one new method which can do all types of indexing,

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Mo, 2016-09-05 at 18:31 -0400, Marten van Kerkwijk wrote: > Actually, on those names: an alternative to your proposal would be to > introduce only one new method which can do all types of indexing, > depending on a keyword argument, i.e., something like > ``` > def getitem(self, item,

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Mo, 2016-09-05 at 21:02 -0400, Marten van Kerkwijk wrote: > p.s. Just to be clear: personally, I think we should have neither > `__numpy_getitem__` nor a mixin; we should just get the quite > wonderful new indexing methods! Hehe, yes but see MaskedArrays. They need logic to also index the

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Mo, 2016-09-05 at 18:31 -0400, Marten van Kerkwijk wrote: > Actually, on those names: an alternative to your proposal would be to > introduce only one new method which can do all types of indexing, > depending on a keyword argument, i.e., something like > ``` > def getitem(self, item,

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Mo, 2016-09-05 at 18:19 -0500, Nathan Goldbaum wrote: > > > On Monday, September 5, 2016, Marten van Kerkwijk ail.com> wrote: > > Hi Sebastian, > > > > It would seem to me that any subclass has to keep up to date with > > new > > features in ndarray, and while I think

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Mo, 2016-09-05 at 18:24 -0400, Marten van Kerkwijk wrote: > Hi Sebastian, > > It would seem to me that any subclass has to keep up to date with new > features in ndarray, and while I think ndarray has a responsibility > not to break backward compatibility, I do not think it has to protect >

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Mo, 2016-09-05 at 14:54 -0400, Marten van Kerkwijk wrote: > Hi Sebastian, > > Indeed, having the scalar pass through `__array_wrap__` would have > been useful (_finalize__ is too late, since one cannot change the > class any more, just set attributes).  But that is water under the > bridge,

Re: [Numpy-discussion] Correct error of invalid axis arguments.

On Mo, 2016-09-05 at 11:54 -0600, Charles R Harris wrote: > Hi All, > > At the moment there are two error types raised when invalid axis > arguments are encountered: IndexError and ValueError. I prefer > ValueError for arguments, IndexError seems more appropriate when the > bad axis value is used

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On So, 2016-09-04 at 11:20 -0400, Marten van Kerkwijk wrote: > Hi Sebastian, > > I haven't given this as much thought as it deserves, but thought I > would comment from the astropy perspective, where we both have direct > subclasses of `ndarray` (`Quantity`, `Column`, `MaskedColumn`) and >

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On So, 2016-09-04 at 14:10 +0200, Sebastian Berg wrote: > On Sa, 2016-09-03 at 21:08 +0200, Sebastian Berg wrote: > > > > Hi all, > > > > not that I am planning to spend much time on this right now, > > however, > > I > > did a small rebase of

Re: [Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

On Sa, 2016-09-03 at 21:08 +0200, Sebastian Berg wrote: > Hi all, > > not that I am planning to spend much time on this right now, however, > I > did a small rebase of the stuff I had (did not push yet) on oindex > and > remembered the old problem ;). > > The

[Numpy-discussion] New Indexing Methods Revival #N (subclasses!)

Hi all, not that I am planning to spend much time on this right now, however, I did a small rebase of the stuff I had (did not push yet) on oindex and remembered the old problem ;). The one remaining issue I have with adding things like (except making the code prettier and writing tests):

Re: [Numpy-discussion] Which NumPy/Numpy/numpy spelling?

On Di, 2016-08-30 at 12:17 -0700, Stefan van der Walt wrote: > On Mon, Aug 29, 2016, at 04:43, m...@telenczuk.pl wrote: > > > > The documentation is not consistent and it mixes both NumPy and > > Numpy. > > For example, the reference manual uses both spellings in the > > introduction > >

Re: [Numpy-discussion] Indexing issue with ndarrays

On Fr, 2016-08-26 at 09:57 -0400, Joseph Fox-Rabinovitz wrote: > > > On Thu, Aug 25, 2016 at 4:37 PM, Sebastian Berg <sebastian@sipsolutio > ns.net> wrote: > > On Do, 2016-08-25 at 10:36 -0400, Joseph Fox-Rabinovitz wrote: > > > This issue recently came up on S

Re: [Numpy-discussion] Indexing issue with ndarrays

On Do, 2016-08-25 at 10:36 -0400, Joseph Fox-Rabinovitz wrote: > This issue recently came up on Stack Overflow: http://stackoverflow.c > om/questions/39145795/masking-a-series-with-a-boolean-array. The > poster attempted to index an ndarray with a pandas boolean Series > object (all False), but

Re: [Numpy-discussion] How to trigger warnings for integer division in python 2

On Fr, 2016-08-19 at 11:29 -0400, Stuart Berg wrote: > Hi, > > To help people migrate their code bases from Python 2 to Python 3, > the python interpreter has a handy option '-3' that issues warnings > at runtime.  One of the warnings is for integer division: > > $ echo "print 3/2" > /tmp/foo.py

Re: [Numpy-discussion] Views and Increments

On Mo, 2016-08-08 at 15:11 +0200, Anakim Border wrote: > Dear List, > > I'm experimenting with views and array indexing. I have written two > code blocks that I was expecting to produce the same result. > > First try: > > >>> a = np.arange(10) > >>> b = a[np.array([1,6,5])] > >>> b += 1 > >>> a

[Numpy-discussion] Euroscipy

Hi all, I am still pondering whether or not (and if which days) to go to EuroScipy. Who else is there and would like to discuss a bit or whatever else? - Sebastian signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion

Re: [Numpy-discussion] Is there any official position on PEP484/mypy?

On Mi, 2016-07-27 at 20:07 +0100, Daniel Moisset wrote: > > Hi,  > > I work at Machinalis were we use a lot of numpy (and the pydata stack > in general). Recently we've also been getting involved with mypy, > which is a tool to type check (not on runtime, think of it as a > linter) annotated

Re: [Numpy-discussion] Custom Dtype/Units discussion

On Do, 2016-07-14 at 18:46 -0500, Nathan Goldbaum wrote: > We are in room 203 > You guys were probably doing that anyway, and I know you are too busy right now. But if there were some nice ideas/plans from this discussion, related to Numpy or not, I would appreciate a lot if one of you can send

Re: [Numpy-discussion] Added atleast_nd, request for clarification/cleanup of atleast_3d

On Mi, 2016-07-06 at 15:30 -0400, Benjamin Root wrote: > I don't see how one could define a spec that would take an arbitrary > array of indices at which to place new dimensions. By definition, you > You just give a reordered range, so that (1, 0, 2) would be the current 3D version. If 1D, fill

Re: [Numpy-discussion] Added atleast_nd, request for clarification/cleanup of atleast_3d

On Mi, 2016-07-06 at 10:22 -0400, Marten van Kerkwijk wrote: > Hi All, > > I'm with Nathaniel here, in that I don't really see the point of > these routines in the first place: broadcasting takes care of many of > the initial use cases one might think of, and others are generally > not all that

Re: [Numpy-discussion] Is numpy.test() supposed to be multithreaded?

On Mi, 2016-06-29 at 02:03 -0700, Nathaniel Smith wrote: > As a general rule I wouldn't worry too much about test speed. Speed > is > extremely dependent on exact workloads. And this is doubly so for > test > suites -- production workloads tend to do a small number of normal > things over and

Re: [Numpy-discussion] Support of '@='?

On Mi, 2016-06-22 at 02:38 +0200, Hans Larsen wrote: > I have Python 3-5-1 and NumPy 1-11! windows 64bits! > When will by side 'M=M@P' be supported with 'M@=P'???:-( > When someone gets around to making it a well defined operation? ;) Just to be clear, `M = M @ P` is probably not what `M @= P`

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

On Mo, 2016-06-20 at 15:15 -0700, Nathaniel Smith wrote: > On Mon, Jun 20, 2016 at 3:09 PM,   wrote: > > > > On Mon, Jun 20, 2016 at 4:31 PM, Alan Isaac > > wrote: > > > > > > On 6/13/2016 1:54 PM, Marten van Kerkwijk wrote: > > > > > > > > > > > >

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

On Fr, 2016-06-10 at 20:16 +, Ian Henriksen wrote: > On Fri, Jun 10, 2016 at 12:01 PM Nathaniel Smith > wrote: > > On Jun 10, 2016 10:50, "Alan Isaac" wrote: > > > > > > On 6/10/2016 1:34 PM, Nathaniel Smith wrote: > > >> > > >> You keep pounding on this

Re: [Numpy-discussion] ENH: compute many inner products quickly

On Di, 2016-06-07 at 00:32 +0200, Jaime Fernández del Río wrote: > On Mon, Jun 6, 2016 at 9:35 AM, Sebastian Berg <sebastian@sipsolution > s.net> wrote: > > On So, 2016-06-05 at 19:20 -0600, Charles R Harris wrote: > > > > > > > > > On Sun, Jun 5, 201

Re: [Numpy-discussion] ENH: compute many inner products quickly

On So, 2016-06-05 at 19:20 -0600, Charles R Harris wrote: > > > On Sun, Jun 5, 2016 at 6:41 PM, Stephan Hoyer > wrote: > > If possible, I'd love to add new functions for "generalized ufunc" > > linear algebra, and then deprecate (or at least discourage) using > > the older

[Numpy-discussion] Developer Meeting at EuroScipy?

Hi all, since we had decided to do a regular developers meeting last year, how would EuroScipy (Aug. 23.-27., Erlangen, Germany) look as a possible place and time to have one? I believe EuroScipy would include a few people who were not able to come to SciPy last year, and it seems SciPy itself

Re: [Numpy-discussion] Changing FFT cache to a bounded LRU cache

On Fr, 2016-05-27 at 22:51 +0200, Lion Krischer wrote: > Hi all, > > I was told to take this to the mailing list. Relevant pull request: > https://github.com/numpy/numpy/pull/7686 > > > NumPy's FFT implementation caches some form of execution plan for > each > encountered input data length.

Re: [Numpy-discussion] (no subject)

On Mi, 2016-04-27 at 22:11 +0530, Saumyajit Dey wrote: > Hi, > > Thanks a lot for the reply. I am looking into the documentation > already. Also is there any guide as to how the source code of Numpy > is organised? > > For example, when i write > > > np.power(2,3) > what is the workflow in

Re: [Numpy-discussion] Do getitem/setitem already have GIL?

This is for a custom dtype? getitem and setitem work with objects and must have the GIL in any case, so yes, you can safely assume this. I think you probably have to set the flags correctly for some things to work right. So that the PyDataType_REFCHK makro gives the right result. Though frankly, I

Re: [Numpy-discussion] f2py: ram usage

On So, 2016-04-10 at 12:04 +0200, Vasco Gervasi wrote: > Hi all, > I am trying to write some code to do calculation onto an array: for > each row I need to do some computation and have a number as return. > To speed up the process I wrote a fortran subroutine that is called > from python [using

Re: [Numpy-discussion] ndarray.T2 for 2D transpose

On Do, 2016-04-07 at 13:29 -0400, josef.p...@gmail.com wrote: > > > On Thu, Apr 7, 2016 at 1:20 PM, Sebastian Berg < > sebast...@sipsolutions.net> wrote: > > On Do, 2016-04-07 at 11:56 -0400, josef.p...@gmail.com wrote: > > > > > > > > > >

Re: [Numpy-discussion] ndarray.T2 for 2D transpose

On Do, 2016-04-07 at 11:56 -0400, josef.p...@gmail.com wrote: > > > > I don't think numpy treats 1d arrays as row vectors. numpy has C > -order for axis preference which coincides in many cases with row > vector behavior. > Well, broadcasting rules, are that (n,) should typically behave

Re: [Numpy-discussion] Multidimension array access in C via Python API

On Di, 2016-04-05 at 20:19 +0200, Sebastian Berg wrote: > On Di, 2016-04-05 at 09:48 -0700, mpc wrote: > > The idea is that I want to thin a large 2D buffer of x,y,z points > > to > > a given > > resolution by dividing the data into equal sized "cubes" (i.e.

Re: [Numpy-discussion] Multidimension array access in C via Python API

On Di, 2016-04-05 at 09:48 -0700, mpc wrote: > The idea is that I want to thin a large 2D buffer of x,y,z points to > a given > resolution by dividing the data into equal sized "cubes" (i.e. > resolution is > number of cubes along each axis) and averaging the points inside each > cube > (if any).

Re: [Numpy-discussion] Multi-dimensional array of splitted array

On Mi, 2016-03-23 at 10:02 -0400, Joseph Fox-Rabinovitz wrote: > On Wed, Mar 23, 2016 at 9:37 AM, Ibrahim EL MEREHBI > wrote: > > Thanks Eric. I already checked that. It's not what I want. I think > > I wasn't > > clear about what I wanted. > > > > I want to split each

Re: [Numpy-discussion] Multi-dimensional array of splitted array

On Mi, 2016-03-23 at 10:02 -0400, Joseph Fox-Rabinovitz wrote: > On Wed, Mar 23, 2016 at 9:37 AM, Ibrahim EL MEREHBI > wrote: > > Thanks Eric. I already checked that. It's not what I want. I think > > I wasn't > > clear about what I wanted. > > > > I want to split each

Re: [Numpy-discussion] GSoC?

On Fr, 2016-03-04 at 21:20 +, Pauli Virtanen wrote: > Thu, 11 Feb 2016 00:02:52 +0100, Ralf Gommers kirjoitti: > [clip] > > OK first version: > > https://github.com/scipy/scipy/wiki/GSoC-2016-project-ideas I kept > > some > > of the ideas from last year, but removed all potential mentors as >

Re: [Numpy-discussion] How to check for memory leaks?

On Di, 2016-02-23 at 12:36 -0700, Charles R Harris wrote: > Hi All, > > I'm suspecting a possible memory leak in 1.11.x, what is the best way > to check for that? > Would like to learn better methods, but I tried valgrind with trace origins and full leak check, just thinking maybe it shows

Re: [Numpy-discussion] reshaping empty array bug?

On Di, 2016-02-23 at 21:06 +0100, Sebastian Berg wrote: > On Di, 2016-02-23 at 14:57 -0500, Benjamin Root wrote: > > I'd be more than happy to write up the patch. I don't think it > > would > > be quite like make zeros be ones, but it would be along those > > lines. >

Re: [Numpy-discussion] reshaping empty array bug?

bugs by not failing when it should. And whether that would be a tradeoff we are willing to accept. - Sebastian > > This is looking more and more like a bug to me. > > Ben Root > > > On Tue, Feb 23, 2016 at 1:58 PM, Sebastian Berg < > sebast...@sipsolutions.net> wrote: > > On

Re: [Numpy-discussion] reshaping empty array bug?

On Di, 2016-02-23 at 11:45 -0500, Benjamin Root wrote: > but, it isn't really ambiguous, is it? The -1 can only refer to a > single dimension, and if you ignore the zeros in the original and new > shape, the -1 is easily solvable, right? I think if there is a simple logic (like using 1 for all

Re: [Numpy-discussion] making "low" optional in numpy.randint

stuff, and I guess the idea is likely a bit too fancy for wide application. - Sebastian > On Wed, Feb 17, 2016 at 9:27 PM, Sebastian Berg < > sebast...@sipsolutions.net> wrote: > > On Mi, 2016-02-17 at 22:10 +0100, Sebastian Berg wrote: > > > On Mi, 2016-02-17 at 20:48 +0

Re: [Numpy-discussion] making "low" optional in numpy.randint

On Mi, 2016-02-17 at 22:10 +0100, Sebastian Berg wrote: > On Mi, 2016-02-17 at 20:48 +, Robert Kern wrote: > > On Wed, Feb 17, 2016 at 8:43 PM, G Young <gfyoun...@gmail.com> > > wrote: > > > > > Josef: I don't think we are making people think more. They're

Re: [Numpy-discussion] making "low" optional in numpy.randint

On Mi, 2016-02-17 at 20:48 +, Robert Kern wrote: > On Wed, Feb 17, 2016 at 8:43 PM, G Young wrote: > > > Josef: I don't think we are making people think more. They're all > keyword arguments, so if you don't want to think about them, then you > leave them as the

Re: [Numpy-discussion] PyData Madrid

On Mi, 2016-02-17 at 20:59 +0100, Jaime Fernández del Río wrote: > Hi all, > > I just found out there is a PyData Madrid happening in early April, > and it would feel wrong not to go, it being my hometown and all. > > Aside from the usual "Who else is going? We should meet!" I was also >

Re: [Numpy-discussion] NumPy 1.11.0b3 released.

On Di, 2016-02-16 at 00:13 -0500, josef.p...@gmail.com wrote: > > > On Tue, Feb 16, 2016 at 12:09 AM, wrote: > > > > > > > > > > Or, it forces everyone to watch out for the color of the ducks :) > > > > It's just a number, whether it's python scalar, numpy scalar, 1D

Re: [Numpy-discussion] Subclassing ma.masked_array, code broken after version 1.9

On Mo, 2016-02-15 at 17:06 +, Gutenkunst, Ryan N - (rgutenk) wrote: > Thank Jonathan, > > Good to confirm this isn't something inappropriate I'm doing. I give > up transparency here in my application, so I'll just work around it. > I leave it up to wiser numpy heads as to whether it's worth

Re: [Numpy-discussion] Suggestion: special-case np.array(range(...)) to be faster

On So, 2016-02-14 at 23:41 -0800, Antony Lee wrote: > I wonder whether numpy is using the "old" iteration protocol > (repeatedly calling x[i] for increasing i until StopIteration is > reached?) A quick timing shows that it is indeed slower. > ... actually it's not even clear to me what qualifies

Re: [Numpy-discussion] resizeable arrays using shared memory?

On Sa, 2016-02-06 at 16:56 -0600, Elliot Hallmark wrote: > Hi all, > > I have a program that uses resize-able arrays. I already over > -provision the arrays and use slices, but every now and then the data > outgrows that array and it needs to be resized. > > Now, I would like to have these

Re: [Numpy-discussion] Numpy 1.11.0b1 is out

On Sa, 2016-01-30 at 20:27 +0100, Derek Homeier wrote: > On 27 Jan 2016, at 1:10 pm, Sebastian Berg < > sebast...@sipsolutions.net> wrote: > > > > On Mi, 2016-01-27 at 11:19 +, Nadav Horesh wrote: > > > Why the dot function/method is slower than @ on pyth

Re: [Numpy-discussion] Bump warning stacklevel

On Mi, 2016-01-27 at 17:12 -0500, Benjamin Root wrote: > I like the idea of bumping the stacklevel in principle, but I am not > sure it is all that practical. For example, if a warning came up when > doing "x / y", I am assuming that it is emitted from within the ufunc > np.divide(). So, you

[Numpy-discussion] Bump warning stacklevel

Hi all, in my PR about warnings suppression, I currently also have a commit which bumps the warning stacklevel to two (or three), i.e. use: warnings.warn(..., stacklevel=2) (almost) everywhere. This means that for example (take only the empty warning): np.mean([]) would not print:

Re: [Numpy-discussion] Numpy 1.11.0b1 is out

On Mi, 2016-01-27 at 11:19 +, Nadav Horesh wrote: > Why the dot function/method is slower than @ on python 3.5.1? Tested > from the latest 1.11 maintenance branch. > The explanation I think is that you do not have a blas optimization. In which case the fallback mode is probably faster in the

Re: [Numpy-discussion] Inconsistent behavior for ufuncs in numpy v1.10.X

On Di, 2016-01-26 at 17:27 +, Solbrig,Jeremy wrote: > Hello Chuck, > > I receive the same result with 1.10.4. I agree that it looks like > __array_prepare__, __array_finalize__, and __array_wrap__ have not > been changed. I’m starting to dig into the source again, but > focusing on the

[Numpy-discussion] Testing warnings

Hi all, so I have been thinking about this a little more, and I do not think there is a truly nice solution to the python bug: http://bugs.python.org/issue4180 (does not create problems for new pythons). However, I have been so annoyed by trying to test FutureWarnings or DeprecationWarnings in

Re: [Numpy-discussion] Make as_strided result writeonly

On Mo, 2016-01-25 at 16:11 +0100, Sturla Molden wrote: > On 23/01/16 22:25, Sebastian Berg wrote: > > > Do you agree with this, or would it be a major inconvenience? > > I think any user of as_strided should be considered a power user. > This > is an inherently dang

Re: [Numpy-discussion] Make as_strided result writeonly

have experience of beeing badly bitten, myself. Would you think it is fine if setting the flag to true would work in your case? > On Sun, Jan 24, 2016 at 8:17 PM, Sebastian Berg <sebast...@sipsolutions.net> > wrote: > > > On So, 2016-01-24 at 13:00 +1100, Juan Nunez-Iglesi

Re: [Numpy-discussion] Make as_strided result writeonly

om> > wrote: > > On Sat, Jan 23, 2016 at 1:25 PM, Sebastian Berg > > <sebast...@sipsolutions.net> wrote: > > > > > > Hi all, > > > > > > I have just opened a PR, to make as_strided writeonly (as > > default). The > > >

[Numpy-discussion] Make as_strided result writeonly

Hi all, I have just opened a PR, to make as_strided writeonly (as default). The reasoning for this change is that an `as_strided` array often have self overlapping memory. However, writing to an array where multiple elements have the identical memory address can be confusing, and the results are

Re: [Numpy-discussion] Behavior of np.random.uniform

On Do, 2016-01-21 at 09:38 +, Robert Kern wrote: > On Tue, Jan 19, 2016 at 5:35 PM, Sebastian Berg < > sebast...@sipsolutions.net> wrote: > > > > On Di, 2016-01-19 at 16:28 +, G Young wrote: > > > In rand range, it raises an exception if low >=

[Numpy-discussion] Set FutureWarnings to error in (dev) tests?

Hi all, should we try to set FutureWarnings to errors in dev tests? I am seriously annoyed by FutureWarnings getting lost all over for two reasons. First, it is hard to impossible to find even our own errors for our own FutureWarning changes. Secondly, we currently would not even see any

Re: [Numpy-discussion] Set FutureWarnings to error in (dev) tests?

On Do, 2016-01-21 at 16:15 -0800, Nathaniel Smith wrote: > On Thu, Jan 21, 2016 at 4:05 PM, Sebastian Berg > <sebast...@sipsolutions.net> wrote: > > Hi all, > > > > should we try to set FutureWarnings to errors in dev tests? I am > > seriously annoyed by

Re: [Numpy-discussion] Set FutureWarnings to error in (dev) tests?

oh noe not ignore! which also still prints other warnings. - sebastian > On Jan 21, 2016 5:00 PM, "Sebastian Berg" <sebast...@sipsolutions.net > > wrote: > > On Do, 2016-01-21 at 16:51 -0800, Nathaniel Smith wrote: > > > On Thu, Jan 21, 2016 at 4:44 PM, Sebasti

Re: [Numpy-discussion] Set FutureWarnings to error in (dev) tests?

On Do, 2016-01-21 at 16:51 -0800, Nathaniel Smith wrote: > On Thu, Jan 21, 2016 at 4:44 PM, Sebastian Berg > <sebast...@sipsolutions.net> wrote: > > On Do, 2016-01-21 at 16:15 -0800, Nathaniel Smith wrote: > > > On Thu, Jan 21, 2016 at 4:05 PM, Sebastian Berg > &

Re: [Numpy-discussion] Behavior of np.random.uniform

On Di, 2016-01-19 at 16:28 +, G Young wrote: > In rand range, it raises an exception if low >= high. > > I should also add that AFAIK enforcing low >= high with floats is a > lot trickier than it is for integers. I have been knee-deep in > corner cases for some time with randint where

Re: [Numpy-discussion] Get rid of special scalar arithmetic

On Mi, 2016-01-13 at 10:33 -0500, Marten van Kerkwijk wrote: > Just thought I would add here a general comment I made in the thread: > replacing scalars everywhere with array scalars (i.e., ndim=0) would > be great also from the perspective of ndarray subclasses; as is, it > is quite annoying to

Re: [Numpy-discussion] ENH: Add the function 'expand_view'

On Do, 2016-01-07 at 22:48 -0500, John Kirkham wrote: > First, off sorry for the long turnaround on responding to these > questions. Below I have tried to respond to everyone's questions and > comments. I have restructured the order of the messages so that my > responses are a little more

Re: [Numpy-discussion] Proposal for a new function: np.moveaxis

Just a heads up, I am planning to put in Stephans pull request (more info, see original mail below) as soon as some minor things are cleared. So if you have any objections or better ideas for the name, now is the time. - Sebastian On Mi, 2015-11-04 at 23:42 -0800, Stephan Hoyer wrote: > I've

Re: [Numpy-discussion] what would you expect A[none] to do?

On Do, 2015-12-31 at 11:36 -0500, Neal Becker wrote: > Neal Becker wrote: > > > In my case, what it does is: > > > > A.shape = (5760,) > > A[none] -> (1, 5760) > > > > In my case, use of none here is just a mistake. But why would you > > want > > this to be accepted at all, and how should it

Re: [Numpy-discussion] How to find indices of values in an array (indirect in1d) ?

On Mi, 2015-12-30 at 17:12 +0100, Nicolas P. Rougier wrote: > Thanks for the quick answers. I think I will go with the .index and > list comprehension. > But if someone finds with a vectorised solution for the numpy 100 > exercises... > Yeah, I doubt you can get very pretty, though maybe there

  1   2   3   4   5   >