lapackpp-devel — Discussion of Lapack++ development

[Lapackpp-devel] Re: latmpl.h

[Christian S. <sti...@tu...>]

Hallo,

1. Fragen zum Programm bitte immer an die Mailingliste=20
lap...@li..., niemals nur an einzelne Entwickler;

2. In welcher Programmzeile genau trat der Fehler auf? Gibt es da=20
bereits einen Kommentar im source dazu?

3. Was war das genau f=FCr ein Compiler? Etwas anderes als GNU gcc? Wenn=20
ja, dann bitte den Kommentar in latmpl.h Zeilen 39 bis 48 durchlesen und=20
ggf. das #define vollst=E4ndig rauskommentieren und erneut versuchen.

Christian

S=F6ren Freudiger schrieb:
> Hallo CHristian
> irgendwie bekomme ich das lapack++ nicht compiliert.
>=20
> In der latmpl.h erhalte ich st=E4ndig folgende Fehlermeldung:
>=20
> warning C4346: 'matT::value_type' : dependent name is not a type prefix=
 with
> 'typename' to indicate a type
>=20
> Hast du eine Ahnung, was das sein koennte? Ich habe 2.4.5 und 2.4.6 get=
estet
> (letztere mit VS 2003 und 2005).
>=20
> Ohne Erfolg...
>=20
> Gru=DF,
> Soeren
>=20
> --
> Dipl.-Ing. Soeren Freudiger
> Institut fuer ComputerAnwendungen im Bauingenieurwesen TU Braunschweig,=
=20
> Pockelsstr. 3, D-38106 Braunschweig
> Tel.: +49 531/391-7595,
> Mobil: +49 176/210 17 444
>=20
> email: fr...@ca...
> http://www.cab.bau.tu-bs.de/ =20
>=20
>=20

[Lapackpp-devel] Re: lapackpp and banded matrices (was: help lapackpp)

[Christian S. <sti...@tu...>]

Hi,

thanks for your feedback. In the future please write to the mailing list 
lapackpp-devel instead to individual developers.

Am Dienstag, 20. Dezember 2005 21:34 schrieb ll...@21...:
>   I am new to lapack++ and I found this package is very good. I have
> compared lapack++ with matlab in solving a 1000x1000 equaions and it
> turns out that lapack++ do a great job. Thanks for your contribution.

Nice to hear.

> However, I have some questions in using lapack++. I have a test code
> like
>
> LaGenMatDouble A(N,N);
> LaBandMatDouble B(N,2,2); // for five-diagonal matrix
> LaVectorDouble x(N), f(N);
>
> LaLinearSolve(A, x, f);
>
> The program shown above can be compiled without any problem. 

I have never used the banded matrices, so I cannot guarantee anything with 
them. You need to manually verify that the functions really do what they are 
supposed to do. I can only guarantee (or rather: try to guarantee) the 
correct functionality for the GenMat classes.

> I just 
> wonder if I really need lapack (not lapack++) installed. I have not
> linked the library of lapack and blas and the program can also be run
> and get the correct answer???

Well, if it works, then you can just be happy. I wouldn't bother as long as it 
works.

> I am using lapack++ 2.4.2, windows

If you're using the self-installing setup.exe file, then this comes with a DLL 
of blas and lapack, too.

> Another question is about band matrix, I try to build a five-diagonal
> matrix with LaBandMatDouble. In my case, building a band matrix with
> LaBandMatDouble is ok, but it seems that LaLinearSolve has no
> corresponding interface for solving LaBandMatDouble!? How can I solve a
> band matrix with lapack++?

As I said: the banded matrices have been untouched since the original 
lapack++-1.0. If you really need this functionality, then: 1. find out the 
original LAPACK function call that does what you want, 2. see whether there 
is already a declaration of that function call in include/lapackd.h, 3. if 
there is, then you're almost done: Go into src/linslv.cc and copy&paste the 
program code from one of the other functions, e.g. 
LaLULinearSolve(LaGenMatDouble& A, LaGenMatDouble& X, const LaGenMatDouble& 
B ), but replace the matrix types and the F77NAME function call with your 
appropriate names. Then add the declaration to the include/laslv.h header, 
compile and test your new function. If the tests behave as expected, send 
your program code to me and I'll happily add it to the library in CVS.

Christian

Re: [Lapackpp-devel] lapack++ compilation failure on linux

[Christian S. <sti...@tu...>]

Hi Vincent,

thanks for the info.

Vincent Acary schrieb:
> PS: A problem remains on the definition a min function in the source 
> file lasvd.cc.  I skip it
> #if !LAPACK_USE_GCC3
> #  ifndef min
> #    define min(A,B) ((A) < (B) ? (A) : (B) )
> #  endif
> #endif

You mean you deleted this entirely? Yes, after looking at this I also 
removed this in CVS entirely, as it isn't used anymore anyway.  Thanks 
for pointing this out.

Christian

Re: [Lapackpp-devel] lapack++ compilation failure on linux

[Vincent A. <Vin...@in...>]

Thank you Christian.

Your answer solves my problem. Thank you very much.

For information, Parasoft Insure++ is an automated runtime=20
application-testing product that detects elusive C/C++ errors such as=20
memory corruption, memory leaks, memory allocation errors, variable=20
initialization errors, variable definition conflicts, pointer errors,=20
library errors, I/O errors, and logic errors.

Bye

PS: A problem remains on the definition a min function in the source=20
file lasvd.cc.  I skip it
#if !LAPACK_USE_GCC3
#  ifndef min
#    define min(A,B) ((A) < (B) ? (A) : (B) )
#  endif
#endif

Christian Stimming wrote:

