Re: [Numpy-discussion] Products of small float32 values.

On Wed, Oct 2, 2013 at 6:06 PM, Matthew Brett wrote: > > > Is it possible you are thinking of 2**-126 rather than 10**-126? > > Yup, brainfart... > In [3]: print np.finfo(np.float32) > Machine parameters for float32 > - > preci

Re: [Numpy-discussion] Products of small float32 values.

Hi, On Wed, Oct 2, 2013 at 6:00 PM, Dave Cook wrote: > Can someone explain what is going on here? > > In [153]: > > small = ones(1, dtype='float32') > > In [154]: > > small > > Out[154]: > > array([ 1.], dtype=float32) > > In [155]: > > small*1e-45 > > Out[155]: > > array([ 1.40129846e-45], dtyp

[Numpy-discussion] Products of small float32 values.

Can someone explain what is going on here? In [153]: small = ones(1, dtype='float32') In [154]: small Out[154]: array([ 1.], dtype=float32) In [155]: small*1e-45 Out[155]: array([ 1.40129846e-45], dtype=float32) In [156]: small*1e-46 Out[156]: array([ 0.], dtype=float32) I would exp

Re: [Numpy-discussion] 1.8.0, nan functions, and pandas

On Wed, Oct 2, 2013 at 5:29 PM, Charles R Harris wrote: > Hi All, > > There was a problem with pandas 0.12 and the numpy nan functions when > applying the nansum function to a pandas Series object. We thought we had > fixed it by the slight of hand use of `a.sum` instead of `add.reduce(a)` so > th

[Numpy-discussion] 1.8.0, nan functions, and pandas

Hi All, There was a problem with pandas 0.12 and the numpy nan functions when applying the nansum function to a pandas Series object. We thought we had fixed it by the slight of hand use of `a.sum` instead of `add.reduce(a)` so that the Series object could use its own version of `sum` which overri

Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.

On 2 Oct 2013 21:19, "Charles R Harris" wrote: > > > The main problem I had was deciding what arg{max, min} should return as the return value is an integer. I like your suggestion of returning 0. This doesn't allow the user to know the difference between valid and" invalid" output, does it? > On

Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.

On Wed, Oct 2, 2013 at 8:19 PM, Charles R Harris wrote: > > > > On Wed, Oct 2, 2013 at 12:51 PM, wrote: >> >> On Wed, Oct 2, 2013 at 2:49 PM, wrote: >> > On Wed, Oct 2, 2013 at 2:05 PM, Stéfan van der Walt >> > wrote: >> >> On 2 Oct 2013 19:14, "Benjamin Root" wrote: >> >>> >> >>> And it is l

[Numpy-discussion] MATLAB fsolve now available in Python

Hi all, New solver for systems of nonlinear equations ( SNLE ) has been connected to free Python framework OpenOpt: fsolve from  MATLAB   Optimization Toolbox; uploaded into PYPI in v. 0.5112. As well as fmincon , currently it's available for Python 2 only. Unlike scipy.optimize fsolve, it ca

Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.

On Wed, Oct 2, 2013 at 12:51 PM, wrote: > On Wed, Oct 2, 2013 at 2:49 PM, wrote: > > On Wed, Oct 2, 2013 at 2:05 PM, Stéfan van der Walt > wrote: > >> On 2 Oct 2013 19:14, "Benjamin Root" wrote: > >>> > >>> And it is logically consistent, I think. a[nanargmax(a)] == nanmax(a) > >>> (ignoring

Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.

On Wed, Oct 2, 2013 at 7:51 PM, wrote: > On Wed, Oct 2, 2013 at 2:49 PM, wrote: >> On Wed, Oct 2, 2013 at 2:05 PM, Stéfan van der Walt wrote: >>> On 2 Oct 2013 19:14, "Benjamin Root" wrote: And it is logically consistent, I think. a[nanargmax(a)] == nanmax(a) (ignoring the sil

Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.

On Wed, Oct 2, 2013 at 2:05 PM, Stéfan van der Walt wrote: > On 2 Oct 2013 19:14, "Benjamin Root" wrote: > > > > And it is logically consistent, I think. a[nanargmax(a)] == nanmax(a) > (ignoring the silly detail that you can't do an equality on nans). > > Why do you call this a silly detail? It

Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.

On Wed, Oct 2, 2013 at 2:49 PM, wrote: > On Wed, Oct 2, 2013 at 2:05 PM, Stéfan van der Walt wrote: >> On 2 Oct 2013 19:14, "Benjamin Root" wrote: >>> >>> And it is logically consistent, I think. a[nanargmax(a)] == nanmax(a) >>> (ignoring the silly detail that you can't do an equality on nans)

Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.

On Wed, Oct 2, 2013 at 2:05 PM, Stéfan van der Walt wrote: > On 2 Oct 2013 19:14, "Benjamin Root" wrote: >> >> And it is logically consistent, I think. a[nanargmax(a)] == nanmax(a) >> (ignoring the silly detail that you can't do an equality on nans). > > Why do you call this a silly detail? It s

Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.

On 2 Oct 2013 19:14, "Benjamin Root" wrote: > > And it is logically consistent, I think. a[nanargmax(a)] == nanmax(a) (ignoring the silly detail that you can't do an equality on nans). Why do you call this a silly detail? It seems to me a fundamental flaw to this approach. Stéfan __

Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.

On Wed, Oct 2, 2013 at 1:05 PM, Charles R Harris wrote: > > > > On Wed, Oct 2, 2013 at 10:56 AM, wrote: > >> On Wed, Oct 2, 2013 at 12:37 PM, Stéfan van der Walt >> wrote: >> > On 2 Oct 2013 18:04, "Charles R Harris" >> wrote: >> >> >> >> The question is what to do when all-nan slices are encou

Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.

On Wed, Oct 2, 2013 at 10:56 AM, wrote: > On Wed, Oct 2, 2013 at 12:37 PM, Stéfan van der Walt > wrote: > > On 2 Oct 2013 18:04, "Charles R Harris" > wrote: > >> > >> The question is what to do when all-nan slices are encountered in the > >> nan{max,min} and nanarg{max, min} functions. Currentl

Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.

On Wed, Oct 2, 2013 at 12:37 PM, Stéfan van der Walt wrote: > On 2 Oct 2013 18:04, "Charles R Harris" wrote: >> >> The question is what to do when all-nan slices are encountered in the >> nan{max,min} and nanarg{max, min} functions. Currently in 1.8.0, the first >> returns nan and raises a warnin

Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.

On 2 Oct 2013 18:04, "Charles R Harris" wrote: > > The question is what to do when all-nan slices are encountered in the nan{max,min} and nanarg{max, min} functions. Currently in 1.8.0, the first returns nan and raises a warning, the second returns intp.min and raises a warning. It is proposed tha

Re: [Numpy-discussion] [SciPy-Dev] 1.8.0rc1

On Wed, Oct 2, 2013 at 10:12 AM, Benjamin Root wrote: > > > > On Wed, Oct 2, 2013 at 11:43 AM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> Hi Stefan, >> >> >> On Wed, Oct 2, 2013 at 9:29 AM, Stéfan van der Walt wrote: >> >>> Hi Chuck >>> >>> On Tue, Oct 1, 2013 at 1:07 AM, Charles

Re: [Numpy-discussion] [SciPy-Dev] 1.8.0rc1

On Wed, Oct 2, 2013 at 11:43 AM, Charles R Harris wrote: > Hi Stefan, > > > On Wed, Oct 2, 2013 at 9:29 AM, Stéfan van der Walt wrote: > >> Hi Chuck >> >> On Tue, Oct 1, 2013 at 1:07 AM, Charles R Harris >> wrote: >> >> I'll bet the skimage problems come from >> >> https://github.com/numpy/numpy

Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.

+1 to making the nan functions consistent with the non-nan functions. On 2 Oct 2013 17:03, "Charles R Harris" wrote: > Hi All, > > The question is what to do when all-nan slices are encountered in the > nan{max,min} and nanarg{max, min} functions. Currently in 1.8.0, the first > returns nan and r

[Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.

Hi All, The question is what to do when all-nan slices are encountered in the nan{max,min} and nanarg{max, min} functions. Currently in 1.8.0, the first returns nan and raises a warning, the second returns intp.min and raises a warning. It is proposed that the nanarg{max, min} functions, and possi

Re: [Numpy-discussion] [SciPy-Dev] 1.8.0rc1

Hi Stefan, On Wed, Oct 2, 2013 at 9:29 AM, Stéfan van der Walt wrote: > Hi Chuck > > On Tue, Oct 1, 2013 at 1:07 AM, Charles R Harris > wrote: > >> I'll bet the skimage problems come from > >> https://github.com/numpy/numpy/pull/3811. They may be doing something > >> naughty... > >> > > > > Rev

Re: [Numpy-discussion] [SciPy-Dev] 1.8.0rc1

Hi Chuck On Tue, Oct 1, 2013 at 1:07 AM, Charles R Harris wrote: >> I'll bet the skimage problems come from >> https://github.com/numpy/numpy/pull/3811. They may be doing something >> naughty... >> > > Reverting that commit fixes those skimage failures. However, there are a > number of python2.7

Re: [Numpy-discussion] 1.8.0rc1

On Wed, 2013-10-02 at 12:54 +0200, Sebastian Berg wrote: > On Wed, 2013-10-02 at 10:04 +0100, Nathaniel Smith wrote: > > This is a complicated issue to describe but i think the bottom line is > > that the test is just wonky here. the behaviour it's checking for is: > > wrong in old numpy, but we do

Re: [Numpy-discussion] 1.8.0rc1

On Wed, 2013-10-02 at 10:04 +0100, Nathaniel Smith wrote: > This is a complicated issue to describe but i think the bottom line is > that the test is just wonky here. the behaviour it's checking for is: > wrong in old numpy, but we do it anyway (bug) > wrong in current numpy without RELAXED_STRIDES

Re: [Numpy-discussion] 1.8.0rc1

This is a complicated issue to describe but i think the bottom line is that the test is just wonky here. the behaviour it's checking for is: wrong in old numpy, but we do it anyway (bug) wrong in current numpy without RELAXED_STRIDES, and we get it right (I.e. don't do it, fixed bug) correct in cur

Re: [Numpy-discussion] 1.8.0rc1

On 9/30/2013 8:17 AM, Charles R Harris wrote: Hi All, NumPy 1.8.0rc1 is up now on sourceforge .The binary builds are included except for Python 3.3 on windows, which will arrive later. Many thanks to Ralf for the binaries, and to thos