Re: [Numpy-discussion] numpy.mean still broken for largefloat32arrays

On Fri, Jul 25, 2014 at 4:25 PM, RayS wrote: > At 11:29 AM 7/25/2014, you wrote: > >On Fri, Jul 25, 2014 at 5:56 PM, RayS wrote: > > > The important point was that it would be best if all of the > > methods affected > > > by summing 32 bit floats with 32 bit accumulators had the same Notes as >

Re: [Numpy-discussion] numpy.mean still broken for largefloat32arrays

On Sat, Jul 26, 2014 at 9:57 AM, Benjamin Root wrote: > I could get behind the context manager approach. It would help keep > backwards compatibility, while providing a very easy (and clean) way of > consistently using the same reduction operation. Adding kwargs is just a > road to hell. > Would

Re: [Numpy-discussion] numpy.mean still broken for largefloat32arrays

On Sat, Jul 26, 2014 at 2:44 PM, Benjamin Root wrote: > That is one way of doing it, and probably the cleanest way. Or else you > have to pass in the context object everywhere anyway. But I am not so > concerned about that (we do that for other things as well). Bigger concerns > would be nested c

Re: [Numpy-discussion] numpy.mean still broken for largefloat32arrays

On Sat, Jul 26, 2014 at 5:19 PM, Sturla Molden wrote: > Robert Kern wrote: > > >> It would presumably require a global threading.RLock for protecting the > >> global state. > > > > We would use thread-local storage like we currently do with the > > np.errstate() context manager. Each thread will

Re: [Numpy-discussion] numpy.mean still broken for largefloat32arrays

On Sun, Jul 27, 2014 at 4:24 AM, Robert Kern wrote: > On Sun, Jul 27, 2014 at 7:04 AM, wrote: > > > > On Sat, Jul 26, 2014 at 5:19 PM, Sturla Molden > > wrote: > >> > >> Robert Kern wrote: > >> > >> >> It would presumably require a global threading.RLock for protecting > the > >> >> global st

[Numpy-discussion] inplace unary operations?

Is there a way to negate a boolean, or to change the sign of a float inplace ? Josef random thoughts ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] inplace unary operations?

On Sat, Aug 30, 2014 at 1:45 PM, Nathaniel Smith wrote: > On Sat, Aug 30, 2014 at 6:43 PM, wrote: > > Is there a way to negate a boolean, or to change the sign of a float > inplace > > ? > > np.logical_not(arr, out=arr) > np.negative(arr, out=arr) > Thanks Nathaniel. np.negative might save a

Re: [Numpy-discussion] SFMT (faster mersenne twister)

On Sun, Sep 7, 2014 at 4:23 PM, Sturla Molden wrote: > Benjamin Root wrote: > > In addition to issues with reproducibility, think of all of the unit > tests > > that would break! > > That is a reproducibility problem :) > > ___ > NumPy-Discussion maili

Re: [Numpy-discussion] Generalize hstack/vstack --> stack; Block matrices like in matlab

On Mon, Sep 8, 2014 at 10:41 AM, Sturla Molden wrote: > Stefan Otte wrote: > > > stack([[a, b], [c, d]]) > > > > In my case `stack` replaced `hstack` and `vstack` almost completely. > > > > If you're interested in including it in numpy I created a pull request > > [1]. I'm looking forward to

Re: [Numpy-discussion] Generalize hstack/vstack --> stack; Block matrices like in matlab

On Mon, Sep 8, 2014 at 12:10 PM, Jaime Fernández del Río < jaime.f...@gmail.com> wrote: > On Mon, Sep 8, 2014 at 7:41 AM, Sturla Molden > wrote: > >> Stefan Otte wrote: >> >> > stack([[a, b], [c, d]]) >> > >> > In my case `stack` replaced `hstack` and `vstack` almost completely. >> > >> > If

Re: [Numpy-discussion] Generalize hstack/vstack --> stack; Block matrices like in matlab

On Tue, Sep 9, 2014 at 5:42 AM, Stefan Otte wrote: > Hey, > > @Josef, I wasn't aware of `bmat` and `np.asarray(np.bmat())` does > basically what I want and what I'm already using. > I never needed any tetris or anything similar except for the matched block version. Just to point out two mor

Re: [Numpy-discussion] Generalize hstack/vstack --> stack; Block matrices like in matlab

On Tue, Sep 9, 2014 at 8:30 AM, wrote: > > > > On Tue, Sep 9, 2014 at 5:42 AM, Stefan Otte wrote: > >> Hey, >> >> @Josef, I wasn't aware of `bmat` and `np.asarray(np.bmat())` does >> basically what I want and what I'm already using. >> > > I never needed any tetris or anything similar except

Re: [Numpy-discussion] Linear algebra functions on empty arrays

On Mon, Sep 15, 2014 at 5:48 AM, Sebastian Berg wrote: > Hey all, > > for https://github.com/numpy/numpy/pull/3861/files I would like to allow > 0-sized dimensions for generalized ufuncs, meaning that the gufunc has > to be able to handle this, but also that it *can* handle it at all. > However la

Re: [Numpy-discussion] Linear algebra functions on empty arrays

On Mon, Sep 15, 2014 at 7:26 AM, Sebastian Berg wrote: > On Mo, 2014-09-15 at 07:07 -0400, josef.p...@gmail.com wrote: >> On Mon, Sep 15, 2014 at 5:48 AM, Sebastian Berg >> wrote: >> > Hey all, >> > >> > for https://github.com/numpy/numpy/pull/3861/files I would like to allow >> > 0-sized dimensi