> Dear Vincent,
>
> I have never heard of the "insure" compiler, so I have to say that=20
> lapackpp hasn't been tested with that before.
>
> The error you are seeing is caused because I some C extensions which=20
> are specific to the GNU gcc have been used when dealing with complex=20
> numbers. I think you can easily solve this issue by changing the line=20
> 50 in the file include/lacomplex.h.in into
>
> #define LAPACK_USE_GCC3 0
>
> Calling "make" again (which will create the file include/lacomplex.h=20
> from the file you just edited) should then fix your error.
>
> (More specifically, the file "include/lacomplex" used the __complex__=20
> attribute of the gcc, which obviously your insure compiler doesn't=20
> know. Fortunately, this particular section will be disabled if the=20
> macro LAPACK_USE_GCC3 is defined to zero.)
>
> Christian
>
>
> Vincent Acary schrieb:
>
>> Hi,
>>
>> I have a problem with the compilation of lapack++ on GNU/linux 2.6-10=20
>> using the compiler insure.
>>
>> It seems that the call of overloaded function are ambiguous (see below=
)
>>
>> Have you any idea ?
>>
>> Thanks
>>
>>
>> insure -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include=20
>> -I../../include -DLA_COMPLEX_SUPPORT -DHAVE_CONFIG_H -DLinux -g -O2=20
>> -Wall -MT blas1pp.lo -MD -MP -MF .deps/blas1pp.Tpo -c blas1pp.cc  -DPI=
C
>> WARNING: optimization flag O2 discarded for Insure++ compile
>> In file included from blas1pp.cc:30:
>> ../../include/lavc.h: In member function `LaVectorComplex&
>>   LaVectorComplex::operator=3D(double)':
>> ../../include/lavc.h:334: error: call of overloaded=20
>> `complex(double&)' is
>>   ambiguous
>> ../../include/lacomplex:578: error: candidates are:
>>   la::complex<double>::complex(const la::complex<double>&)
>> ../../include/lacomplex:625: error:                 =20
>> la::complex<double>::complex(double)
>> ../../include/lacomplex:649: error:                 =20
>> la::complex<double>::complex(const std::complex<double>&)
>> ../../include/lacomplex:587: error:                 =20
>> la::complex<double>::complex(const la::complex<long double>&)
>> ../../include/lacomplex:586: error:                 =20
>> la::complex<double>::complex(const la::complex<float>&)
>> ../../include/lacomplex:641: error:                 =20
>> la::complex<double>::complex(double, double)
>> Driver: error executing "Run -DHAVE_CONFIG_H -I. -I. -I../..=20
>> -I../../include -I../../include -DLA_COMPLEX_SUPPORT -DHAVE_CONFIG_H=20
>> -DLinux -g -O2 -Wall -MT blas1pp.lo -MD -MP -MF .deps/blas1pp.Tpo -c=20
>> blas1pp.cc -DPIC"
>> make[3]: *** [blas1pp.lo] Erreur 1
>> make[3]: Leaving directory=20
>> `/home/bipop/acary/src/lapackpp-2.4.0/blaspp/src'
>> make[2]: *** [all-recursive] Erreur 1
>> make[2]: Leaving directory `/home/bipop/acary/src/lapackpp-2.4.0/blasp=
p'
>> make[1]: *** [all-recursive] Erreur 1
>> make[1]: Leaving directory `/home/bipop/acary/src/lapackpp-2.4.0'
>> make: *** [all] Erreur 2
>>
>>
>>
>
>


--=20
Vincent ACARY                     		   Charge de recherche
INRIA Rh=F4ne-Alpes    Equipe BIPOP        http://www.inrialpes.fr/bipop/
ZIRST, 655 avenue de l'Europe, MONTBONNOT 38334 ST ISMIER Cedex, FRANCE=20
Bureau D118       tel:+33 (0)4 76 61 52 29     fax:+33 (0)4 76 61 54 77=20

Re: [Lapackpp-devel] lapack++ compilation failure on linux

[Christian S. <sti...@tu...>]

Dear Vincent,

I have never heard of the "insure" compiler, so I have to say that 
lapackpp hasn't been tested with that before.

The error you are seeing is caused because I some C extensions which are 
specific to the GNU gcc have been used when dealing with complex 
numbers. I think you can easily solve this issue by changing the line 50 
in the file include/lacomplex.h.in into

#define LAPACK_USE_GCC3 0

Calling "make" again (which will create the file include/lacomplex.h 
from the file you just edited) should then fix your error.

(More specifically, the file "include/lacomplex" used the __complex__ 
attribute of the gcc, which obviously your insure compiler doesn't know. 
Fortunately, this particular section will be disabled if the macro 
LAPACK_USE_GCC3 is defined to zero.)

Christian


Vincent Acary schrieb:
> Hi,
> 
> I have a problem with the compilation of lapack++ on GNU/linux 2.6-10 
> using the compiler insure.
> 
> It seems that the call of overloaded function are ambiguous (see below)
> 
> Have you any idea ?
> 
> Thanks
> 
> 
> insure -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -I../../include 
> -DLA_COMPLEX_SUPPORT -DHAVE_CONFIG_H -DLinux -g -O2 -Wall -MT blas1pp.lo 
> -MD -MP -MF .deps/blas1pp.Tpo -c blas1pp.cc  -DPIC
> WARNING: optimization flag O2 discarded for Insure++ compile
> In file included from blas1pp.cc:30:
> ../../include/lavc.h: In member function `LaVectorComplex&
>   LaVectorComplex::operator=(double)':
> ../../include/lavc.h:334: error: call of overloaded `complex(double&)' is
>   ambiguous
> ../../include/lacomplex:578: error: candidates are:
>   la::complex<double>::complex(const la::complex<double>&)
> ../../include/lacomplex:625: error:                  
> la::complex<double>::complex(double)
> ../../include/lacomplex:649: error:                  
> la::complex<double>::complex(const std::complex<double>&)
> ../../include/lacomplex:587: error:                  
> la::complex<double>::complex(const la::complex<long double>&)
> ../../include/lacomplex:586: error:                  
> la::complex<double>::complex(const la::complex<float>&)
> ../../include/lacomplex:641: error:                  
> la::complex<double>::complex(double, double)
> Driver: error executing "Run -DHAVE_CONFIG_H -I. -I. -I../.. 
> -I../../include -I../../include -DLA_COMPLEX_SUPPORT -DHAVE_CONFIG_H 
> -DLinux -g -O2 -Wall -MT blas1pp.lo -MD -MP -MF .deps/blas1pp.Tpo -c 
> blas1pp.cc -DPIC"
> make[3]: *** [blas1pp.lo] Erreur 1
> make[3]: Leaving directory 
> `/home/bipop/acary/src/lapackpp-2.4.0/blaspp/src'
> make[2]: *** [all-recursive] Erreur 1
> make[2]: Leaving directory `/home/bipop/acary/src/lapackpp-2.4.0/blaspp'
> make[1]: *** [all-recursive] Erreur 1
> make[1]: Leaving directory `/home/bipop/acary/src/lapackpp-2.4.0'
> make: *** [all] Erreur 2
> 
> 
> 

[Lapackpp-devel] lapack++ compilation failure on linux

[Vincent A. <Vin...@in...>]

Hi,

I have a problem with the compilation of lapack++ on GNU/linux 2.6-10=20
using the compiler insure.

It seems that the call of overloaded function are ambiguous (see below)

Have you any idea ?

Thanks


insure -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -I../../include=20
-DLA_COMPLEX_SUPPORT -DHAVE_CONFIG_H -DLinux -g -O2 -Wall -MT blas1pp.lo=20
-MD -MP -MF .deps/blas1pp.Tpo -c blas1pp.cc  -DPIC
WARNING: optimization flag O2 discarded for Insure++ compile
In file included from blas1pp.cc:30:
../../include/lavc.h: In member function `LaVectorComplex&
   LaVectorComplex::operator=3D(double)':
../../include/lavc.h:334: error: call of overloaded `complex(double&)' is
   ambiguous
../../include/lacomplex:578: error: candidates are:
   la::complex<double>::complex(const la::complex<double>&)
../../include/lacomplex:625: error:               =20
   la::complex<double>::complex(double)
../../include/lacomplex:649: error:               =20
   la::complex<double>::complex(const std::complex<double>&)
../../include/lacomplex:587: error:               =20
   la::complex<double>::complex(const la::complex<long double>&)
../../include/lacomplex:586: error:               =20
   la::complex<double>::complex(const la::complex<float>&)
../../include/lacomplex:641: error:               =20
   la::complex<double>::complex(double, double)
