[Numpy-discussion] another numpy/ATLAS problem

[David Warde-Farley]

On 29-Nov-09, at 4:46 PM, David Warde-Farley wrote:

> On 27-Nov-09, at 6:29 PM, Charles R Harris wrote:
>
>> 3.9.12 segfaulted on me while running, so I haven't bothered with
>> versions after that. Why not try the stable version 3.8.3?
>
> Just to follow up, I went back to 3.9.11 and numpy works without
> incident, using the exact same ATLAS build procedure; I guess it
> wasn't something I was doing wrong after all.
>
> I've filed it on the ATLAS tracker, so hopefully it'll be addressed
> sooner or later.


Below is the response I received from Clint Whaley re: dlamc3_ and  
NumPy. It seems that NumPy's lapack_lite is making some assumptions  
about routines which aren't actually there in recent (3.9.16 and on)  
versions of ATLAS, as it provides a speedier version of DLAMCH.

I've briefly been trying to figure out how to work around this, but  
I'm a bit confused. I was under the (mistaken?) impression that the  
f2c'd code in dlapack_lite.c, zlapack_lite.c and dlamch.c was only  
used in the absence of an external BLAS/LAPACK, so that NumPy can fall  
back on its own; yet these are the only places dlamc3_ is referenced.

The ATLAS ticket is at http://tinyurl.com/y8dv5w8 if you wish to  
respond directly as well.

--------------------------------------------------------------------------------------------

David,

Well, dlamc3 is an internal routine called by dlamch in LAPACK in  
order to
keep register assignment from screwing up their internal tests.  It is  
not
part of the official LAPACK API AFAIK.  It looks like some part of  
NumPy is
calling this routine, expecting that DLAMCH will provide it.  However,  
from
3.9.16 on, ATLAS provides a native LAMCH implementation, that reads in a
generated file for improved speed.  This LAMCH does no computation at  
all,
and so obviously does not provide the internal routine DLAM3.

Can you ask the NumPy people to comment on why they are calling this
routine?

Thanks,
Clint