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

On Fri, Jul 25, 2014 at 4:25 PM, RayS r...@blue-cove.com wrote: At 11:29 AM 7/25/2014, you wrote: On Fri, Jul 25, 2014 at 5:56 PM, RayS r...@blue-cove.com wrote: The important point was that it would be best if all of the methods affected by summing 32 bit floats with 32 bit

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

On Sat, Jul 26, 2014 at 9:57 AM, Benjamin Root ben.r...@ou.edu 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

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

On Sat, Jul 26, 2014 at 2:44 PM, Benjamin Root ben.r...@ou.edu 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

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

On Sat, Jul 26, 2014 at 5:19 PM, Sturla Molden sturla.mol...@gmail.com wrote: Robert Kern robert.k...@gmail.com 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()

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

On Sun, Jul 27, 2014 at 4:24 AM, Robert Kern robert.k...@gmail.com wrote: On Sun, Jul 27, 2014 at 7:04 AM, josef.p...@gmail.com wrote: On Sat, Jul 26, 2014 at 5:19 PM, Sturla Molden sturla.mol...@gmail.com wrote: Robert Kern robert.k...@gmail.com wrote: It would presumably

Re: [Numpy-discussion] inplace unary operations?

On Sat, Aug 30, 2014 at 1:45 PM, Nathaniel Smith n...@pobox.com wrote: On Sat, Aug 30, 2014 at 6:43 PM, josef.p...@gmail.com 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.

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

On Sun, Sep 7, 2014 at 4:23 PM, Sturla Molden sturla.mol...@gmail.com wrote: Benjamin Root ben.r...@ou.edu wrote: In addition to issues with reproducibility, think of all of the unit tests that would break! That is a reproducibility problem :)

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

On Mon, Sep 8, 2014 at 10:41 AM, Sturla Molden sturla.mol...@gmail.com wrote: Stefan Otte stefan.o...@gmail.com 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

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 sturla.mol...@gmail.com wrote: Stefan Otte stefan.o...@gmail.com wrote: stack([[a, b], [c, d]]) In my case `stack` replaced `hstack` and `vstack`

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

On Tue, Sep 9, 2014 at 5:42 AM, Stefan Otte stefan.o...@gmail.com 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

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

On Tue, Sep 9, 2014 at 8:30 AM, josef.p...@gmail.com wrote: On Tue, Sep 9, 2014 at 5:42 AM, Stefan Otte stefan.o...@gmail.com 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

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

On Mon, Sep 15, 2014 at 5:48 AM, Sebastian Berg sebast...@sipsolutions.net 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

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

On Mon, Sep 15, 2014 at 7:26 AM, Sebastian Berg sebast...@sipsolutions.net 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 sebast...@sipsolutions.net wrote: Hey all, for https://github.com/numpy/numpy/pull/3861/files I

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

On Tue, Sep 16, 2014 at 3:42 PM, Nathaniel Smith n...@pobox.com wrote: On Tue, Sep 16, 2014 at 3:27 PM, Charles R Harris charlesr.har...@gmail.com 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

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

On Sun, Oct 12, 2014 at 10:54 AM, Warren Weckesser warren.weckes...@gmail.com wrote: On Sun, Oct 12, 2014 at 7:57 AM, Robert Kern robert.k...@gmail.com wrote: On Sat, Oct 11, 2014 at 11:51 PM, Warren Weckesser warren.weckes...@gmail.com wrote: A small wart in this API is the meaning of

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

On Sun, Oct 12, 2014 at 11:33 AM, Warren Weckesser warren.weckes...@gmail.com wrote: On Sun, Oct 12, 2014 at 11:20 AM, josef.p...@gmail.com wrote: On Sun, Oct 12, 2014 at 10:54 AM, Warren Weckesser warren.weckes...@gmail.com wrote: On Sun, Oct 12, 2014 at 7:57 AM, Robert Kern

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

On Sun, Oct 12, 2014 at 12:14 PM, Warren Weckesser warren.weckes...@gmail.com wrote: On Sat, Oct 11, 2014 at 6:51 PM, Warren Weckesser warren.weckes...@gmail.com wrote: I created an issue on github for an enhancement to numpy.random.shuffle: https://github.com/numpy/numpy/issues/5173

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

On Thu, Oct 16, 2014 at 3:39 PM, Nathaniel Smith n...@pobox.com wrote: On Thu, Oct 16, 2014 at 6:30 PM, Warren Weckesser warren.weckes...@gmail.com wrote: On Thu, Oct 16, 2014 at 12:40 PM, Nathaniel Smith n...@pobox.com wrote: On Thu, Oct 16, 2014 at 4:39 PM, Warren Weckesser

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