Driver: error executing "Run -DHAVE_CONFIG_H -I. -I. -I../..=20
-I../../include -I../../include -DLA_COMPLEX_SUPPORT -DHAVE_CONFIG_H=20
-DLinux -g -O2 -Wall -MT blas1pp.lo -MD -MP -MF .deps/blas1pp.Tpo -c=20
blas1pp.cc -DPIC"
make[3]: *** [blas1pp.lo] Erreur 1
make[3]: Leaving directory `/home/bipop/acary/src/lapackpp-2.4.0/blaspp/s=
rc'
make[2]: *** [all-recursive] Erreur 1
make[2]: Leaving directory `/home/bipop/acary/src/lapackpp-2.4.0/blaspp'
make[1]: *** [all-recursive] Erreur 1
make[1]: Leaving directory `/home/bipop/acary/src/lapackpp-2.4.0'
make: *** [all] Erreur 2



--=20
Vincent ACARY                     		   Charge de recherche
INRIA Rh=F4ne-Alpes    Equipe BIPOP        http://www.inrialpes.fr/bipop/
ZIRST, 655 avenue de l'Europe, MONTBONNOT 38334 ST ISMIER Cedex, FRANCE=20
Bureau D118       tel:+33 (0)4 76 61 52 29     fax:+33 (0)4 76 61 54 77=20

Re: [Lapackpp-devel] Sourceforge e-mail archives showing e-mail addresses on web site

[Christian S. <sti...@tu...>]

Hi Jack,

not that I know of. As a project administrator, I cannot modify any of the 
content of the mailinglist archive. I guess the sf-documentation will list 
this question somewhere, because it surely gets asked more than once.

Christian

Am Freitag, 30. September 2005 06:42 schrieb Jacob (Jack) Gryn:
> I just found out through google alerts that my e-mail address has been put
> on the web archives of the lapackpp-devel list at
> http://sourceforge.net/mailarchive/forum.php?thread_id=6935459
> <http://sourceforge.net/mailarchive/forum.php?thread_id=6935459&forum_id=41
>6 08> &forum_id=41608  (it may appear elsewhere, but this was the only one I
> got notified on from google alerts)
>
> Is it possible to remove my e-mail address from the web archive to prevent
> spam?

[Lapackpp-devel] Sourceforge e-mail archives showing e-mail addresses on web site

[Jacob \(Jack\) G. <jg...@cs...>]

Hi,

 

I just found out through google alerts that my e-mail address has been put
on the web archives of the lapackpp-devel list at
http://sourceforge.net/mailarchive/forum.php?thread_id=6935459
<http://sourceforge.net/mailarchive/forum.php?thread_id=6935459&forum_id=416
08> &forum_id=41608  (it may appear elsewhere, but this was the only one I
got notified on from google alerts)

 

Is it possible to remove my e-mail address from the web archive to prevent
spam?

 

Let me know.

 

Thanks

 

Jack

Re: [Lapackpp-devel] HELP: about Lapack++ on vc6

[Christian S. <sti...@tu...>]

Hi,

Xu Bin schrieb:
> I'm new to Lapack++. I have download  //lapackpp-2.4.0-setup.exe for 32 
> bits windows and installed it on my computer.
> then I use a example surplemented by the package to test the compiler, 
> but there are a lot of errors as follows:
> c:\program files\lapackpp\include\lapackpp\blas1pp.h(217) : error C2039: 
> 'fabs' : is not a member of 'std'

You tried to use the pre-compiled lapackpp-2.4.0-setup.exe with the 
Microsoft Visual C++-Compiler vc6? This will not work. The pre-compiled 
package is only suitable for the mingw32/gcc compiler. As Lapack++ is a 
C++ library, you can use a DLL only with exactly the same compiler as 
you use for the application. So this won't work anyway.

The only alternative would be to try to compile lapack++ from its source 
code with the vc6 compiler. However, I have never done this and I 
believe this requires a lot of work. In other words, on windows you can 
use lapack++ only for the gcc compiler.

Regards,

Christian

[Lapackpp-devel] HELP: about Lapack++ on vc6

[Xu B. <xub...@gm...>]

Hello,
 *I'm new to Lapack++. I have download **lapackpp-2.4.0-setup.exe for 32
bits windows and installed it on my computer.*
*then I use a example surplemented by the package to test the compiler, but
there are a lot of errors as follows:*
c:\program files\lapackpp\include\lapackpp\blas1pp.h(217) : error C2039:
'fabs' : is not a member of 'std'
c:\program files\lapackpp\include\lapackpp\blas3pp.h(259) : error C2039:
'abs' : is not a member of 'std'
c:\program files\lapackpp\include\lapackpp\blas3pp.h(287) : error C2039:
'abs' : is not a member of 'std'
c:\program files\lapackpp\include\lapackpp\blas3pp.h(315) : error C2039:
'abs' : is not a member of 'std'
c:\program files\lapackpp\include\lapackpp\blas3pp.h(334) : error C2039:
'abs' : is not a member of 'std'
c:\program files\lapackpp\include\lapackpp\blas3pp.h(334) : error C2039:
'abs' : is not a member of 'std'
c:\program files\lapackpp\include\lapackpp\blas3pp.h(338) : error C2039:
'abs' : is not a member of 'std'
c:\program files\lapackpp\include\lapackpp\blas3pp.h(338) : error C2039:
'abs' : is not a member of 'std'
c:\program files\lapackpp\include\lapackpp\blas3pp.h(338) : error C2039:
'abs' : is not a member of 'std'
c:\program files\lapackpp\include\lapackpp\blas3pp.h(341) : error C2039:
'abs' : is not a member of 'std'
c:\program files\lapackpp\include\lapackpp\blas3pp.h(341) : error C2039:
'abs' : is not a member of 'std'
c:\my work\numerical\lapack++\my test\1\t1.cpp(140) : error C2039: 'min' :
is not a member of 'std'
c:\my work\numerical\lapack++\my test\1\t1.cpp(140) : error C2065: 'min' :
undeclared identifier
Error executing cl.exe.
Creating browse info file...

Can any one tell me why? Thanks


--
xubin

Re: [Lapackpp-devel] Memory Allocation

[kevin c. <kev...@gm...>]

Thanks, I will try and make such an example.

            Kevin.

---------- Forwarded message ----------
From: Christian Stimming <sti...@tu...>
Date: 16-Sep-2005 11:11
Subject: Re: [Lapackpp-devel] Memory Allocation
To: kev...@gm...
Cc: lap...@li...


Dear Kevin,

thanks for sending the code. However, this code is not (yet) a
standalone example, because you are using many constants that come from
somewhere else. So far I don't yet fully understand the problem. If you
get a segfault, is it possible to obtain a backtrace about where exactly
this segfault occurs? In code like this I would always suspect at first
that some matrix offsets might be out of bounds, which should just as
well give you a segfault. Other than that, the line "LaGenMatDouble
V(D_rows,D_rows);" looks perfectly fine.

Or in other words: I don't know of a segfault in the "normal
construction" of the LaGenMatDouble, aside from when the program really
runs out of memory (for sure this is not a stack/heap problem here, as
the data array is always on the heap). You would need to provide a real
standalone example demonstration of the problem if you need more
assistance from me.

Regards,

Christian


kevin channon schrieb:
> Hi,
>
>    The code that I am using is below.  The aim is to define a matrix,
> V, of size D_rows x D_rows and fill a diagonal band of width ~ M with
> values and then the rest with zeros.  It is symmetric, so I calculate
> the diagonal and super-diagonal elements and then copy these into the
> correct sub-diagonal elements.
>
> ...
>
> This is the offending section of code.  It will work fine until I get
> to N ~ 128 and then gives a segmentation fault.  I can make the fault
> go away again by choosing a sufficiently large M (which reduces the
> size of D_rows), but this is not really practical, as M is a
> meaningful parameter in my model!
>
>   Cheers,
>           Kevin
>
>

Re: [Lapackpp-devel] Memory Allocation

[Christian S. <sti...@tu...>]

Dear Kevin,

thanks for sending the code. However, this code is not (yet) a 
standalone example, because you are using many constants that come from 
somewhere else. So far I don't yet fully understand the problem. If you 
get a segfault, is it possible to obtain a backtrace about where exactly 
this segfault occurs? In code like this I would always suspect at first 
that some matrix offsets might be out of bounds, which should just as 
well give you a segfault. Other than that, the line "LaGenMatDouble 
V(D_rows,D_rows);" looks perfectly fine.

Or in other words: I don't know of a segfault in the "normal 
construction" of the LaGenMatDouble, aside from when the program really 
runs out of memory (for sure this is not a stack/heap problem here, as 
the data array is always on the heap). You would need to provide a real 
standalone example demonstration of the problem if you need more 
assistance from me.

Regards,

Christian


kevin channon schrieb:
> Hi,
> 
>    The code that I am using is below.  The aim is to define a matrix,
> V, of size D_rows x D_rows and fill a diagonal band of width ~ M with
> values and then the rest with zeros.  It is symmetric, so I calculate
> the diagonal and super-diagonal elements and then copy these into the
> correct sub-diagonal elements.
> 
> ...
> 
> This is the offending section of code.  It will work fine until I get
> to N ~ 128 and then gives a segmentation fault.  I can make the fault
> go away again by choosing a sufficiently large M (which reduces the
> size of D_rows), but this is not really practical, as M is a
> meaningful parameter in my model!
> 
>   Cheers,
>           Kevin
> 
> 

Re: [Lapackpp-devel] Memory Allocation

[kevin c. <kev...@gm...>]

Hi,

   The code that I am using is below.  The aim is to define a matrix,
V, of size D_rows x D_rows and fill a diagonal band of width ~ M with
values and then the rest with zeros.  It is symmetric, so I calculate
the diagonal and super-diagonal elements and then copy these into the
correct sub-diagonal elements.

#include<stdio.h>
#include<stdlib.h>
#include<string.h>
#include<iostream>
#include<math.h>
#include<lapackpp.h>=20

int main()
{
...
      int N =3D numberOfLines;        //The value of numberOfLines is
determined earlier
                                                //in the code by
counting the number of lines in a
                                                //data file.
      int M =3D expDegree;             //M is determined earlier in the
file by user input
      int D_rows =3D N-M-1;
      LaGenMatDouble V(D_rows,D_rows);
...

=09for(i=3D0;i<D_rows;i++)
=09{
=09=09sum =3D 0.0;
=09=09for(k=3D0;k<M;k++)
=09=09{
=09=09=09sum +=3D p(k,0)*p(k,0)*y(i-k+M-1,1);
=09=09}
=09=09V(i,i) =3D y(i+M,1) + sum;
=09=09if(!V(i,i))
=09=09{
=09=09=09V(i,i) =3D 1;
=09=09}
=09=09for(j=3Di+1;(j-i)<V_sd;j++)
=09=09{
=09=09=09sum =3D 0.0;
=09=09=09for(k=3D0;k<M-j;k++)
=09=09=09{
=09=09=09=09sum +=3D p(k,0)*p(k+j-i,0)*y(i+M-k-1,1);
=09=09=09}
=09=09=09V(i,j) =3D -p(j-i-1,0)*y(i+M,1) + sum;
=09=09=09if(!V(i,i))
=09=09=09{
=09=09=09=09V(i,i) =3D 1;
=09=09=09}
=09=09}
=09=09for(j=3Di+V_sd;j<D_rows;j++)
=09=09{
=09=09=09V(i,j) =3D 0.0;
=09=09}
=09}
=09for(i=3D0;i<D_rows;i++)
=09{
=09=09for(j=3D0;j<i;j++)
=09=09{
=09=09=09V(i,j) =3D V(j,i);
=09=09}
=09}
...
       return 0;
}


This is the offending section of code.  It will work fine until I get
to N ~ 128 and then gives a segmentation fault.  I can make the fault
go away again by choosing a sufficiently large M (which reduces the
size of D_rows), but this is not really practical, as M is a
meaningful parameter in my model!

  Cheers,
          Kevin


On 16/09/05, Christian Stimming <sti...@tu...> wrote:
> Hi Kevin,
>=20
> can you provide some example code that demonstrates the error?
> Allocation itself usually is not a problem, even for much larger
> matrices (can be verified by ./matrix/testing/tgd 200 200).
>=20
> However, it is true that lapackpp unfortunately doesn't check for
> successful allocation of a new matrix. I'll add this in CVS soon.
>=20
> Regards,
>=20
> Christian
>=20
> kevin channon schrieb:
> > Hi,
> >
> >     I have used lapack++ to allocate memory for a 128x128 element
> > matrix (LaGenMatDouble), which works fine.  When I try to allocate
> > values to the elements I get a segmentation fault.  As I understand
> > it, this means that my program is trying to access memory that has not
> > been allocated to it.  The error goes away if I use a smaller matrix
> > (113x113, for example), so I think that the code works, it just runs
> > out of memory.  I was wondering if this is due to the memory being
> > allocated on the stack instead of the heap, thus not giving much room
> > for large arrays.  If so, how can I get the memory allocated to the
> > heap instead?  If not, does anyone know what the problem could be?
>

Re: [Lapackpp-devel] Memory Allocation

[Christian S. <sti...@tu...>]

Hi Kevin,

can you provide some example code that demonstrates the error? 
Allocation itself usually is not a problem, even for much larger 
matrices (can be verified by ./matrix/testing/tgd 200 200).

However, it is true that lapackpp unfortunately doesn't check for 
successful allocation of a new matrix. I'll add this in CVS soon.

Regards,

Christian

kevin channon schrieb:
> Hi,
> 
>     I have used lapack++ to allocate memory for a 128x128 element
> matrix (LaGenMatDouble), which works fine.  When I try to allocate
> values to the elements I get a segmentation fault.  As I understand
> it, this means that my program is trying to access memory that has not
> been allocated to it.  The error goes away if I use a smaller matrix
> (113x113, for example), so I think that the code works, it just runs
> out of memory.  I was wondering if this is due to the memory being
> allocated on the stack instead of the heap, thus not giving much room
> for large arrays.  If so, how can I get the memory allocated to the
> heap instead?  If not, does anyone know what the problem could be?

[Lapackpp-devel] Memory Allocation

[kevin c. <kev...@gm...>]

Hi,

    I have used lapack++ to allocate memory for a 128x128 element
matrix (LaGenMatDouble), which works fine.  When I try to allocate
values to the elements I get a segmentation fault.  As I understand
it, this means that my program is trying to access memory that has not
been allocated to it.  The error goes away if I use a smaller matrix
(113x113, for example), so I think that the code works, it just runs
out of memory.  I was wondering if this is due to the memory being
allocated on the stack instead of the heap, thus not giving much room
for large arrays.  If so, how can I get the memory allocated to the
heap instead?  If not, does anyone know what the problem could be?

[Lapackpp-devel] Re: Lapack++ v2.3

[Christian S. <sti...@tu...>]

Dear Kevin,

(discussion of lapack++ should be done on the mailing list 
lapackpp-devel, never only with individual developers! Thanks.)

K. Channon schrieb:
>  I am trying to use the Lapack++ library in a program that I am making. 
> I am using Suse linux version 9.0, on i686. I could not find a .rpm 
> package for suse on i686, so I have installed the i586 versions of 
> lapack++, lapack & blas. Installation resulted in the files liblapack
> liblapackpp and libblas (with a number of extensions, including .a & .so 
> ) being inserted into the directory /usr/lib, which I believe is 
> correct. 

Sounds quite correct. You should say where you got your "i586 versions" 
from (URL or similar) and whether that was rpm or .tar.gz or whatever, 
otherwise I cannot tell whether these are correctly built or might be 
problematic. More detail, please.

> I have written a small test program which is as follows
> 
> 0  #include<stdio.h>
> 1  #include<.h>

<.h> ?!? Sounds wrong.

> 2  3  int main()
> 4  {
> 5      printf("\nHello!\n");
> 6  7    LaGenMatDouble A(2,2);
> 8
> 9    return 0;
> 10 }
> 
> I can compile this program with lines 1 & 7 commented out using the 
> compile statement
> 
> g++ test.cc -o test.out
> 
> If only line 7 is commented out then I can compile the program with
> 
> g++ test.cc -I/usr/include/lapackpp -o test.out

Of course you need to add that include directory. That is the normal 
case with any larger library.

> now, when I try compiling the program with no lines commented out, using 
> the compile statement
> 
> g++ test.cc -I/usr/include/lapackpp -o test.out -L/usr/lib -llapackpp 
> -llapack -lblas
> 
> I get an error saying:
> 
> /usr/lib/liblapackpp.so: undefined reference to `d_sign'
> /usr/lib/liblapack.so: undefined reference to `e_wsfe'

That depends on the package built, and that is also a requirement of 
LAPACK and not of Lapack++. In principle that should be explained by 
documentation of LAPACK, not by me or the documentation of Lapack++, or 
put the other way: You have to blame LAPACK, not me. However, in the rpm 
packages I provide you usually have to add "-lm -lgcc_s" after the 
"-lblas".

When building an application based on lapack++ I usually use 
autoconf/automake anyway, and lapack++ provides an autoconf macro in the 
file acx_lapackpp.m4 that can directly be used in that build system. The 
necessary linker flags will be determined by that autoconf macro. That's 
why the documentation doesn't describe this in more detail.

Christian

[Lapackpp-devel] Re: bugs in reference counting in vd.{cc,h}?

[Christian S. <sti...@tu...>]

Dear Brian,

Brian White schrieb:
> I may have another bug.  I can't pinpoint exactly what the problem is, but
> I can manifest it repeatedly and I can fix it. :)
> 
> I've included a program called manifestMemProb.C, which is similar to the
> last program I sent out.  It creates two different views of a matrix (plus
> the original) and modifies them.  It does the same procedure on a
> different matrix.  Somehow, the second matrix is being corrupted, as you
> can see in the file manifestMemProb.incorrect.

No, there is not a bug. Instead, it seems you didn't understand the 
implications of the LaGenMatDouble constructor that you used. The 
LaGenMatDouble(int, int) constructor clearly states: "Matrix elements 
are NOT initialized!" (see 
http://lapackpp.sourceforge.net/html/classLaGenMatDouble.html#z41_1 ) -- 
and that is precisely what you see here. If you want an all-zero matrix, 
you need to do

   LaGenMatDouble A(10,10);
   A = 0.0;

The reason for this is that the extra initialization (setting all 
elements to zero) can be an expensive operation (think of a 1e5x1e5 
matrix), and it really depends on the application whether this is really 
needed. Therefore the standard constructor will only allocate the 
memory, but the values inside that memory can be anything. It is just 
pure coincidence that the first matrix in your test program happened to 
contain "almost" zeros.

Lapackpp is explicitly intended for "high-performance linear algebra", 
and in that field you really need to think for yourself about which 
prerequisites you depend on and which you don't. The library will give 
you many choices, especially all the high-performance choices. 
Construction without initialization clearly is one of those choices.

Christian

[Lapackpp-devel] bugs in reference counting in vd.{cc,h}?

[Brian W. <bw...@cs...>]

> Yes, that's true and it's a feature :-) .

Thanks for the explanation, Christian.

I may have another bug.  I can't pinpoint exactly what the problem is, but
I can manifest it repeatedly and I can fix it. :)

I've included a program called manifestMemProb.C, which is similar to the
last program I sent out.  It creates two different views of a matrix (plus
the original) and modifies them.  It does the same procedure on a
different matrix.  Somehow, the second matrix is being corrupted, as you
can see in the file manifestMemProb.incorrect.

Like I said, I was unable to track down the exact problem.  It may be
related to new'ing and delete'ing 0 byte chunks of memory?  I added a
check for n=0 in the following constructor:

VectorDouble::VectorDouble(int n=0)

In that case, I set ref_count = 0 and p->data = data = NULL:

 VectorDouble::VectorDouble(int n=0)
{
    assert(n>=0);
    p = new vrefDouble;
    p->sz = n;
    if ( n > 0 ) {
      p->data = data = new double[n];
      p->ref_count = 1;
    } else {
      p->data = data = NULL;
      p->ref_count = 0;
    }
}

I then only decremented ref_count if it was > 0.  And asserted explicitly
that p->data was non-NULL before delete'ing it.  However, even in the
original code this assertion was never hit.  At any rate, this seems to
have fixed the manifestation of the bug.  Sorry I can't provide a better
understanding of what was going on.

I ended up changing all of the constructors to do something similar.  I
also changed the VectorDouble destructor and ref (where ref_count is
decremented) as described above.  Also, in ref I don't increment the
ref_count unless the associated data is non-NULL.  In short then:
ref_counts are only > 0 when data != NULL.  Also, I never allocate or free
0-byte data.

I imagine other vectors will have the same type of problems, but I didn't
fix those.

I'm sending my modified vd.cc and vd.h.

By the way, please let me know if I'm somehow abusing the interface in my
example such that I am causing the seemingly incorrect behavior.

Thanks,
Brian

Re: [Lapackpp-devel] bugs in operator= for LaIndex/LaGenMatComplex/LaGenMatDouble?

[Christian S. <sti...@tu...>]

Dear Brian,

Brian White schrieb:
> In LaIndex::oeprator=(const LaIndex &i), the following definition
> ignores the increment of the LaIndex it is copying:
> 
>         inline LaIndex& operator=(const LaIndex& i){
>             start_=i.start_; inc_=1; end_=i.end_;
>             return *this;}
> 
> I think inc_=1 should be inc_=i.inc_:

Yes, that's a bug. Thanks for reporting this. It has been fixed in CVS now.

> Also, LaGenMatComplex::operator=(COMPLEX s) and
> LaGenMatDouble::operator=(double s) seem to be problematic since both
> assign to the vectorDouble v without accounting for the active view
> of the LaGenMatDouble object.  I believe this means that if we assign
> (via operator=) through a submatrix view, the entire matrix will be
> effected.

Yes, that's a bug, too. I've fixed this by first checking for unit 
stride and then either assigning to the vectorDouble object (*much* 
faster!) or iterating over all elements.

> Below is some example code (taken essentially from the Lapack++ 1.1
> manual when it was still being developed by NIST/Tennessee/Oak Ridge).
> I've included what I believe to be the correct output and also
> the output I get before making the above changes.

Thanks for adding this. It helped a lot to verify the correct fix.

> By the way, this differs from the example in the manual only
> in so far as assignments are replaced by references.
> i.e., B = A(II,II) is replaced below by B.ref(A(II,II)).
> If I'm reading that manual correctly, B = A(II,II) should
> establish B as a reference to elements in A.  Instead it
> appears to perform a (deep) copy.

Yes, that's true and it's a feature :-) . Seriously, I've decided 
against that original lapackpp-1.1 approach (now also more clearly 
documented in the header) because of two reasons: 
LaGenMatDouble::LaGenMatDouble(const LaGenMatDouble &) [i.e. the copy 
constructor] was working as a by-value deep copy anyway. So having 
operator= [i.e. the copy assignment] work as a by-reference copy means 
that the copy constructor and the copy assignment were doing two 
different things, which is a bad thing. Secondly, many users of lapackpp 
got quite confused when they constructed a new LaGenMatDouble, assigned 
an initial value by the copy assignment (i.e. LaGenMatDouble B = A;) and 
to their surprise discovered that the newly created matrix won't behave 
as a standalone object but rather as a reference to some other object. 
If you want, you can say that the by-reference semantics were too 
difficult to grok for the average programmer. Therefore I changed the 
copy assignment to be the same as the copy constructor: a by-value deep 
copy. If you want a by-reference copy, use ref(). Those who use it are 
probably quite sure they know what they do.

Regards,

Christian

[Lapackpp-devel] bugs in operator= for LaIndex/LaGenMatComplex/LaGenMatDouble?

[Brian W. <bw...@cs...>]

Hello,

I think I've uncovered a few bugs.

In LaIndex::oeprator=(const LaIndex &i), the following definition
ignores the increment of the LaIndex it is copying:

        inline LaIndex& operator=(const LaIndex& i){
            start_=i.start_; inc_=1; end_=i.end_;
            return *this;}

I think inc_=1 should be inc_=i.inc_:

        inline LaIndex& operator=(const LaIndex& i){
            start_=i.start_; inc_=i.inc_; end_=i.end_;
            return *this;}

Also, LaGenMatComplex::operator=(COMPLEX s) and
LaGenMatDouble::operator=(double s) seem to be problematic since both
assign to the vectorDouble v without accounting for the active view
of the LaGenMatDouble object.  I believe this means that if we assign
(via operator=) through a submatrix view, the entire matrix will be
effected.

So, instead of doing

    v = s;

in both LaGenMatComplex::operator=(COMPLEX s) and
LaGenMatDouble::operator=(double s), we should instead have:

    int i,j;

    for (j=0; j<size(1); j++)
    {
        for (i=0; i<size(0); i++)
        {
            (*this)(i,j) = s;
        }
    }

and something similar for the complex case.  Note that this
mirrors operator+= (obviously, with += replaced by =).

Below is some example code (taken essentially from the Lapack++ 1.1
manual when it was still being developed by NIST/Tennessee/Oak Ridge).
I've included what I believe to be the correct output and also
the output I get before making the above changes.

By the way, this differs from the example in the manual only
in so far as assignments are replaced by references.
i.e., B = A(II,II) is replaced below by B.ref(A(II,II)).
If I'm reading that manual correctly, B = A(II,II) should
establish B as a reference to elements in A.  Instead it
appears to perform a (deep) copy.

Thanks,
Brian

int main(int argc, char **argv)
{

  LaGenMatDouble A(10,10), B, C;
  LaIndex II(1,9,2);
  LaIndex JJ(1,1,1);

  B.ref(A(II,II));   // B references the following elements of A:
                     //    (1, 1), (1, 3), (1, 5), (1, 7), (1, 9)
                     //    (3, 1), (3, 3), (3, 5), (3, 7), (3, 9)
                     //    (5, 1), (5, 3), (5, 5), (5, 7), (5, 9)
                     //    (7, 1), (7, 3), (7, 5), (7, 7), (7, 9)
                     //    (9, 1), (9, 3), (9, 5), (9, 7), (9, 9)
  B(2,3) = 3.1;      // Set A(5,7) = 3.1

  C.ref(B(LaIndex(2,2,4), JJ));
                     // C references the following elements of B:
                     //    (2, 1)
                     // C references the following elements of A:
                     //    (5, 3)

  C = 1.1;           // Set B(2,1) = A(5,3) = 1.1

  cout << A << endl;
  cout << B << endl;
  cout << C << endl;

  return 0;
}

Correct output:

0  0  0  0  0  0  0  0  0  0
7.94687e-311  0  0  0  0  0  0  0  0  0
0  0  0  0  0  0  0  0  0  0
0  0  0  0  0  0  0  0  0  0
0  0  0  0  0  0  0  0  0  0
0  0  0  1.1  0  0  0  3.1  0  0
0  0  0  0  0  0  0  0  0  0
0  0  0  0  0  0  0  0  0  0
0  0  0  0  0  0  0  0  0  0
0  0  0  0  0  0  0  0  0  0

// Note the following matrix is 5x5
0  0  0  0  0
0  0  0  0  0
0  1.1  0  3.1  0
0  0  0  0  0
0  0  0  0  0

1.1


Incorrect output:

1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1
1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1
1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1
1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1
1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1
1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1
1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1
1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1
1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1
1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1

// The following matrix is 9x9 because the
// view (II=(1,9,2),II) is incorrectly copied to
// (I=(1,9,1),I) when the increment is set to 1
// irrespective of the LaIndex being copied.

// Also, we have assigned to the entire matrix,
// rather than simply the view specified in
//   C.ref(B(LaIndex(2,2,4), JJ));
1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1
1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1
1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1
1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1
1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1
1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1
1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1
1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1
1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1  1.1

1.1

[Lapackpp-devel] RE: Problems when try to build lapackpp on Debian Linux

[<hon...@ag...>]

Hello Christian,

         The problem is solved. I change to another lapack package which =
is a rpm package.
After building it and removing the blas of the debian linux, I build the =
lapackpp successfully.
Thank you for the help.

Best regards,
hongwei

[Lapackpp-devel] RE: Problems when try to build lapackpp on Debian Linux

[<hon...@ag...>]

Sorry. The error message when doing the make check should be=20

make[3]: Entering directory `/hdb2/MIMO/lapackpp-2.3.0/blaspp/testing'
if g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -I../../include =
-DLA_COMPLEX_SUPPORT -DHAVE_CONFIG_H -DLinux     -g -O2 -Wall -MT =
tblasd++.o -MD -MP -MF ".deps/tblasd++.Tpo" -c -o tblasd++.o =
tblasd++.cc; \
then mv -f ".deps/tblasd++.Tpo" ".deps/tblasd++.Po"; else rm -f =
".deps/tblasd++.Tpo"; exit 1; fi
/bin/sh ../../libtool --tag=3DCXX --mode=3Dlink g++  -g -O2 -Wall  =
-L../../blaspp/src -L../../src -llapackpp -llapack.2.0 -L/usr/lib =
-lcblas.2.3 -lf77blas.2.3 -latlas.2  =
-L/usr/lib/gcc-lib/i386-linux/2.95.4 -lg2c -lm  -o tblasd++  tblasd++.o
g++ -g -O2 -Wall -o .libs/tblasd++ tblasd++.o  =
-L/hdb2/MIMO/lapackpp-2.3.0/blaspp/src -L/hdb2/MIMO/lapackpp-2.3.0/src =
/hdb2/MIMO/lapackpp-2.3.0/src/.libs/liblapackpp.so -llapack.2.0 =
-L/usr/lib -lcblas.2.3 -lf77blas.2.3 -latlas.2 =
-L/usr/lib/gcc-lib/i386-linux/2.95.4 -lg2c -lm -Wl,--rpath =
-Wl,/usr/local/lib
/usr/bin/ld: cannot find -llapack.2.0
collect2: ld returned 1 exit status
make[3]: *** [tblasd++] Error 1
make[3]: Leaving directory `/hdb2/MIMO/lapackpp-2.3.0/blaspp/testing'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory `/hdb2/MIMO/lapackpp-2.3.0/blaspp/testing'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/hdb2/MIMO/lapackpp-2.3.0/blaspp'
make: *** [check-recursive] Error 1