Re: [Numpy-discussion] Is this a bug?

On Tue, Sep 16, 2014 at 3:42 PM, Nathaniel Smith wrote: > On Tue, Sep 16, 2014 at 3:27 PM, Charles R Harris > wrote: >> Hi All, >> >> It turns out that gufuncs will broadcast the last dimension if it is one. >> For instance, inner1d has signature `(n), (n) -> ()`, yet >> >> In [27]: inner1d([1,1,

Re: [Numpy-discussion] Request for enhancement to numpy.random.shuffle

On Sun, Oct 12, 2014 at 10:54 AM, Warren Weckesser wrote: > > > On Sun, Oct 12, 2014 at 7:57 AM, Robert Kern wrote: >> >> On Sat, Oct 11, 2014 at 11:51 PM, Warren Weckesser >> wrote: >> >> > A small wart in this API is the meaning of >> > >> > shuffle(a, independent=False, axis=None) >> > >> >

Re: [Numpy-discussion] Request for enhancement to numpy.random.shuffle

On Sun, Oct 12, 2014 at 11:33 AM, Warren Weckesser wrote: > > > On Sun, Oct 12, 2014 at 11:20 AM, wrote: >> >> On Sun, Oct 12, 2014 at 10:54 AM, Warren Weckesser >> wrote: >> > >> > >> > On Sun, Oct 12, 2014 at 7:57 AM, Robert Kern >> > wrote: >> >> >> >> On Sat, Oct 11, 2014 at 11:51 PM, Warre

Re: [Numpy-discussion] Request for enhancement to numpy.random.shuffle

On Sun, Oct 12, 2014 at 12:14 PM, Warren Weckesser wrote: > > > On Sat, Oct 11, 2014 at 6:51 PM, Warren Weckesser > wrote: >> >> I created an issue on github for an enhancement >> to numpy.random.shuffle: >> https://github.com/numpy/numpy/issues/5173 >> I'd like to get some feedback on the id

Re: [Numpy-discussion] Request for enhancement to numpy.random.shuffle

On Thu, Oct 16, 2014 at 3:39 PM, Nathaniel Smith wrote: > On Thu, Oct 16, 2014 at 6:30 PM, Warren Weckesser > wrote: >> >> >> On Thu, Oct 16, 2014 at 12:40 PM, Nathaniel Smith wrote: >>> >>> On Thu, Oct 16, 2014 at 4:39 PM, Warren Weckesser >>> wrote: >>> > >>> > On Sun, Oct 12, 2014 at 9:13 PM

Re: [Numpy-discussion] Request for enhancement to numpy.random.shuffle

On Thu, Oct 16, 2014 at 10:50 PM, Nathaniel Smith wrote: > On Fri, Oct 17, 2014 at 2:35 AM, wrote: >> On Thu, Oct 16, 2014 at 3:39 PM, Nathaniel Smith wrote: >>> On Thu, Oct 16, 2014 at 6:30 PM, Warren Weckesser >>> wrote: On Thu, Oct 16, 2014 at 12:40 PM, Nathaniel Smith wrote

Re: [Numpy-discussion] Choosing between NumPy and SciPy functions

On Mon, Oct 27, 2014 at 2:24 PM, Eelco Hoogendoorn < hoogendoorn.ee...@gmail.com> wrote: > The same occurred to me when reading that question. My personal opinion is > that such functionality should be deprecated from numpy. I don't know who > said this, but it really stuck with me: but the power

Re: [Numpy-discussion] Choosing between NumPy and SciPy functions

On Mon, Oct 27, 2014 at 10:50 PM, Sturla Molden wrote: > wrote: > > > For fft I use mostly scipy, IIRC. (scipy's fft imports numpy's fft, > > partially?) > > No. SciPy uses the Fortran library FFTPACK (wrapped with f2py) and NumPy > uses a smaller C library called fftpack_lite. Algorithmically

Re: [Numpy-discussion] Choosing between NumPy and SciPy functions

On Mon, Oct 27, 2014 at 11:31 PM, wrote: > > > On Mon, Oct 27, 2014 at 10:50 PM, Sturla Molden > wrote: > >> wrote: >> >> > For fft I use mostly scipy, IIRC. (scipy's fft imports numpy's fft, >> > partially?) >> >> No. SciPy uses the Fortran library FFTPACK (wrapped with f2py) and NumPy >> us

Re: [Numpy-discussion] Choosing between NumPy and SciPy functions

On Fri, Oct 31, 2014 at 11:07 AM, Benjamin Root wrote: > Just to throw in my two cents here. I feel that sometimes, features are > tried out first elsewhere (possibly in scipy) and then brought down into > numpy after sufficient shakedown time. So, in some cases, I wonder if the > numpy version i

Re: [Numpy-discussion] simple reduction question

On Wed, Dec 24, 2014 at 10:30 AM, Julian Taylor < jtaylor.deb...@googlemail.com> wrote: > On 24.12.2014 16:25, Neal Becker wrote: > > What would be the most efficient way to compute: > > > > c[j] = \sum_i (a[i] * b[i,j]) > > > > where a[i] is a 1-d vector, b[i,j] is a 2-d array? > > > > This seems

Re: [Numpy-discussion] The future of ndarray.diagonal()

On Mon, Jan 5, 2015 at 4:08 AM, Konrad Hinsen wrote: > --On 5 janvier 2015 08:43:45 + Sturla Molden > wrote: > > > To me it seems that algorithms in scientific papers and books are > > described in various forms of pseudo-code. > > That's indeed what people do when they write a paper about a

Re: [Numpy-discussion] The future of ndarray.diagonal()

On Mon, Jan 5, 2015 at 11:13 AM, Alan G Isaac wrote: > On 1/5/2015 10:48 AM, josef.p...@gmail.com wrote: > > Dtypes are a mess (in terms of code compatibility). Matlab is much > nicer, it's all just doubles. > > > 1. Thank goodness for dtypes. > 2. http://www.mathworks.com/help/matlab/numeric-typ

Re: [Numpy-discussion] Characteristic of a Matrix.

On Mon, Jan 5, 2015 at 1:58 PM, Nathaniel Smith wrote: > I'm afraid that I really don't understand what you're trying to say. Is > there something that you think numpy should be doing differently? > I liked it better when this raised an exception, instead of creating a rectangular object array.

Re: [Numpy-discussion] Characteristic of a Matrix.

On Mon, Jan 5, 2015 at 2:36 PM, Nathaniel Smith wrote: > On Mon, Jan 5, 2015 at 7:18 PM, wrote: > > > > > > > > On Mon, Jan 5, 2015 at 1:58 PM, Nathaniel Smith wrote: > >> > >> I'm afraid that I really don't understand what you're trying to say. Is > there something that you think numpy should

Re: [Numpy-discussion] Any interest in a 'heaviside' ufunc?

On Wed, Feb 4, 2015 at 12:18 AM, Warren Weckesser < warren.weckes...@gmail.com> wrote: > > > On Tue, Feb 3, 2015 at 11:14 PM, Sturla Molden > wrote: > >> Warren Weckesser wrote: >> >> > 0if x < 0 >> > heaviside(x) = 0.5 if x == 0 >> > 1if x >

[Numpy-discussion] suggestion: improve text of failing test

The assert_allclose text is not precise enough to be helpful to fix a test failure that cannot be replicated on every machine, and we cannot just quickly grab --pdb-failures. By how much do I have to lower the precision to make it pass on this continuous integration machine? assert_allclose(he,

Re: [Numpy-discussion] suggestion: improve text of failing test

On Thu, Feb 5, 2015 at 3:39 PM, Nathaniel Smith wrote: > On 5 Feb 2015 12:15, wrote: > > > > The assert_allclose text is not precise enough to be helpful to fix a > test failure that cannot be replicated on every machine, and we cannot just > quickly grab --pdb-failures. > > > > By how much do I

Re: [Numpy-discussion] Silent Broadcasting considered harmful

On Sun, Feb 8, 2015 at 4:08 PM, Eelco Hoogendoorn wrote: >> I personally use Octave and/or Numpy for several years now and never ever >> needed braodcasting. > But since it is still there there will be many users who need it, there will > be some use for it. > > Uhm, yeah, there is some use for i

Re: [Numpy-discussion] Silent Broadcasting considered harmful

On Sun, Feb 8, 2015 at 4:56 PM, Matthew Brett wrote: > Hi, > > On Sun, Feb 8, 2015 at 1:39 PM, Simon Wood wrote: >> >> >> On Sun, Feb 8, 2015 at 4:24 PM, Stefan Reiterer wrote: >>> >>> I don't think this is a good comparison, especially since broadcasting is >>> a feature not a necessity ... >>>

Re: [Numpy-discussion] Silent Broadcasting considered harmful

On Sun, Feb 8, 2015 at 5:17 PM, Stefan Reiterer wrote: > Actually I use numpy for several years now, and I love it. > The reason that I think silent broadcasting of sums is bad > comes simply from the fact, that I had more trouble with it, than it helped > me. > > I won't stop using numpy because

Re: [Numpy-discussion] Silent Broadcasting considered harmful

On Sun, Feb 8, 2015 at 7:12 PM, Eric Firing wrote: > On 2015/02/08 12:43 PM, josef.p...@gmail.com wrote: > >> >> For me the main behavior I had to adjust to was loosing a dimension in >> any reduce operation, mean, sum, ... >> >> if x is 2d >> x - x.mean(1) >> we loose a dimension, and it doesn't

Re: [Numpy-discussion] Matrix Class

On Wed, Feb 11, 2015 at 4:18 PM, Ryan Nelson wrote: > Colin, > > I currently use Py3.4 and Numpy 1.9.1. However, I built a quick test conda > environment with Python2.7 and Numpy 1.7.0, and I get the same: > > > Python 2.7.9 |Continuum Analytics, Inc.| (default, Dec 18 2014, 16:57:52)

Re: [Numpy-discussion] Matrix Class

On Sat, Feb 14, 2015 at 12:05 PM, cjw wrote: > > On 14-Feb-15 11:35 AM, josef.p...@gmail.com wrote: >> >> On Wed, Feb 11, 2015 at 4:18 PM, Ryan Nelson >> wrote: >>> >>> Colin, >>> >>> I currently use Py3.4 and Numpy 1.9.1. However, I built a quick test >>> conda >>> environment with Python2.7 and

Re: [Numpy-discussion] Matrix Class

On Sat, Feb 14, 2015 at 4:27 PM, Charles R Harris wrote: > > > On Sat, Feb 14, 2015 at 12:36 PM, wrote: >> >> On Sat, Feb 14, 2015 at 12:05 PM, cjw wrote: >> > >> > On 14-Feb-15 11:35 AM, josef.p...@gmail.com wrote: >> >> >> >> On Wed, Feb 11, 2015 at 4:18 PM, Ryan Nelson >> >> wrote: >> >>> >>

Re: [Numpy-discussion] Adding keyword to asarray and asanyarray.

On Thu, Mar 5, 2015 at 12:33 PM, Charles R Harris wrote: > > > On Thu, Mar 5, 2015 at 10:04 AM, Chris Barker wrote: >> >> On Thu, Mar 5, 2015 at 8:42 AM, Benjamin Root wrote: >>> >>> dare I say... datetime64/timedelta64 support? >> >> >> well, the precision of those is 64 bits, yes? so if you as

Re: [Numpy-discussion] Adding keyword to asarray and asanyarray.

On Fri, Mar 6, 2015 at 7:59 AM, Charles R Harris wrote: > > > On Thu, Mar 5, 2015 at 10:02 PM, wrote: >> >> On Thu, Mar 5, 2015 at 12:33 PM, Charles R Harris >> wrote: >> > >> > >> > On Thu, Mar 5, 2015 at 10:04 AM, Chris Barker >> > wrote: >> >> >> >> On Thu, Mar 5, 2015 at 8:42 AM, Benjamin R

[Numpy-discussion] MKL ValueError: On entry to DLASCL parameter number 5 had an illegal value

I got a illegal value message using MKL on Windows 64 while running the statsmodels test suite. Kevin is getting the same with more information, which indicates that it might be numpy.linalg.svd https://github.com/statsmodels/statsmodels/issues/2308#issuecomment-78086656 Is this serious? I'm jus

Re: [Numpy-discussion] MKL ValueError: On entry to DLASCL parameter number 5 had an illegal value

On Tue, Mar 10, 2015 at 1:20 PM, Charles R Harris wrote: > > > On Tue, Mar 10, 2015 at 10:33 AM, wrote: > >> >> I got a illegal value message using MKL on Windows 64 while running the >> statsmodels test suite. >> >> Kevin is getting the same with more information, which indicates that it >> mig

Re: [Numpy-discussion] Behavior of np.random.multivariate_normal with bad covariance matrices

On Sun, Mar 29, 2015 at 7:39 PM, Blake Griffith wrote: > I have an open PR which lets users control the checks on the input > covariance matrix. The matrix is required to be symmetric and positve > semi-definite (PSD). The current behavior is that NumPy raises a warning if > the matrix is not PSD,

Re: [Numpy-discussion] IDE's for numpy development?

On Wed, Apr 1, 2015 at 12:04 PM, Charles R Harris wrote: > Hi All, > > In a recent exchange Mark Wiebe suggested that the lack of support for numpy > development in Visual Studio might limit the number of developers attracted > to the project. I'm a vim/console developer myself and make no claim o

Re: [Numpy-discussion] Adding 'where' to ufunc methods?

On Wed, Apr 1, 2015 at 3:47 PM, Nathaniel Smith wrote: > On Wed, Apr 1, 2015 at 11:34 AM, Jaime Fernández del Río > wrote: >> This question on StackOverflow: >> >> http://stackoverflow.com/questions/29394377/minimum-of-numpy-array-ignoring-diagonal >> >> Got me thinking that I had finally found a

Re: [Numpy-discussion] Advanced indexing: "fancy" vs. orthogonal

On Thu, Apr 2, 2015 at 2:03 PM, Eric Firing wrote: > On 2015/04/02 4:15 AM, Jaime Fernández del Río wrote: >> We probably need more traction on the "should this be done?" discussion >> than on the "can this be done?" one, the need for a reordering of the >> axes swings me slightly in favor, but I

Re: [Numpy-discussion] Advanced indexing: "fancy" vs. orthogonal

On Thu, Apr 2, 2015 at 8:02 PM, Eric Firing wrote: > On 2015/04/02 1:14 PM, Hanno Klemm wrote: >> Well, I have written quite a bit of code that relies on fancy >> indexing, and I think the question, if the behaviour of the [] >> operator should be changed has sailed with numpy now at version 1.9.

Re: [Numpy-discussion] Advanced indexing: "fancy" vs. orthogonal

On Thu, Apr 2, 2015 at 9:09 PM, wrote: > On Thu, Apr 2, 2015 at 8:02 PM, Eric Firing wrote: >> On 2015/04/02 1:14 PM, Hanno Klemm wrote: >>> Well, I have written quite a bit of code that relies on fancy >>> indexing, and I think the question, if the behaviour of the [] >>> operator should be cha

Re: [Numpy-discussion] Advanced indexing: "fancy" vs. orthogonal

On Thu, Apr 2, 2015 at 10:30 PM, Matthew Brett wrote: > Hi, > > On Thu, Apr 2, 2015 at 6:09 PM, wrote: >> On Thu, Apr 2, 2015 at 8:02 PM, Eric Firing wrote: >>> On 2015/04/02 1:14 PM, Hanno Klemm wrote: Well, I have written quite a bit of code that relies on fancy indexing, and I thin

Re: [Numpy-discussion] Advanced indexing: "fancy" vs. orthogonal

On Thu, Apr 2, 2015 at 11:30 PM, Nathaniel Smith wrote: > On Thu, Apr 2, 2015 at 6:35 PM, wrote: >> (I thought about this because I was looking at accessing off-diagonal >> elements, m2[np.arange(4), np.arange(4) + 1] ) > > Psst: np.diagonal(m2, offset=1) It was just an example (banded or toep

Re: [Numpy-discussion] On responding to dubious ideas (was: Re: Advanced indexing: "fancy" vs. orthogonal)

On Wed, Apr 8, 2015 at 1:38 PM, Robert Kern wrote: > On Wed, Apr 8, 2015 at 2:06 AM, Nathaniel Smith wrote: >> >> On Apr 5, 2015 7:04 AM, "Robert Kern" wrote: >> > >> > On Sat, Apr 4, 2015 at 10:38 PM, Nathaniel Smith wrote: >> > > >> > > On Apr 4, 2015 4:12 AM, "Todd" wrote: >> > > > >> > > >

Re: [Numpy-discussion] On responding to dubious ideas (was: Re: Advanced indexing: "fancy" vs. orthogonal)

On Thu, Apr 9, 2015 at 10:11 AM, Alan G Isaac wrote: > > Alan wrote: >>> 3. I admit, my students are NOT using non-boolen fancy indexing on >>> >multidimensional arrays. (As far as I know.) Are yours? The only confusing case is mixing slices and integer array indexing for ndim > 2. The rest loo

Re: [Numpy-discussion] ANN: HDF5 for Python 2.5.0

On Thu, Apr 9, 2015 at 2:41 PM, Nathaniel Smith wrote: > (Off-list) > > Congrats! Also btw, you might want to switch to a new subject line format > for these emails -- the mention of Python 2.5 getting hdf5 support made me > do a serious double take before I figured out what was going on, and 2.6

Re: [Numpy-discussion] Consider improving numpy.outer's behavior with zero-dimensional vectors

On Wed, Apr 15, 2015 at 7:35 AM, Neil Girdhar wrote: > Yes, I totally agree. If I get started on the PR to deprecate np.outer, > maybe I can do it as part of the same PR? > > On Wed, Apr 15, 2015 at 4:32 AM, Sebastian Berg > wrote: >> >> Just a general thing, if someone has a few minutes, I thin

Re: [Numpy-discussion] Consider improving numpy.outer's behavior with zero-dimensional vectors

On Wed, Apr 15, 2015 at 5:31 PM, Neil Girdhar wrote: > Does it work for you to set > > outer = np.multiply.outer > > ? > > It's actually faster on my machine. I assume it does because np.corrcoeff uses it, and it's the same type of use cases. However, I'm not using it very often (I prefer broadca

Re: [Numpy-discussion] Consider improving numpy.outer's behavior with zero-dimensional vectors

On Wed, Apr 15, 2015 at 6:08 PM, wrote: > On Wed, Apr 15, 2015 at 5:31 PM, Neil Girdhar wrote: >> Does it work for you to set >> >> outer = np.multiply.outer >> >> ? >> >> It's actually faster on my machine. > > I assume it does because np.corrcoeff uses it, and it's the same type > of use cases

Re: [Numpy-discussion] Consider improving numpy.outer's behavior with zero-dimensional vectors

On Wed, Apr 15, 2015 at 6:40 PM, Nathaniel Smith wrote: > On Wed, Apr 15, 2015 at 6:08 PM, wrote: >> On Wed, Apr 15, 2015 at 5:31 PM, Neil Girdhar wrote: >>> Does it work for you to set >>> >>> outer = np.multiply.outer >>> >>> ? >>> >>> It's actually faster on my machine. >> >> I assume it doe

Re: [Numpy-discussion] Consider improving numpy.outer's behavior with zero-dimensional vectors

On Fri, Apr 17, 2015 at 10:07 AM, Sebastian Berg wrote: > On Do, 2015-04-16 at 15:28 -0700, Matthew Brett wrote: >> Hi, >> > >> >> So, how about a slight modification of your proposal? >> >> 1) Raise deprecation warning for np.outer for non 1D arrays for a few >> versions, with depraction in favo

Re: [Numpy-discussion] Consider improving numpy.outer's behavior with zero-dimensional vectors

On Fri, Apr 17, 2015 at 10:59 AM, Sebastian Berg wrote: > On Fr, 2015-04-17 at 10:47 -0400, josef.p...@gmail.com wrote: >> On Fri, Apr 17, 2015 at 10:07 AM, Sebastian Berg >> wrote: >> > On Do, 2015-04-16 at 15:28 -0700, Matthew Brett wrote: >> >> Hi, >> >> >> > >> >> >> >> So, how about a sligh

Re: [Numpy-discussion] Consider improving numpy.outer's behavior with zero-dimensional vectors

Neil, please reply inline or at the bottom which is customary for numpy scipy related mailing lists. It's sometimes difficult to figure out what the context of your reply is. (and the context is all over the place) On Fri, Apr 17, 2015 at 11:30 AM, Neil Girdhar wrote: > This relationship between

Re: [Numpy-discussion] Consider improving numpy.outer's behavior with zero-dimensional vectors

On Fri, Apr 17, 2015 at 11:22 AM, Neil Girdhar wrote: > > > On Fri, Apr 17, 2015 at 10:47 AM, wrote: >> >> On Fri, Apr 17, 2015 at 10:07 AM, Sebastian Berg >> wrote: >> > On Do, 2015-04-16 at 15:28 -0700, Matthew Brett wrote: >> >> Hi, >> >> >> > >> >> >> >> So, how about a slight modification

Re: [Numpy-discussion] Consider improving numpy.outer's behavior with zero-dimensional vectors

On Fri, Apr 17, 2015 at 12:16 PM, Neil Girdhar wrote: > > > On Fri, Apr 17, 2015 at 12:09 PM, wrote: >> >> On Fri, Apr 17, 2015 at 11:22 AM, Neil Girdhar >> wrote: >> > >> > >> > On Fri, Apr 17, 2015 at 10:47 AM, wrote: >> >> >> >> On Fri, Apr 17, 2015 at 10:07 AM, Sebastian Berg >> >> wrote:

Re: [Numpy-discussion] Consider improving numpy.outer's behavior with zero-dimensional vectors

On Fri, Apr 17, 2015 at 2:56 PM, Sebastian Berg wrote: > On Fr, 2015-04-17 at 12:40 -0400, josef.p...@gmail.com wrote: >> On Fri, Apr 17, 2015 at 12:16 PM, Neil Girdhar wrote: >> > >> > >> > On Fri, Apr 17, 2015 at 12:09 PM, wrote: >> >> >> >> On Fri, Apr 17, 2015 at 11:22 AM, Neil Girdhar >> >

Re: [Numpy-discussion] Consider improving numpy.outer's behavior with zero-dimensional vectors

On Fri, Apr 17, 2015 at 4:03 PM, Sebastian Berg wrote: > On Fr, 2015-04-17 at 15:18 -0400, josef.p...@gmail.com wrote: >> On Fri, Apr 17, 2015 at 2:56 PM, Sebastian Berg > >> > Hehe, yeah, that difference. But if you really want that, you can >> > usually do a1[0, 1, ...] if you don't mind the ug

[Numpy-discussion] code snippet: assert all close or large

___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] code snippet: assert all close or large

Sorry, hit the wrong key just an example that I think is not covered by numpy.testing assert absolute tolerance for `inf`: "assert x and y are allclose or x is large if y is inf" On Thu, Apr 30, 2015 at 2:24 PM, wrote: > > > def assert_allclose_large(x, y, rtol=1e-6, atol=0, ltol=1e30): "

Re: [Numpy-discussion] binary wheels for numpy?

On Fri, May 15, 2015 at 4:07 PM, Chris Barker wrote: > Hi folks., > > I did a little "intro to scipy" session as part of a larger Python class > the other day, and was dismayed to find that "pip install numpy" still > dosn't work on Windows. > > Thanks mostly to Matthew Brett's work, the whole sc

Re: [Numpy-discussion] Backwards-incompatible improvements to numpy.random.RandomState

On Sun, May 24, 2015 at 9:08 AM, Alan G Isaac wrote: > On 5/24/2015 8:47 AM, Ralf Gommers wrote: > > Values only change if you leave out the call to seed() > > > OK, but this claim seems to conflict with the following language: > "the global RandomState object should use the latest implementation

Re: [Numpy-discussion] Backwards-incompatible improvements to numpy.random.RandomState

On Sun, May 24, 2015 at 11:13 AM, Anne Archibald wrote: > Do we want a deprecation-like approach, so that eventually people who want > replicability will specify versions, and everyone else gets bug fixes and > improvements? This would presumably take several major versions, but it > might avoid

Re: [Numpy-discussion] Backwards-incompatible improvements to numpy.random.RandomState

On Sun, May 24, 2015 at 1:49 PM, Nathaniel Smith wrote: > On May 24, 2015 8:43 AM, wrote: > > > > Reminder: we are bottom or inline posting > > Can we stop hassling people about this? Inline replies are a great tool to > have in your toolkit for complicated technical discussions, but I feel like

Re: [Numpy-discussion] Backwards-incompatible improvements to numpy.random.RandomState

On Sun, May 24, 2015 at 5:09 PM, Antony Lee wrote: > 2015-05-24 13:30 GMT-07:00 Sturla Molden : > >> On 24/05/15 10:22, Antony Lee wrote: >> >> > Comments, and help for writing tests (in particular to make sure >> > backwards compatibility is maintained) are welcome. >> >> I have one comment, and

[Numpy-discussion] checking S versus U dtype

What's the best way to check whether a numpy array is string or bytes on python3? using char? >>> A = np.asarray([[1, 0, 0],['E', 1, 0],['E', 'E', 1]], dtype='>> A array([['1', '0', '0'], ['E', '1', '0'], ['E', 'E', '1']], dtype='>> A.dtype dtype('>> A.dtype.char 'U' >>> A.dt

Re: [Numpy-discussion] DEP: Deprecate boolean array indices with non-matching shape #4353

On Fri, Jun 5, 2015 at 3:16 AM, Sebastian Berg wrote: > On Do, 2015-06-04 at 18:04 -0700, Nathaniel Smith wrote: > > On Thu, Jun 4, 2015 at 5:57 PM, Nathaniel Smith wrote: > > > So specifically the question is -- if you have an array with five > > items, and > > > a Boolean array with three item

Re: [Numpy-discussion] DEP: Deprecate boolean array indices with non-matching shape #4353

On Fri, Jun 5, 2015 at 11:50 AM, Anne Archibald wrote: > > > On Fri, Jun 5, 2015 at 5:45 PM Sebastian Berg > wrote: > >> On Fr, 2015-06-05 at 08:36 -0400, josef.p...@gmail.com wrote: >> > >> >> > >> > What is actually being deprecated? >> > It looks like there are different examples. >> > >> >

Re: [Numpy-discussion] Clarification sought on Scipy Numpy version requirements.

On Fri, Jun 19, 2015 at 4:08 PM, Charles R Harris wrote: > Hi All, > > I'm looking to change some numpy deprecations into errors as well as > remove some deprecated functions. The problem I see is that > SciPy claims to support Numpy >= 1.5 and Numpy 1.5 is really, really, old. > So the question

Re: [Numpy-discussion] Python 3 and isinstance(np.int64(42), int)

On Fri, Jun 19, 2015 at 4:15 PM, Chris Barker wrote: > On Wed, Jun 17, 2015 at 11:13 PM, Nathaniel Smith wrote: > >> there's some >> argument that in Python, doing explicit type checks like this is >> usually a sign that one is doing something awkward, > > > I tend to agree with that. > > On th

[Numpy-discussion] annoying Deprecation warnings about non-integers

I'm trying to fix some code in statsmodels that creates Deprecation Warnings from numpy Most of it are quite easy to fix, mainly cases where we use floats to avoid integer division I have two problems first, I get Deprecation warnings in the test run that don't specify where they happen. I try t

[Numpy-discussion] floats for indexing, reshape - too strict ?

About the deprecation warning for using another type than integers, in ones, reshape, indexing and so on: Wouldn't it be nicer to accept floats that are equal to an integer? for example >>> 5.0 == 5 True >>> np.ones(10 / 2) array([ 1., 1., 1., 1., 1.]) >>> 10 / 2 == 5 True or the python 2

Re: [Numpy-discussion] floats for indexing, reshape - too strict ?

On Wed, Jul 1, 2015 at 10:32 AM, Sebastian Berg wrote: > On Mi, 2015-07-01 at 10:05 -0400, josef.p...@gmail.com wrote: > > About the deprecation warning for using another type than integers, in > > ones, reshape, indexing and so on: > > > > > > Wouldn't it be nicer to accept floats that are equal

Re: [Numpy-discussion] floats for indexing, reshape - too strict ?

On Thu, Jul 2, 2015 at 8:51 PM, Chris Barker - NOAA Federal < chris.bar...@noaa.gov> wrote: > Sent from my iPhone > > > > > The disadvantage I see is, that some weirder calculations would possible > > work most of the times, but not always, > > > > not sure if you can define a "tolerance" > > rea

[Numpy-discussion] difference between dtypes

Is there an explanation somewhere of what different basic dtypes mean, across platforms and python versions? >>> np.bool8 >>> np.bool_ >>> bool Are there any rules and recommendations or is it all folks lore? I'm asking because my intuition picked up by osmosis might be off, and I thought h

Re: [Numpy-discussion] difference between dtypes

On Fri, Jul 24, 2015 at 3:46 AM, Robert Kern wrote: > On Wed, Jul 22, 2015 at 7:45 PM, wrote: > > > > Is there an explanation somewhere of what different basic dtypes mean, > across platforms and python versions? > > > > >>> np.bool8 > > > > >>> np.bool_ > > > > >>> bool > > > > > > > > Are t

Re: [Numpy-discussion] Proposal: Deprecate np.int, np.float, etc.?

On Tue, Aug 4, 2015 at 4:39 AM, Sebastian Berg wrote: > On Mo, 2015-08-03 at 21:32 +0200, Sturla Molden wrote: > > On 03/08/15 20:51, Chris Barker wrote: > > > > > well, IIUC, np.int is the python integer type, which > is > > > a C long in all the implemtations of cPython that I k

Re: [Numpy-discussion] np.in1d() & sets, bug?

On Mon, Aug 10, 2015 at 1:40 PM, Benjamin Root wrote: > > Not really, it is "simply" because ``np.asarray(set([1, 2, 3]))`` > > returns an object array > > Holy crap! To be pedantic, it looks like it turns it into a numpy scalar, > but still! I wouldn't have expected np.asarray() on a set (or dic

Re: [Numpy-discussion] Comments on governance proposal (was: Notes from the numpy dev meeting at scipy 2015)

On Thu, Aug 27, 2015 at 8:57 AM, Matthew Brett wrote: > Hi, > > On Thu, Aug 27, 2015 at 12:11 PM, Sebastian Berg > wrote: > > On Do, 2015-08-27 at 10:45 +0100, Matthew Brett wrote: > >> Hi, > >> > >> On Thu, Aug 27, 2015 at 10:35 AM, Bryan Van de Ven > wrote: > >> > > >> >> On Aug 27, 2015, at

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

On Wed, Aug 26, 2015 at 10:06 AM, Travis Oliphant wrote: > > > On Wed, Aug 26, 2015 at 1:41 AM, Nathaniel Smith wrote: > >> Hi Travis, >> >> Thanks for taking the time to write up your thoughts! >> >> I have many thoughts in return, but I will try to restrict myself to two >> main ones :-). >> >

Re: [Numpy-discussion] Comments on governance proposal (was: Notes from the numpy dev meeting at scipy 2015)

On Thu, Aug 27, 2015 at 11:04 AM, Matthew Brett wrote: > Hi, > > On Thu, Aug 27, 2015 at 3:34 PM, wrote: > [snip] > > I don't really see a problem with "codifying" the status quo. > > That's an excellent point.If we believe that the current situation > is the best possible, both now and in

Re: [Numpy-discussion] Comments on governance proposal (was: Notes from the numpy dev meeting at scipy 2015)

On Thu, Aug 27, 2015 at 12:22 PM, Matthew Brett wrote: > Hi > > On Thu, Aug 27, 2015 at 5:11 PM, wrote: > > > > > > On Thu, Aug 27, 2015 at 11:04 AM, Matthew Brett > > > wrote: > >> > >> Hi, > >> > >> On Thu, Aug 27, 2015 at 3:34 PM, wrote: > >> [snip] > >> > I don't really see a problem wit

Re: [Numpy-discussion] Comments on governance proposal (was: Notes from the numpy dev meeting at scipy 2015)

On Thu, Aug 27, 2015 at 2:06 PM, Matthew Brett wrote: > Hi, > > On Thu, Aug 27, 2015 at 6:23 PM, wrote: > > > > > > On Thu, Aug 27, 2015 at 12:22 PM, Matthew Brett > > > wrote: > >> > >> Hi > >> > >> On Thu, Aug 27, 2015 at 5:11 PM, wrote: > >> > > >> > > >> > On Thu, Aug 27, 2015 at 11:04 A

[Numpy-discussion] meshgrid dtype casting

I'm trying to build a meshgrid with small nonnegative integers default is int32 >>> np.meshgrid([0,1,2], [0,1])[0].dtype dtype('int32') If I use uint, then the arrays are upcast to int64 - Why? >>> np.meshgrid(np.array([0,1,2], np.uint), np.array([0,1], np.uint))[0].dtype dtype('int64') broad

Re: [Numpy-discussion] Comments on governance proposal (was: Notes from the numpy dev meeting at scipy 2015)

On Fri, Sep 4, 2015 at 5:55 PM, Matthew Brett wrote: > Hi, > > On Fri, Sep 4, 2015 at 10:22 PM, Eric Firing wrote: > > On 2015/09/04 10:53 AM, Matthew Brett wrote: > >> On Fri, Sep 4, 2015 at 2:33 AM, Matthew Brett > wrote: > >>> Hi, > >>> > >>> On Wed, Sep 2, 2015 at 5:41 PM, Chris Barker > w

Re: [Numpy-discussion] Comments on governance proposal (was: Notes from the numpy dev meeting at scipy 2015)

On Fri, Sep 4, 2015 at 7:19 PM, Matthew Brett wrote: > On Sat, Sep 5, 2015 at 12:04 AM, wrote: > > > > > > On Fri, Sep 4, 2015 at 5:55 PM, Matthew Brett > > wrote: > >> > >> Hi, > >> > >> On Fri, Sep 4, 2015 at 10:22 PM, Eric Firing > wrote: > >> > On 2015/09/04 10:53 AM, Matthew Brett wrote:

Re: [Numpy-discussion] Governance model request

On Tue, Sep 22, 2015 at 10:55 PM, Bryan Van de Ven wrote: > > > On Sep 22, 2015, at 1:48 PM, Matthew Brett > wrote: > > > > The point is, that a sensible organization and a sensible leader has > > to take the possibility of conflict of interest into account. They > > also have to consider the p

Re: [Numpy-discussion] Sign of NaN

On Tue, Sep 29, 2015 at 11:25 AM, Anne Archibald wrote: > IEEE 754 has signum(NaN)->NaN. So does np.sign on floating-point arrays. > Why should it be different for object arrays? > > Anne > > P.S. If you want exceptions when NaNs appear, that's what np.seterr is > for. -A > I also think NaN sho

Re: [Numpy-discussion] Sign of NaN

On Tue, Sep 29, 2015 at 2:16 PM, Nathaniel Smith wrote: > On Sep 29, 2015 8:25 AM, "Anne Archibald" wrote: > > > > IEEE 754 has signum(NaN)->NaN. So does np.sign on floating-point arrays. > Why should it be different for object arrays? > > The argument for doing it this way would be that arbitra

Re: [Numpy-discussion] Oops - maybe post3 numpy file?

On Thu, Oct 8, 2015 at 8:39 PM, Charles R Harris wrote: > > > On Thu, Oct 8, 2015 at 6:30 PM, Matthew Brett > wrote: > >> Hi, >> >> I'm afraid I made a mistake uploading OSX wheels for numpy 1.10.0. >> Using twine to do the upload generated a new release - 1.10.0.post2 - >> containing only the w

[Numpy-discussion] Bug

___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Bug

Sorry, wrong shortcut key, question will arrive later. Josef On Fri, Oct 16, 2015 at 1:40 PM, wrote: > > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] numpy 1.10.1 reduce operation on recarrays

was there a change with reduce operations with recarrays in 1.10 or 1.10.1? Travis shows a new test failure in the statsmodels testsuite with 1.10.1: ERROR: test suite for File "/home/travis/miniconda/envs/statsmodels-test/lib/python2.7/site-packages/statsmodels-0.8.0-py2.7-linux-x86_64.egg/s

  1   2   >