[Numpy-discussion] numarray cholesky solver ?

[Piotr Luszczek]

David M. Cooke wrote:
> Piotr Luszczek <luszczek at cs.utk.edu> writes:
> 
> 
>>Hi all,
>>
>>the Cholesky routine that's been mentioned (dpotrs) is from LAPACK (I
>>apologize if every body knows that).
>>
>>I'm on the LAPACK team right now and we were wondering if we should
>>provide bindings for Python. It is almost trivial to do with Pyrex.
>>But Numeric and numarray already have some functionality in it.
>>Also, I don't know about popularity of PyLapack.
>>
>>So my question is if there is a need for the specialized LAPACK
>>routines. And if so, which API it should use (Numeric, numarray,
>>Numeric3, scipy_core, standard array, minimum standard array implementation
>>or array protocol meta info).
> 
> 
> You'll probably first want to look at scipy, which already wraps (all?
> most?) of LAPACK in its scipy.linalg package (including dpotrs :-)

It seems to have almost all routines.

> It uses f2py to make the process much easier.
> 
> 
> Since you mention you're on the LAPACK team ...
> 
> I've been working on redoing the f2c'd LAPACK wrappers in Numeric,
> updating them to the current version...except: what *is* the current

Current version is 3.0.

> version? The patches on netlib are 2-3 years old, and you have to grab

After funding ran out there were only volunteers left.
It's hard to get free open-source developers these days.

> them separately, file-by-file (can I say how insanely stupid that

Frankly, I had the same comment when I first saw it.
Hopefully, next update will straighten things out.

> is?). Also ... they break: with some test cases (derived from ones
> posted to our bug tracker) some routines segfault.

Yes I know. We have postings about it on the mailing list almost
weekly.

> Is it the LAPACK 3e? If that's the case, we can't use it unless there

LAPACK 3E is only somewhat related to LAPACK.
But it's not "current version".

> are C versions (Numeric only requires Python and a C compiler;
> throwing a F90 compiler in there is *not* an option -- we don't even
> require a F77 compiler).

We've been thinking about languages for a while. CLAPACK user base
is too strong to ignore. So we think of keeping F77 as the base language.
Or maybe we should do f90toC. f2c and f2j are on Netlib already and
f2py has some F90 support.

> I ended up using the source from Debian unstable from the lapack3
> package, and those work fine.

Again, it's hard to get grant money for support.

Thanks for the comments.

Piotr