-----Original Message-----
From: KONG,HONG-WEI (A-China,ex1)=20
Sent: 2005=C4=EA8=D4=C223=C8=D5 12:43
To: 'Christian Stimming'; KONG,HONG-WEI (A-China,ex1)
Cc: lap...@li...
Subject: RE: Problems when try to build lapackpp on Debian Linux


Hello, Christian,

>This means that lapack++ cannot link correctly against the LAPACK and
>BLAS libraries. This will also mean that any other project using
>lapack++ cannot run, as you have discovered with mimolib. You need to
>fix this first, otherwise the mimolib project will not work anyway.

   Agree with you on this. I also suspect that the link of LAPACK and =
BLAS library is not
correct.

>In any case, the problem is that your LAPACK and BLAS package have not
been correctly installed.=20

I have used the lapack package of Debian Linux first. Attached please =
find the ./configure result.
Before I do this, I have made sure that there is no different version of =
LAPACK lib exists.
The version of LAPACK I used is lapack_3.0.20000531a-28_i386.deb. I =
install it with the usual=20
package manager. That is, I use 'apt-get install' and there is no =
conflict, no error during the install.


Unfortunately, the make check
failed in this case. Please refer to the attached file conf.result1. =
Hopefully this will help you to locate=20
the problem. The make test result is as follows:

