Shot in the dark: Anyone ever use CLAPACK routines?

[Jerry Feldman]

I've used CLAPACK, but as an underlying library for other things. My
company uses CLAPACK 3.0 in our product and I am unaware of any issues.
We do complex things like Stochastic systems. In addition about 99% of
our code is pure C++ with a very small amount of C Flex and Bison.
Additionally, the Python Numpy and Scipy packages use CLAPACK, and we do
use a bit of the lapack stuff in our Python modules. After looking at
your code, the first thing I looked for is initializations, and it does
appear that your initializations of matricies A and I are ok. I also
think that defining 'doublecomplex A[m][m]' is correct. I'm wondering if
your LDx values are correct. What happens if you define 'doublecomplex
A[m+1][m+1];' as well as I and C.

On 05/18/2010 08:13 PM, Bruce Labitt wrote:
> As the subject line indicates - a total shot in the dark...
>
> Prototyping Platform: Ubuntu 10.04 x86-64
> Libraries: BLAS from ATLAS, CLAPACK
>
> I'm trying to use some CLAPACK routines to perform matrix manipulation, 
> in particular, the zgesvd routine to do a singular value decomposition 
> (SVD).  My code is working for a 2x2 matrix, but it does not work for a 
> 9x9.  I posted the code at the lapack-forum
>
> http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=2&t=1839&sid=a44c7f5bb3f4836d77568664db0e1c89 
>
>
> which works for a 2x2 and fails for a 9x9, with a Segmentation Fault.
>
> I'm suspicious that it is 99% operator (me) error.  (Fair guess :-P )
>
> In particular, I'm worried about stuff like declaring:
>
> doublecomplex A[m][m];
> where doublecomplex is defined in f2c.h as struct{ double r; double i; }
>
> Is is better in general (more portable) to use something like
>
> doublecomplex A[m*m] instead?
>
> For those who may not know, CLAPACK is a C version of LAPACK, which was 
> originally written in FORTRAN (gasp).  It is the Linear Algebra library 
> that both OSS and closed source use.  I know that Numpy & Scipy use 
> LAPACK, as well as MATLAB.  I'm using CLAPACK because it can be built 
> entirely in C. (FORTRAN is not available on the 'final' platform)
>
> If anyone has a few spare moments, I'd appreciate a quick look and any 
> helpful comments you may have.  FWIW, I used valgrind and saw that even 
> when I got the correct answer, there were tons of warnings and errors 
> reported.  (These errors were DEEP inside of the CLAPACK library.)
>
> Note: if anyone is adventurous enough to try this at home (or anywhere 
> else) you will need to change the libs and includes to point to your 
> blas and lapack libs.  I built my BLAS using ATLAS with the nof77 option 
> (C only!), and linked to CLAPACK (which I also built).  Most folks would 
> just install the libs from their repositories...
>
>   


-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : http://mail.gnhlug.org/mailman/private/gnhlug-discuss/attachments/20100519/cd73d1ec/attachment-0001.bin