On Thu, Oct 16, 2014 at 10:50 PM, Nathaniel Smith n...@pobox.com wrote: On Fri, Oct 17, 2014 at 2:35 AM, josef.p...@gmail.com wrote: On Thu, Oct 16, 2014 at 3:39 PM, Nathaniel Smith n...@pobox.com wrote: On Thu, Oct 16, 2014 at 6:30 PM, Warren Weckesser warren.weckes...@gmail.com wrote: On

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 of

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

On Mon, Oct 27, 2014 at 10:50 PM, Sturla Molden sturla.mol...@gmail.com wrote: josef.p...@gmail.com 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

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

On Mon, Oct 27, 2014 at 11:31 PM, josef.p...@gmail.com wrote: On Mon, Oct 27, 2014 at 10:50 PM, Sturla Molden sturla.mol...@gmail.com wrote: josef.p...@gmail.com wrote: For fft I use mostly scipy, IIRC. (scipy's fft imports numpy's fft, partially?) No. SciPy uses the Fortran

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

On Fri, Oct 31, 2014 at 11:07 AM, Benjamin Root ben.r...@ou.edu 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

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 to be one way:

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 sturla.mol...@gmail.com wrote: Warren Weckesser warren.weckes...@gmail.com wrote: 0if x 0 heaviside(x) = 0.5 if x == 0

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

On Thu, Feb 5, 2015 at 3:39 PM, Nathaniel Smith n...@pobox.com wrote: On 5 Feb 2015 12:15, josef.p...@gmail.com 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

Re: [Numpy-discussion] Silent Broadcasting considered harmful

On Sun, Feb 8, 2015 at 4:08 PM, Eelco Hoogendoorn hoogendoorn.ee...@gmail.com 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,

Re: [Numpy-discussion] Silent Broadcasting considered harmful

On Sun, Feb 8, 2015 at 4:56 PM, Matthew Brett matthew.br...@gmail.com wrote: Hi, On Sun, Feb 8, 2015 at 1:39 PM, Simon Wood sgwoo...@gmail.com wrote: On Sun, Feb 8, 2015 at 4:24 PM, Stefan Reiterer dom...@gmx.net wrote: I don't think this is a good comparison, especially since broadcasting

Re: [Numpy-discussion] Silent Broadcasting considered harmful

On Sun, Feb 8, 2015 at 5:17 PM, Stefan Reiterer dom...@gmx.net 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

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

On Mon, Jan 5, 2015 at 11:13 AM, Alan G Isaac alan.is...@gmail.com 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.

Re: [Numpy-discussion] Matrix Class

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

Re: [Numpy-discussion] Matrix Class

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

[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] Characteristic of a Matrix.

On Mon, Jan 5, 2015 at 1:58 PM, Nathaniel Smith n...@pobox.com 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

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

On Mon, Jan 5, 2015 at 2:36 PM, Nathaniel Smith n...@pobox.com wrote: On Mon, Jan 5, 2015 at 7:18 PM, josef.p...@gmail.com wrote: On Mon, Jan 5, 2015 at 1:58 PM, Nathaniel Smith n...@pobox.com wrote: I'm afraid that I really don't understand what you're trying to say. Is there

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

On Mon, Jan 5, 2015 at 4:08 AM, Konrad Hinsen konrad.hin...@fastmail.net wrote: --On 5 janvier 2015 08:43:45 + Sturla Molden sturla.mol...@gmail.com wrote: To me it seems that algorithms in scientific papers and books are described in various forms of pseudo-code. That's indeed what

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

On Fri, Mar 6, 2015 at 7:59 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Mar 5, 2015 at 10:02 PM, josef.p...@gmail.com wrote: On Thu, Mar 5, 2015 at 12:33 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Mar 5, 2015 at 10:04 AM, Chris Barker