make[3]: Entering directory `/hdb2/MIMO/lapackpp-2.3.0/blaspp/testing'
if g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -I../../include =
-DLA_COMPLEX_SUPPORT -DHAVE_CONFIG_H -DLinux     -g -O2 -Wall -MT =
tblasd++.o -MD -MP -MF ".deps/tblasd++.Tpo" -c -o tblasd++.o =
tblasd++.cc; \
then mv -f ".deps/tblasd++.Tpo" ".deps/tblasd++.Po"; else rm -f =
".deps/tblasd++.Tpo"; exit 1; fi
/bin/sh ../../libtool --tag=3DCXX --mode=3Dlink g++  -g -O2 -Wall  =
-L../../blaspp/src -L../../src -llapackpp -llapack.2.0 -L/usr/lib =
-lcblas.2.3 -lf77blas.2.3 -latlas.2  =
-L/usr/lib/gcc-lib/i386-linux/2.95.4 -lg2c -lm  -o tblasd++  tblasd++.o
mkdir .libs
g++ -g -O2 -Wall -o tblasd++ tblasd++.o  =
-L/hdb2/MIMO/lapackpp-2.3.0/blaspp/src -L/hdb2/MIMO/lapackpp-2.3.0/src =
-llapackpp -llapack.2.0 -L/usr/lib -lcblas.2.3 -lf77blas.2.3 -latlas.2 =
-L/usr/lib/gcc-lib/i386-linux/2.95.4 -lg2c -lm
/usr/bin/ld: cannot find -llapackpp
collect2: ld returned 1 exit status
make[3]: *** [tblasd++] Error 1


Then I suspect that the lapack library I am using is not good. So I =
remove the lapack package from my
Debian Linux box and try to use the self-built LAPACK. The package I am =
using is from
www.netlib.org/lapack. The build and installation of this package is =
really different from usual packages. It=20
will build the library under the directory where it is built and 'make =
install' makes no difference. I try to
run lapackpp configure as follows:

./configure --with-blas=3D/hdb2/MIMO/LAPACK/blas_LINUX.a =
--with-lapack=3D/hdb2/MIMO/LAPACK/lapack_LINUX.a.

It fails (refer to conf.result2).

Since the configure script can't find the self-built library, I made =
change to force it to use the self-built library. That is
why the library in the build directory is used.



>In any case, I'm also confused why your LAPACK library filenames end in
>".a", i.e. they are static libraries. On a recent Linux you would =
always
>have ".so" files, shared object, i.e. dynamic libraries. This again
>looks like you didn't install the LAPACK package correctly. Again,
>please ask the Debian guys on how to do this correctly on Debian.

As mentioned above, the self-built LAPACK package is from =
www.netlib.org/lapack. The built result
is really different from usual package. It build static libraries.

Maybe a better questions is which lapack package you are using when you =
build lapackpp.=20
Will you please tell me on which Linux distribution you have tested to =
build lapackpp?

Best regards,
Hongwei

[Lapackpp-devel] RE: Problems when try to build lapackpp on Debian Linux

[<hon...@ag...>]

Hello, Christian,

>This means that lapack++ cannot link correctly against the LAPACK and
>BLAS libraries. This will also mean that any other project using
>lapack++ cannot run, as you have discovered with mimolib. You need to
>fix this first, otherwise the mimolib project will not work anyway.

   Agree with you on this. I also suspect that the link of LAPACK and =
BLAS library is not
correct.

>In any case, the problem is that your LAPACK and BLAS package have not
been correctly installed.=20

I have used the lapack package of Debian Linux first. Attached please =
find the ./configure result.
Before I do this, I have made sure that there is no different version of =
LAPACK lib exists.
The version of LAPACK I used is lapack_3.0.20000531a-28_i386.deb. I =
install it with the usual=20
package manager. That is, I use 'apt-get install' and there is no =
conflict, no error during the install.


Unfortunately, the make check
failed in this case. Please refer to the attached file conf.result1. =
Hopefully this will help you to locate=20
the problem. The make test result is as follows:

make[3]: Entering directory `/hdb2/MIMO/lapackpp-2.3.0/blaspp/testing'
if g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -I../../include =
-DLA_COMPLEX_SUPPORT -DHAVE_CONFIG_H -DLinux     -g -O2 -Wall -MT =
tblasd++.o -MD -MP -MF ".deps/tblasd++.Tpo" -c -o tblasd++.o =
tblasd++.cc; \
then mv -f ".deps/tblasd++.Tpo" ".deps/tblasd++.Po"; else rm -f =
".deps/tblasd++.Tpo"; exit 1; fi
/bin/sh ../../libtool --tag=3DCXX --mode=3Dlink g++  -g -O2 -Wall  =
-L../../blaspp/src -L../../src -llapackpp -llapack.2.0 -L/usr/lib =
-lcblas.2.3 -lf77blas.2.3 -latlas.2  =
-L/usr/lib/gcc-lib/i386-linux/2.95.4 -lg2c -lm  -o tblasd++  tblasd++.o
mkdir .libs
g++ -g -O2 -Wall -o tblasd++ tblasd++.o  =
-L/hdb2/MIMO/lapackpp-2.3.0/blaspp/src -L/hdb2/MIMO/lapackpp-2.3.0/src =
-llapackpp -llapack.2.0 -L/usr/lib -lcblas.2.3 -lf77blas.2.3 -latlas.2 =
-L/usr/lib/gcc-lib/i386-linux/2.95.4 -lg2c -lm
/usr/bin/ld: cannot find -llapackpp
collect2: ld returned 1 exit status
make[3]: *** [tblasd++] Error 1


