[SciPy-dev] Do we care about the LAPACK C interface?
Fri Nov 7 22:19:06 CST 2008
On Sat, Nov 8, 2008 at 12:50 PM, Robert Kern <email@example.com> wrote:
> On Fri, Nov 7, 2008 at 21:42, David Cournapeau <firstname.lastname@example.org> wrote:
>> On Sat, Nov 8, 2008 at 8:43 AM, Robert Kern <email@example.com> wrote:
>>> On Fri, Nov 7, 2008 at 17:27, Travis E. Oliphant <firstname.lastname@example.org> wrote:
>>>> Hi all,
>>>> I'm sitting here in a BOF with Clint Whaley (the author of ATLAS). He
>>>> is looking for information about people that care about the C interface
>>>> to LAPACK. Do we care?
>>>> I'm not clear on that. Don't we just use the FORTRAN interfaces to ATLAS?
>>>> If I hear from you soon, I can give Clint the information before I leave
>>>> the BOF.
>>> Query: Are you talking about just the C interface to LAPACK or the C
>>> interface to the BLAS, too? I definitely want to keep the BLAS C
>> I agree cblas is more interesting than clapack. In theory, we could
>> wrap more cblas into numpy, without the need of any fortran compiler.
>> There is also technical difference between clapack and cblas: clapack
>> interface is a fortran-like interfance (everything passed by
>> reference, same name than lapack), contrary to cblas which is more C.
>> This makes clapack quite confusing, actually, and not always even
>> usable at the same time as LAPACK (because of name collision).
>>> It would be nice if there were a C interface to the entire
>>> LAPACK, but I don't think that ATLAS (or anyone else) provides that
>> I am not 100 % positive, but I think the accelerate framework offers
>> a clapack interface. AMD, too, may offer a clapack interface. It is
>> not always obvious whereas a given interface is lapack or clapack
>> (since the names are the same).
> I don't think that's what we're talking about, here. The CLAPACK that
> you are talking about is already accomplished, and is just the result
> of f2c'ing the Fortran LAPACK sources; it is available here:
Ok, Netlib clapack and ATLAS clapack are not the same thing. The
clapack we wrap in scipy.linalg is the later, then
But since we have to support the fortran interface anyway, what's the
advantage of using a parallel clapack ? Even if atlas had a 100 %
coverage of LAPACK into a C interface to LAPACK, we still could not
drop the fortran wrapper ( to support old versions of atlas, and all
the other ones without C interface).
More information about the Scipy-dev