[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

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 charlesr.har...@gmail.com wrote: On Tue, Mar 10, 2015 at 10:33 AM, josef.p...@gmail.com 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

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

On Sun, Mar 29, 2015 at 7:39 PM, Blake Griffith blake.a.griff...@gmail.com 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

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

On Thu, Mar 5, 2015 at 12:33 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Mar 5, 2015 at 10:04 AM, Chris Barker chris.bar...@noaa.gov wrote: On Thu, Mar 5, 2015 at 8:42 AM, Benjamin Root ben.r...@ou.edu wrote: dare I say... datetime64/timedelta64 support? well, the

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

On Thu, Apr 2, 2015 at 2:03 PM, Eric Firing efir...@hawaii.edu 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

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

On Thu, Apr 2, 2015 at 10:30 PM, Matthew Brett matthew.br...@gmail.com wrote: Hi, On Thu, Apr 2, 2015 at 6:09 PM, josef.p...@gmail.com wrote: On Thu, Apr 2, 2015 at 8:02 PM, Eric Firing efir...@hawaii.edu wrote: On 2015/04/02 1:14 PM, Hanno Klemm wrote: Well, I have written quite a bit of

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

On Thu, Apr 2, 2015 at 11:30 PM, Nathaniel Smith n...@pobox.com wrote: On Thu, Apr 2, 2015 at 6:35 PM, josef.p...@gmail.com 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

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

On Thu, Apr 2, 2015 at 9:09 PM, josef.p...@gmail.com wrote: On Thu, Apr 2, 2015 at 8:02 PM, Eric Firing efir...@hawaii.edu 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

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

On Thu, Apr 2, 2015 at 8:02 PM, Eric Firing efir...@hawaii.edu 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

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, josef.p...@gmail.com wrote: def assert_allclose_large(x, y, rtol=1e-6, atol=0,

[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] binary wheels for numpy?

On Fri, May 15, 2015 at 4:07 PM, Chris Barker chris.bar...@noaa.gov 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,

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

On Wed, Apr 15, 2015 at 6:08 PM, josef.p...@gmail.com wrote: On Wed, Apr 15, 2015 at 5:31 PM, Neil Girdhar mistersh...@gmail.com 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

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

On Wed, Apr 15, 2015 at 6:40 PM, Nathaniel Smith n...@pobox.com wrote: On Wed, Apr 15, 2015 at 6:08 PM, josef.p...@gmail.com wrote: On Wed, Apr 15, 2015 at 5:31 PM, Neil Girdhar mistersh...@gmail.com wrote: Does it work for you to set outer = np.multiply.outer ? It's actually faster on

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

On Wed, Apr 15, 2015 at 5:31 PM, Neil Girdhar mistersh...@gmail.com 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

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

On Wed, Apr 15, 2015 at 7:35 AM, Neil Girdhar mistersh...@gmail.com 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 sebast...@sipsolutions.net wrote: Just a general

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

On Fri, Apr 17, 2015 at 10:07 AM, Sebastian Berg sebast...@sipsolutions.net wrote: On Do, 2015-04-16 at 15:28 -0700, Matthew Brett wrote: Hi, snip 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

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

On Fri, Apr 17, 2015 at 10:59 AM, Sebastian Berg sebast...@sipsolutions.net 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 sebast...@sipsolutions.net wrote: On Do, 2015-04-16 at 15:28 -0700, Matthew Brett wrote: Hi,

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

On Fri, Apr 17, 2015 at 12:16 PM, Neil Girdhar mistersh...@gmail.com wrote: On Fri, Apr 17, 2015 at 12:09 PM, josef.p...@gmail.com wrote: On Fri, Apr 17, 2015 at 11:22 AM, Neil Girdhar mistersh...@gmail.com wrote: On Fri, Apr 17, 2015 at 10:47 AM, josef.p...@gmail.com wrote: On

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 mistersh...@gmail.com wrote: This

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

On Fri, Apr 17, 2015 at 2:56 PM, Sebastian Berg sebast...@sipsolutions.net 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 mistersh...@gmail.com wrote: On Fri, Apr 17, 2015 at 12:09 PM, josef.p...@gmail.com wrote: On

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

On Fri, Apr 17, 2015 at 4:03 PM, Sebastian Berg sebast...@sipsolutions.net 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 snip Hehe, yeah, that difference. But if you really want that, you can usually do a1[0, 1, ...] if

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

On Fri, Apr 17, 2015 at 11:22 AM, Neil Girdhar mistersh...@gmail.com wrote: On Fri, Apr 17, 2015 at 10:47 AM, josef.p...@gmail.com wrote: On Fri, Apr 17, 2015 at 10:07 AM, Sebastian Berg sebast...@sipsolutions.net wrote: On Do, 2015-04-16 at 15:28 -0700, Matthew Brett wrote: Hi, snip

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 alan.is...@gmail.com 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.

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

On Thu, Apr 9, 2015 at 2:41 PM, Nathaniel Smith n...@pobox.com 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

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 robert.k...@gmail.com wrote: On Wed, Apr 8, 2015 at 2:06 AM, Nathaniel Smith n...@pobox.com wrote: On Apr 5, 2015 7:04 AM, Robert Kern robert.k...@gmail.com wrote: On Sat, Apr 4, 2015 at 10:38 PM, Nathaniel Smith n...@pobox.com wrote: On Apr

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

On Wed, Apr 1, 2015 at 12:04 PM, Charles R Harris charlesr.har...@gmail.com 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

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

On Wed, Apr 1, 2015 at 3:47 PM, Nathaniel Smith n...@pobox.com wrote: On Wed, Apr 1, 2015 at 11:34 AM, Jaime Fernández del Río jaime.f...@gmail.com wrote: This question on StackOverflow: http://stackoverflow.com/questions/29394377/minimum-of-numpy-array-ignoring-diagonal Got me thinking

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

On Fri, Jun 5, 2015 at 3:16 AM, Sebastian Berg sebast...@sipsolutions.net wrote: On Do, 2015-06-04 at 18:04 -0700, Nathaniel Smith wrote: On Thu, Jun 4, 2015 at 5:57 PM, Nathaniel Smith n...@pobox.com wrote: So specifically the question is -- if you have an array with five items, and a

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

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

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

On Fri, Jun 19, 2015 at 4:15 PM, Chris Barker chris.bar...@noaa.gov wrote: On Wed, Jun 17, 2015 at 11:13 PM, Nathaniel Smith n...@pobox.com 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

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

On Fri, Jun 19, 2015 at 4:08 PM, Charles R Harris charlesr.har...@gmail.com 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,

[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='U1') A array([['1', '0', '0'], ['E', '1', '0'], ['E', 'E', '1']], dtype='U1') A.dtype dtype('U1') A.dtype.char 'U'

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

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

On Wed, Jul 1, 2015 at 10:32 AM, Sebastian Berg sebast...@sipsolutions.net 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

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

[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

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

On Sun, May 24, 2015 at 9:08 AM, Alan G Isaac alan.is...@gmail.com 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

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

On Sun, May 24, 2015 at 1:49 PM, Nathaniel Smith n...@pobox.com wrote: On May 24, 2015 8:43 AM, josef.p...@gmail.com 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

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

On Sun, May 24, 2015 at 11:13 AM, Anne Archibald archib...@astron.nl 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

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

On Sun, May 24, 2015 at 5:09 PM, Antony Lee antony@berkeley.edu wrote: 2015-05-24 13:30 GMT-07:00 Sturla Molden sturla.mol...@gmail.com: 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

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

On Tue, Aug 4, 2015 at 4:39 AM, Sebastian Berg sebast...@sipsolutions.net 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 http://np.int is the python integer type, which is a C long in all the implemtations of

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

On Mon, Aug 10, 2015 at 1:40 PM, Benjamin Root ben.r...@ou.edu 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

[Numpy-discussion] difference between dtypes

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

Re: [Numpy-discussion] difference between dtypes

On Fri, Jul 24, 2015 at 3:46 AM, Robert Kern robert.k...@gmail.com wrote: On Wed, Jul 22, 2015 at 7:45 PM, josef.p...@gmail.com wrote: Is there an explanation somewhere of what different basic dtypes mean, across platforms and python versions? np.bool8 type 'numpy.bool_' np.bool_

Re: [Numpy-discussion] Proposal: stop supporting 'setup.py install'; start requiring 'pip install .' instead

On Tue, Oct 27, 2015 at 3:32 AM, Ralf Gommers wrote: > > > On Tue, Oct 27, 2015 at 8:28 AM, Nathaniel Smith wrote: > >> On Tue, Oct 27, 2015 at 12:19 AM, Ralf Gommers >> wrote: >> > >> > >> > On Tue, Oct 27, 2015 at 6:44 AM,

Re: [Numpy-discussion] Proposal: stop supporting 'setup.py install'; start requiring 'pip install .' instead

On Tue, Oct 27, 2015 at 10:59 AM, Nathaniel Smith wrote: > On Oct 27, 2015 6:08 AM, wrote: > > > [...] > > > > > > What's the equivalent of > > python setup.py build_ext --inplace > > It's > python setup.py build_ext --inplace > > ;-) > Ok, Sorry, I

[Numpy-discussion] Bug

___ 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

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

Re: [Numpy-discussion] when did column_stack become C-contiguous?

On Mon, Oct 19, 2015 at 1:10 AM, Stephan Hoyer wrote: > Looking at the git logs, column_stack appears to have been that way > (creating a new array with concatenate) since at least NumPy 0.9.2, way > back in January 2006: >

[Numpy-discussion] when did column_stack become C-contiguous?

>>> np.column_stack((np.ones(10), np.ones(10))).flags C_CONTIGUOUS : True F_CONTIGUOUS : False >>> np.__version__ '1.9.2rc1' on my notebook which has numpy 1.6.1 it is f_contiguous I was just trying to optimize a loop over variable adjustment in regression, and found out that we lost

Re: [Numpy-discussion] when did column_stack become C-contiguous?

On Mon, Oct 19, 2015 at 1:27 AM, wrote: > > > On Mon, Oct 19, 2015 at 1:10 AM, Stephan Hoyer wrote: > >> Looking at the git logs, column_stack appears to have been that way >> (creating a new array with concatenate) since at least NumPy 0.9.2, way >> back

Re: [Numpy-discussion] when did column_stack become C-contiguous?

On Mon, Oct 19, 2015 at 12:35 AM, wrote: > >>> np.column_stack((np.ones(10), np.ones(10))).flags > C_CONTIGUOUS : True > F_CONTIGUOUS : False > > >>> np.__version__ > '1.9.2rc1' > > > on my notebook which has numpy 1.6.1 it is f_contiguous > > > I was just trying to

Re: [Numpy-discussion] numpy 1.10.1 reduce operation on recarrays

On Fri, Oct 16, 2015 at 2:21 PM, Charles R Harris wrote: > > > On Fri, Oct 16, 2015 at 12:20 PM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> >> >> On Fri, Oct 16, 2015 at 11:58 AM, wrote: >> >>> was there a change with reduce

Re: [Numpy-discussion] when did column_stack become C-contiguous?

On Mon, Oct 19, 2015 at 2:14 AM, Nathaniel Smith wrote: > On Sun, Oct 18, 2015 at 9:35 PM, wrote: > np.column_stack((np.ones(10), np.ones(10))).flags > > C_CONTIGUOUS : True > > F_CONTIGUOUS : False > > > np.__version__ > > '1.9.2rc1' > > > >

Re: [Numpy-discussion] when did column_stack become C-contiguous?

On Mon, Oct 19, 2015 at 5:16 AM, Sebastian Berg wrote: > On Mo, 2015-10-19 at 01:34 -0400, josef.p...@gmail.com wrote: > > > > > > > > > > It looks like in 1.9 it depends on the order of the 2-d arrays, which > > it didn't do in 1.6 > > > > Yes, it uses concatenate,

Re: [Numpy-discussion] when did column_stack become C-contiguous?

On Mon, Oct 19, 2015 at 9:00 AM, wrote: > > > On Mon, Oct 19, 2015 at 5:16 AM, Sebastian Berg < > sebast...@sipsolutions.net> wrote: > >> On Mo, 2015-10-19 at 01:34 -0400, josef.p...@gmail.com wrote: >> > >> >> >> >> >> > >> > It looks like in 1.9 it depends on the order

Re: [Numpy-discussion] when did column_stack become C-contiguous?

On Mon, Oct 19, 2015 at 9:15 PM, Nathaniel Smith wrote: > On Mon, Oct 19, 2015 at 5:55 AM, wrote: > > > > > > On Mon, Oct 19, 2015 at 2:14 AM, Nathaniel Smith wrote: > >> > >> On Sun, Oct 18, 2015 at 9:35 PM, wrote:

Re: [Numpy-discussion] numpy 1.10.1 reduce operation on recarrays

On Fri, Oct 16, 2015 at 9:31 PM, Allan Haldane wrote: > On 10/16/2015 09:17 PM, josef.p...@gmail.com wrote: > >> >> >> On Fri, Oct 16, 2015 at 8:56 PM, Allan Haldane > > wrote: >> >> On 10/16/2015 05:31 PM,

Re: [Numpy-discussion] when did column_stack become C-contiguous?

On Mon, Oct 19, 2015 at 9:51 PM, wrote: > > > On Mon, Oct 19, 2015 at 9:15 PM, Nathaniel Smith wrote: > >> On Mon, Oct 19, 2015 at 5:55 AM, wrote: >> > >> > >> > On Mon, Oct 19, 2015 at 2:14 AM, Nathaniel Smith

Re: [Numpy-discussion] numpy 1.10.1 reduce operation on recarrays

On Fri, Oct 16, 2015 at 8:56 PM, Allan Haldane wrote: > On 10/16/2015 05:31 PM, josef.p...@gmail.com wrote: > > > > > > On Fri, Oct 16, 2015 at 2:21 PM, Charles R Harris > > > wrote: > > > > > > > > On Fri,

Re: [Numpy-discussion] Interesting discussion on copyrighting files.

On Thu, Oct 15, 2015 at 11:28 PM, Charles R Harris < charlesr.har...@gmail.com> wrote: > Worth a read at A . > Thanks, it is worth a read. Most of the time when I see code copied from scipy or statsmodels, it is properly attributed. But every once in a

  1   2   >