Then I suspect that the lapack library I am using is not good. So I =
remove the lapack package from my
Debian Linux box and try to use the self-built LAPACK. The package I am =
using is from
www.netlib.org/lapack. The build and installation of this package is =
really different from usual packages. It=20
will build the library under the directory where it is built and 'make =
install' makes no difference. I try to
run lapackpp configure as follows:

./configure --with-blas=3D/hdb2/MIMO/LAPACK/blas_LINUX.a =
--with-lapack=3D/hdb2/MIMO/LAPACK/lapack_LINUX.a.

It fails (refer to conf.result2).

Since the configure script can't find the self-built library, I made =
change to force it to use the self-built library. That is
why the library in the build directory is used.



>In any case, I'm also confused why your LAPACK library filenames end in
>".a", i.e. they are static libraries. On a recent Linux you would =
always
>have ".so" files, shared object, i.e. dynamic libraries. This again
>looks like you didn't install the LAPACK package correctly. Again,
>please ask the Debian guys on how to do this correctly on Debian.

As mentioned above, the self-built LAPACK package is from =
www.netlib.org/lapack. The built result
is really different from usual package. It build static libraries.

Maybe a better questions is which lapack package you are using when you =
build lapackpp.=20
Will you please tell me on which Linux distribution you have tested to =
build lapackpp?

