numpy-discussion

[Numpy-discussion] Assign NaN, get zero

[Keith G. <kwg...@gm...>]

I accidentally wrote a unit test using int32 instead of float64 and
ran into this problem:

>> x = M.matrix([[1, 2, 3]])
>> x[0,1] = M.nan
>> x
matrix([[1, 0, 3]])   <--- Got 0 instead of NaN

But this, of course, works:

>> x = M.matrix([[1.0, 2.0, 3.0]])
>> x[0,1] = M.nan
>> x
matrix([[ 1.        ,         nan,  3.        ]])

Is returning a 0 instead of NaN the expected behavior?

If so do I need to check dtype before inserting NaNs? And if the dtype
is int32, then raise an exception?

I'm using 1.0rc1 from debian etch.

Re: [Numpy-discussion] Assign NaN, get zero

[Stefan v. d. W. <st...@su...>]

On Sat, Nov 11, 2006 at 10:40:22AM -0800, Keith Goodman wrote:
> I accidentally wrote a unit test using int32 instead of float64 and
> ran into this problem:
>=20
> >> x =3D M.matrix([[1, 2, 3]])
> >> x[0,1] =3D M.nan
> >> x
> matrix([[1, 0, 3]])   <--- Got 0 instead of NaN
>=20
> But this, of course, works:
>=20
> >> x =3D M.matrix([[1.0, 2.0, 3.0]])
> >> x[0,1] =3D M.nan
> >> x
> matrix([[ 1.        ,         nan,  3.        ]])
>=20
> Is returning a 0 instead of NaN the expected behavior?

NaN (or inf) is a floating point number, so seeing a zero in integer
representation seems correct:

In [2]: int(N.nan)
Out[2]: 0L

Cheers
St=E9fan

Re: [Numpy-discussion] Assign NaN, get zero

[Lisandro D. <da...@gm...>]

On 11/11/06, Stefan van der Walt <st...@su...> wrote:
> NaN (or inf) is a floating point number, so seeing a zero in integer
> representation seems correct:
>
> In [2]: int(N.nan)
> Out[2]: 0L
>

Just to learn myself: Why int(N.nan) should be 0? Is it C behavior?

--=20
Lisandro Dalc=EDn
---------------
Centro Internacional de M=E9todos Computacionales en Ingenier=EDa (CIMEC)
Instituto de Desarrollo Tecnol=F3gico para la Industria Qu=EDmica (INTEC)
Consejo Nacional de Investigaciones Cient=EDficas y T=E9cnicas (CONICET)
PTLC - G=FCemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

Re: [Numpy-discussion] Assign NaN, get zero

[Charles R H. <cha...@gm...>]

On 11/11/06, Lisandro Dalcin <da...@gm...> wrote:
>
> On 11/11/06, Stefan van der Walt <st...@su...> wrote:
> > NaN (or inf) is a floating point number, so seeing a zero in integer
> > representation seems correct:
> >
> > In [2]: int(N.nan)
> > Out[2]: 0L
> >
>
> Just to learn myself: Why int(N.nan) should be 0? Is it C behavior?


In [1]: int32(0)/int32(0)
Warning: divide by zero encountered in long_scalars
Out[1]: 0

In [2]: float32(0)/float32(0)
Out[2]: nan

In [3]: int(nan)
Out[3]: 0L

I think it was just a default for numpy. Hmmm, numpy now warns on integer
division by zero, didn't used to.  Looks like a warning should also be
raised when casting nan to integer. It is probably a small bug not to. I
also suspect int(nan) should return a normal python zero, not 0L.

Chuck

Re: [Numpy-discussion] Assign NaN, get zero

[Stefan v. d. W. <st...@su...>]

On Sat, Nov 11, 2006 at 06:30:06PM -0300, Lisandro Dalcin wrote:
> On 11/11/06, Stefan van der Walt <st...@su...> wrote:
> > NaN (or inf) is a floating point number, so seeing a zero in integer
> > representation seems correct:
> >
> > In [2]: int(N.nan)
> > Out[2]: 0L
> >
>=20
> Just to learn myself: Why int(N.nan) should be 0? Is it C behavior?

As far as I know (and please correct me if I'm wrong), nan's are just
a specific bit pattern set in memory when an invalid floating point
operation occurs (in IEEE 754 nan's are represented by an exponent of
all 1's and a non-zero mantissa).

Most integer representations have no way of indication an invalid
result (and C provides no such conversion, as far as I am aware), so
nan's are interpreted as 0 (which could have been any arbitrary number
for that matter, although 0 seems a logical choice).

Regards
St=E9fan

Re: [Numpy-discussion] Assign NaN, get zero

[Keith G. <kwg...@gm...>]

On 11/11/06, Stefan van der Walt <st...@su...> wrote:
> On Sat, Nov 11, 2006 at 10:40:22AM -0800, Keith Goodman wrote:
> > I accidentally wrote a unit test using int32 instead of float64 and
> > ran into this problem:
> >
> > >> x = M.matrix([[1, 2, 3]])
> > >> x[0,1] = M.nan
> > >> x
> > matrix([[1, 0, 3]])   <--- Got 0 instead of NaN
> >
> > But this, of course, works:
> >
> > >> x = M.matrix([[1.0, 2.0, 3.0]])
> > >> x[0,1] = M.nan
> > >> x
> > matrix([[ 1.        ,         nan,  3.        ]])
> >
> > Is returning a 0 instead of NaN the expected behavior?
>
> NaN (or inf) is a floating point number, so seeing a zero in integer
> representation seems correct:
>
> In [2]: int(N.nan)
> Out[2]: 0L

Would it make sense to upcast instead of downcast?

This upcasts:

>> x = M.matrix([[1, M.nan, 3]])
>> x
matrix([[ 1.        ,         nan,  3.        ]])

But this doesn't:

>> x = M.matrix([[1, 2, 3]])
>> x[0,1] = M.nan
>> x
matrix([[1, 0, 3]])

(BTW, how do you represent missing integers if you can't use NaN?)

Re: [Numpy-discussion] Assign NaN, get zero

[Stefan v. d. W. <st...@su...>]

On Sat, Nov 11, 2006 at 01:59:40PM -0800, Keith Goodman wrote:
> Would it make sense to upcast instead of downcast?
>=20
> This upcasts:
>=20
> >> x =3D M.matrix([[1, M.nan, 3]])
> >> x
> matrix([[ 1.        ,         nan,  3.        ]])
>=20
> But this doesn't:
>=20
> >> x =3D M.matrix([[1, 2, 3]])
> >> x[0,1] =3D M.nan
> >> x
> matrix([[1, 0, 3]])

This behaviour is consistent with

x =3D N.array([[1,2.0,3]])

vs

x =3D N.array([1,2,3])
x[0,1] =3D 2.

> (BTW, how do you represent missing integers if you can't use NaN?)

I think masked arrays should work on integer arrays (alternatively, if
you have enough memory, cast your array to float).

Regards
St=E9fan