[Numpy-discussion] two previously unresolved issues

Stefan van der Walt stefan@sun.ac...
Tue Mar 27 01:45:01 CDT 2007


I just went through my mail archive and found these two minor
outstanding issues.  Thought I'd ask for comments before the new

From: "Charles R Harris" <charlesr.harris@gmail.com>
Subject: Re: [Numpy-discussion] Assign NaN, get zero

On 11/11/06, Lisandro Dalcin <dalcinl@gmail.com> wrote:
> On 11/11/06, Stefan van der Walt <stefan@sun.ac.za> 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.

From: "Bill Baxter" <wbaxter@gmail.com>
To: numpy-discussion@scipy.org
Subject: [Numpy-discussion] linalg.lstsq for complex

Is this code from linalg.lstsq for the complex case correct?

       lapack_routine = lapack_lite.zgelsd
        lwork = 1
        rwork = zeros((lwork,), real_t)
        work = zeros((lwork,),t)
        results = lapack_routine(m, n, n_rhs, a, m, bstar, ldb, s, rcond,
                                 0, work, -1, rwork, iwork, 0)
        lwork = int(abs(work[0]))
        rwork = zeros((lwork,),real_t)
        a_real = zeros((m,n),real_t)
        bstar_real = zeros((ldb,n_rhs,),real_t)
        results = lapack_lite.dgelsd(m, n, n_rhs, a_real, m,
                                     bstar_real, ldb, s, rcond,
                                     0, rwork, -1, iwork, 0)
        lrwork = int(rwork[0])
        work = zeros((lwork,), t)
        rwork = zeros((lrwork,), real_t)
        results = lapack_routine(m, n, n_rhs, a, m, bstar, ldb, s, rcond,

The middle call to dgelsd looks unnecessary to me.  At the very least,
allocating astar_real and bstar_real shouldn't be necessary since they
aren't referenced anywhere else in the lstsq function.  The lapack
documentation for zgelsd also doesn't mention any need to call dgelsd
to compute the size of the work array.


More information about the Numpy-discussion mailing list