Best regards,
Hongwei

[Lapackpp-devel] Re: Problems when try to build lapackpp on Debian Linux

[Christian S. <sti...@tu...>]

Hello Hongwei,

https://sourceforge.net/support/getsupport.php?group_id=99696 says: You
may contact the lapackpp project by sending email to the lapackpp-devel
mailing list at lap...@li.... In the future,
please always address your question to that mailinglist, *never* only to
individual developers.

hon...@ag... schrieb:
> Hello, Christian:
> 
>            I want to try the mimolib provided at URL: http://simthetic.sourceforge.net/. So I try to build lapackpp on my Debian Linux box. I noticed that prior installing lapackpp, I need to install lapack and blas. I have tried two approaches:1) using the lapack and Blas  package of Debian Linux. 2) Build lapack from http://www.netlib.org/lapack/. I have met some problems with both approaches. The problems are the following:
> 
> 1) With both approaches, the make and make install succeed. However, If I run make check. There will be an error saying that the lapack library not existing. In fact, they do exist.  The error message for approach 2) is given below. For approach 1), the error is similar, it says that lapack.2.0  not found.
> 
> make[3]: Entering directory `/hdb2/MIMO/lapackpp-2.3.0/blaspp/testing'
> /bin/sh ../../libtool --tag=CXX --mode=link g++  -g -O2 -Wall  -L../../blaspp/src -L../../src -llapackpp -l/hdb2/MIMO/LAPACK/lapack_LINUX.a -L/usr/lib -l/hdb2/MIMO/LAPACK/blas_LINUX.a -lf77blas.2.3 -latlas.2  -L/usr/lib/gcc-lib/i386-linux/2.95.4 -lg2c -lm  -o tblasd++  tblasd++.o
> g++ -g -O2 -Wall -o .libs/tblasd++ tblasd++.o  -L/hdb2/MIMO/lapackpp-2.3.0/blaspp/src -L/hdb2/MIMO/lapackpp-2.3.0/src /hdb2/MIMO/lapackpp-2.3.0/src/.libs/liblapackpp.so -l/hdb2/MIMO/LAPACK/lapack_LINUX.a -L/usr/lib -l/hdb2/MIMO/LAPACK/blas_LINUX.a -lf77blas.2.3 -latlas.2 -L/usr/lib/gcc-lib/i386-linux/2.95.4 -lg2c -lm -Wl,--rpath -Wl,/usr/local/lib
> /usr/bin/ld: cannot find -l/hdb2/MIMO/LAPACK/lapack_LINUX.a


This means that lapack++ cannot link correctly against the LAPACK and
BLAS libraries. This will also mean that any other project using
lapack++ cannot run, as you have discovered with mimolib. You need to
fix this first, otherwise the mimolib project will not work anyway.

In any case, the problem is that your LAPACK and BLAS package have not
been correctly installed. Somehow the lapack++ checks during its
./configure got the idea that the linker arguments for linking against
LAPACK should be -l/hdb2/MIMO/LAPACK/lapack_LINUX.a . That location
looks rather like the place where you compiled LAPACK, but not where you
installed it, so I would guess you didn't use the correct way of
installing the LAPACK package. Installing such a package should firstly
be tried in your distribution's package manager. I would therefore
strongly suggest you should use the LAPACK and BLAS packages of your
Debian version (by the way you didn't say which version), but since I
don't use Debian I can't tell you more than that. If in doubt, please
ask on the Debian forums how to do that.

But since you now already installed LAPACK and BLAS manually in addition
to the Debian packages, you need to make sure that these two don't
interfere with each other. It is a common mistake to install such an
extra package manually (e.g. into /usr/lib/liblapack.so*) and then
install it also by the package manager, but then some files in
/usr/lib/... are from the package manager's packet and others are from
the manual installation. This will almost surely result in a broken
LAPACK installation such as you described one.

Another common mistake is that you have one version of a library in
/usr/lib/liblapack... and another version in /usr/local/lib/liblapack...
and the files from both interfere with each other. You should make sure
to have only one version of LAPACK installed, and the other version
should be removed completely, especially files in /usr/lib/ and
/usr/local/lib/.

In any case, I'm also confused why your LAPACK library filenames end in
".a", i.e. they are static libraries. On a recent Linux you would always
have ".so" files, shared object, i.e. dynamic libraries. This again
looks like you didn't install the LAPACK package correctly. Again,
please ask the Debian guys on how to do this correctly on Debian.


> 2)I have no problem with building mimolib. However, when I try to run the examples under mimolib/src/parameter, there will be an error reporting
>
>
> simthetic: relocation error: /usr/local/lib/liblapackpp.so.1:
undefined symbol: zgemm_.


As long as "make check" in lapack++ doesn't run correctly, mimolib will
also not run correctly.


> BTW, I don't know why during the ./configure stage, the check of cheev_ in lapack will fail no matter I use lapack library from Deian package or self-built lapack package. Thank you very much.


If it were a problem then ./configure would abort and show an error
message. If ./configure completes, things should be fine.

Regards,

Christian

[Lapackpp-devel] Re: About Lapackpp

[Christian S. <sti...@tu...>]

Hi Claudio,

thank you for your kind words about lapackpp. In fact I also created lapackpp 
during my Ph.D. thesis, which I'm still working at. I'm glad you listed this 
library in these websites. That's very nice, thank you. 

I don't have any plans for further documentation, because I don't have that 
much time for this and I'm also not that good at writing something like this. 
As I wrote on the documentation mainpage (http://lapackpp.sf.net), the only 
detailed text about lapack++ is the "Lapack++ user guide" written in 1998 (I 
think), but this was already outdated for the original lapack++-1.1 from 
which I started this fork. So maybe these old documents would be a good 
starting point to write something more coherent for the up-to-date 
lapackpp... Whatever. Feel free to contribute, and I will happily either 
integrate it or link to it. 

Best regards,

Christian

Am Sonntag, 31. Juli 2005 19:15 schrieben Sie:
> Hi
>
> I want congratulate with you
> for the library you realized Lapackpp.
> It was, and it is very useful for me, and I realy appreciated it.
> I put two links to Lapack++ in my websites.
>
> http://freescience.info/index.php
> http://attaccalite.altervista.org/nofortran.php.
>
> I  want ask you if I can help you to develop or to advertise
> Lapack++ library, even if in this moment I have to finish
> my Phd thesis.
> For example it sould be nice to have a page
> with examples and guide. (like for GSL).
> Let me know.
>
> Best Regards
> Claudio Attaccalite
>
>
> ==========================================================
> Claudio Attaccalite
>
> S.I.S.S.A.
> Via Beirut 2-4 34014 Grignano (TS)
> email: at...@si...
>
> ICQ number: 23970278
> Skype: claudioattaccalite
> web site: www.attaccalite.altervista.org
> ===========================================================
> A quart of ale is a dish for a king.
>                                       -William Shakespeare                 
>                          			 Winter's Tale