lapackpp-devel — Discussion of Lapack++ development

Re: [Lapackpp-devel] Error in LaGenMatDouble::copy(...) and other questions

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dominik Wagenfuehr schrieb:
> So, I have attached the three files for LaSymmBandMatDouble and
> LaSymmBandFactDouble. I hope this mailing list accept attachments...

You didn't send it to the mailing list, only to me directly. In the
future please make sure you always send a CC to the mailing list (or
vice versa, but I still suggest sending to both, see [1]).

> Most of the sybmd.h-parts are original. I have only commented them
> properly. There was a copy-Functon in sybmd.cc but however I've only got
> an error if I remove the "inline" from sybmd.h as you suggested the last
> time. So I deleted this copy-function (It was wrong anyway!) and add a
> new one in sybmd.h. Further the programmer forgot to reset N_ and kl_
> when copying or referencing another matrix.

Ok, thanks for fixing the missing parts. Some remarks:

* Please always use the code from CVS, now that you're actually working
with it. I already did some changes. This time I did the merging myself,
but in the future it is expected that any patches are against the
up-to-date CVS, not any released versions (which might already be
outdated). See [2] for CVS.

* As for inline vs. non-inline: I want to reduce the "inline" functions
to a minimum, because they contradict the OO-paradigm of "hiding the
implementation" (and make debugging harder, among other things).
Therefore if I review a class, I want to keep only those methods
"inline" where it actually makes sense. Inlining a function makes sense
if and only if the execution cost of the function is on the order of the
cost of the function call. OTOH if the cost of the function call is
negligible compared to the execution cost of the function, then inlining
is complete nonsense. Most prominent example here is copy(), which
obviously has a large execution cost, so there is no point at all in
marking this as inline. Same for any constructor. According to this
criterion I've moved many functions to the .cc file, and I've moved the
operator() to the header file, because this one is the counterexample
where inlining *does* make sense. Also, having the operator() inline
enables the client application to decide on the amount of error checking
by defining or not defining LA_BOUNDS_CHECK, which was the whole point
of that macro.

* In the other functions I'd like to encourage you to re-use more of the
existing functions, i.e. have copy() simply call operator=() or vice versa.

> Please take a close look at the documentation. I'm not that much
> experienced with doxygen syntax... Most parts I have copied from gmd.h.
> I hope this is okay. :)

Sure. Looks good. I'll have one last round of documentation proofreading
 during the next hour, but then you have those files (in CVS) back to
your work without more interference from me.

> The class in sybfd.h should be clear. The function
> LaSymmBandMatFactorize is mostly original. The serious error was
> 
> integer = A.size(0)
> 
> what was incorrect, because it returns the wrong dimension.
> 
> The first LaLinearSolve-function is original too. I only set the info
> flags...

Ok. Looks good on a first glance. I accepted your file unchanged, but
mostly because the original one was complete nonsense anyway :-) . If
possible, please think about splitting the code to a .cc file so that
only the useful functions stay inline and the others are defined in the
.cc file. Also, please think about adding a test program (in
matrix/test/blablabla.cc) so that the correct functioning can be tested
automatically.

> The second LaLinearSolve-function is because often people want to solve
> a matrix and have no need to factorize them before. So this function
> will do it.

I would prefer not to have such convenience functions, because
eventually this might drive people to not think about the internally
used factorization. Once people know that the solving is done in two
steps, they might keep in mind that the left hand side in many
applications could be reused several times, hence they would require
only half the calculations. However, the decision about which functions
to add and which not is obviously in part a matter of taste, so in this
case it's probably fine. In that LaLinearSolve() case you even made this
quite clear by simply calling these other functions.

Actually I'm not so sure whether the function LaSymmBandMatFactorize()
is useful. If that functionality better lives inside some
LaSymmBandFactDouble class methods then I'd encourage you to remove the
function and move the code to suitable class methods.

> The LaLinearSolveIP-function is because I think often the arguments can
> be overwritten because they are not needed any longer. So it would be
> rather useless to allocate memory for a new factorization. I hope you agree.

An additional "IP"-function is almost always a *good* thing. You might
even think about implementing the non-IP version of that function in
terms of the IP-version... but I think I've already said this.

> Several other things:
> 
> 1. You have written in gmd.h
> 
>        * Optional runtime bounds checking (0<=i<=m, 0<=j<=n) is set
>        * by the compile time macro LA_BOUNDS_CHECK.
> 
> This is wrong, it should be (0<=i<m, 0<=j<n), m and n are already out of
> bounds.

You are correct. The comment is wrong.

> 2. What is the correct meaning of A.size(int d) ? I think the code
> 
>   for (int i=0; i<A.size(0); i++)
>     for (int j=0; j<A.size(1); j++)
>       A(i,j)=1.0;
> 
> should never fail. Do you agree? 

No, I think size() should give the dimensions in terms of the
"mathematical" viewpoint, not in terms of the internal storage
implementation. So I think this code in fact does fail as soon as the
internal storage is different from the "mathematical" matrix dimension
in question, which is probably true for all matrix classes except the
"General" (dense) ones. At least that's what I *thought* until I started
to look at LaSymmBandMatDouble::size() --

> If so, the size-function in
> LaSymmBandMatDouble is still wrong, because it does not return size(0)=N
> and size(1)=N but size(0)=2*P+1 and size(1)=N. I don't know if it's part
> of the programmer (of the library) to set this correct so that size(0)
> returns N or if the user of the library should pay attention to this.
> What do you think?

The size() function in LaSymmBandMatDouble might very well be wrong. If
you're redesigning this class, the decision is pretty much up to you.
Only make sure you clearly explain the meaning of size(), especially if
it is different from my described meaning above which would hold for the
General/dense matrices.

Regards,

Christian


[1]
http://cstimming.de/index.php?option=com_content&task=view&id=28&Itemid=41

[2] http://sourceforge.net/cvs/?group_id=99696
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRV2RwmXAi+BfhivFAQJ+DwP8CcQVRXtK2MAeQwRKeMJzArv9ctJcHsSU
KpRCrkLVTCDIBjYc9ycIUO6d5YxVNvzUK0iUCHT4b74UtczkxiQIH57kPhDhXG1f
zMW0r3UCAhlvt88QaHqw9CjzhAtZtP4rrMct/sjMrRife46B1o95ETZGpqF8pMtB
p7ma2djAVMQ=
=XuiU
-----END PGP SIGNATURE-----

Re: [Lapackpp-devel] Error in LaGenMatDouble::copy(...) and other questions

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dominik Wagenfuehr schrieb:
>> That's a serious error. I have spent a lot of checking on the
>> LaGenMatDouble methods, including the ::copy() method. If you can
>> extrace the relevant code portion than that would be really helpful.
> 
> Ok, the program crashed at LaGenMatDouble but the error is in sybfd.h in
> the factorize-function I have called earlier. I have fixed it and will
> send you a new file with documentation later (see at the end).

Thanks. Looking forward to this.

>> Again, this isn't "my fault" :-) because this code has been untouched
>> from the original lapackpp authors
> 
> I have never said that. ;) I took a look at the old lapack++ classes from 96
> and it's almost unbelievable that there are errors inside these functions
> for more than 10 years.

I totally agree.

>> and it turns out this function is already
>> available as Blas_R1_Update(),
> 
> Found it, thanks. :) The bad with these old lapack++ code
> is that these parts you have never touched are not documented and
> if you don't know the correct phrase or Fortran-Name you
> probably will never found it. :(

Yes. When I'm looking for something I'd usually start with the LAPACK
documentation at http://www.netlib.org/lapack/lug/lapack_lug.html , and
if there is a LAPACK routine, then I'd grep over the full lapackpp
source code to see whether it is being used anywhere.

> Maybe I will have documented the two most important files
> sybmd.h and sybfd.h tomorrow.
> 
> Another question concerning the changed. How far can I change it?
> I think the LaSymmBandFactDouble is ... hm, to be honest, useless.
> The functions inside can be used with the simple
> LaSymmBandMatDouble. But however it works.. I think this is the
> important part. ;)

I agree that several of the FactDouble classes are indeed relatively
useless. I have added the class LaGenQRFactComplex
http://lapackpp.sourceforge.net/html/classLaGenQRFactComplex.html and I
consider it useful. It isn't anything more than a wrapper around the
matrix A and vector Tau that make up the complex-valued QR decomposition
in LAPACK, but it additionally encapsulates the two other interesting
functions that would need these A and Tau as input.

In other words, if the existing factorization class is useless, just go
ahead and throw it out and/or replace it by your own class if you came
up with a design that is more useful.

Regards,

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRVyEqmXAi+BfhivFAQLK2QQAs+FliK2pcO165m999IBWlAYShx4eIs1E
SHFfA9er1iCW62AU1cz9GPXXoqdFhdTgmS2mnCjamty8orxZr8ujBtC9Z1n7/Wt/
m+jClS8UPyycZtku8jmktQCc51OS8gqPXEyQ+iQk2MSNEi7oJaeOxWZGrMEmg1Ju
T+q1uXsjSAE=
=jle0
-----END PGP SIGNATURE-----

Re: [Lapackpp-devel] Mailing list archive gives Internal Error 500

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dominik Wagenfuehr schrieb:
> PS: Your archive
> http://sourceforge.net/mailarchive/forum.php?forum=lapackpp-devel seems
> to be down sometimes. I only get Internal Error 500... I hope the
> subscription will work.

This is a known sourceforge bug:
https://sourceforge.net/tracker/index.php?func=detail&aid=1588125&group_id=1&atid=200001

The suggested "workaround" (urgh): Try the same URL again but without
being logged into sourceforge (i.e. try it in a different browser).
Indeed the same URL will work in that case, except that the archive
seems to have stopped working in mid-October, which is yet another known
sourceforge bug. That sucks.

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRVxrZ2XAi+BfhivFAQLcdQP9HzXx5uxVtSRcW1NLm/0qGkxBHoqVTZWp
e0JatfNrLGBo5R9RwJ6IEK3VKC1EqjasTYiQD/DnPsv70Fg/irnqU82Tpoa6MrB+
yRtaRGBvjORWEaWUig/Vs3h/ojY5Ptyw2LFhA6YUk1oOLnNvFYVIcWuWG+igFE+Y
5ZmvStG0nxw=
=kzi9
-----END PGP SIGNATURE-----

Re: [Lapackpp-devel] Error in LaGenMatDouble::copy(...) and other questions

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dominik Wagenfuehr schrieb:
> 1. I havent' found the exact error yet, but if I debug my program I will
> get a segmentation fault in
> 
> LaGenMatDouble B(A);
> 
> or
> 
> LaGenMatDouble B;
> B.copy(A);
> 
> A is a (4 x 2)-matrix with some values I have calculated before.
> Unfortunately I cannot debug the lapack-libary so I don't know where the
> error could be. I try to extract the relevant code parts from my program
> to reconstruct it.

That's a serious error. I have spent a lot of checking on the
LaGenMatDouble methods, including the ::copy() method. If you can
extrace the relevant code portion than that would be really helpful.

> 2. Is it possible that you forgot to create the copy-function for
> LaSymmBandMatDouble? I only get
> 
> /usr/local/include/lapackpp/sybmd.h:51: warning: inline function
> 'LaSymmBandMatDouble& LaSymmBandMatDouble::copy(const
> LaSymmBandMatDouble&)' used but never defined
> 
> I have created my own copy-function yet but as I see you have used some
> templates for this. I don't understand much about templates but it would
> be great if you can fix it.

In fact the copy() method is declared "inline" but its definition is in
matrix/src/sybmd.cc, so it is not at all inline. You can fix this
yourself by removing the "inline" keyword in front of copy() in sybmd.h.
 Again, this isn't "my fault" :-) because this code has been untouched
from the original lapackpp authors, see the version history of sybmd.h
at
http://lapackpp.cvs.sourceforge.net/lapackpp/lapackpp/include/sybmd.h?view=log
- - I only started to work on that file after you asked for these issues
yesterday.

> 3. Is there such a simple thing like A := A + alpha*B ? I have only
> found Blas_Mat_Mat_Mult and actually I perform
> 
> Blas_Mat_Mat_Mult(B, I, A, alpha);
> 
> where I as the Identity Matrix. Especially for LaSymmBandMatDouble you
> could save a lot lot lot of time if there would be such a simple
> operation for different types of matrices. I don't know if there exists
> a BLAS-function for it (I haven't found it yet), 

The point with these "simple arithmetics" for the matrices is that
surprisingly few of these are actually available as BLAS functions.
Especially the direct addition of two matrices (with or without scalar
factor) is *not* available in BLAS or LAPACK, see
http://www.netlib.org/blas/blasqr.pdf or
http://www.netlib.org/blas/faq.html or
http://www.cs.colorado.edu/~jessup/lapack/aboutBlas.html

I don't know the reasons for this decision. I'm an engineer, not a
numerical mathematician. I can only *guess* that the plain addition of
matrices for whatever reason is never being computed explicitly in "real
numerics".

The goal of lapackpp, on the other hand, is to be a C++ interface to
BLAS and LAPACK. So if you're asking for functionality that isn't
available in there, then I'm hesitating to put it into lapackpp. Rather,
I'd like to ask you to implement this yourself - I just guess the
LAPACK/BLAS people do have their reasons for deciding what to implement
and what not to implement, and since they are more intelligent than me,
I'd rather stick to their decision. Sorry.

> 4. Same with the operation A = B^T * B. There seems to be no
> BLAS-function for it even if you know that A is symmetric. You could
> save half of the time. And further if you know that B has a special
> structure and A will be banded symmetric...

This function is surely available in BLAS (I've looked this up on the
Quick Reference Guide). It is called DSYRK there (see "man dsyrk" if you
have lapack-manpages installed). The correct place for the C++ function
declaration is include/blas3pp.h and the implementation (=definition) in
blaspp/src/blas3pp.cc, and it turns out this function is already
available as Blas_R1_Update(), search for LaSymmMatDouble and set
alpha=1, beta=0. I have no idea why that name was chosen - maybe I
should add a better function name like Blas_RK_Update().

For the reference, if you discover more such functions that *are*
available in BLAS but not yet in LAPACKPP, here's what we would need to do:

1. Find the BLAS function name (say, dsyrk in level-3-blas)

2. Check whether a declaration of that function name exists in
include/blas3.h (no C++ here, only plain C) - if it doesn't exist, add
the declaration by copy&paste a similar declaration and suitable
reordering of the arguments.

3. Invent a C++ function name (say, Blas_RK_Update) and add a suitable
declaration for that function into include/blas3pp.h.

4. Add the implementation for the C++ function to blaspp/src/blas3pp.cc;
follow the existing checks and argument conversions from the other
existing wrapper functions.

5. (slightly optional) Add some testing code into blaspp/test/tblas++.cc
that will make the tblas++.cc program fail if your new function doesn't
work as expected. This ensures that "make check" will always check your
newly added function.

> PS: I have tested the functions in sybmd.h and sybfd.h and they seem to
> work fine. (Ignoring the little copy-incident above!) I will try to
> comment the functions...

Good. Again I'd invite you to submit any code changes that you consider
an improvements. That is great. Thanks a lot.

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRVxnvGXAi+BfhivFAQJstAP/f9Vf6T/XwqyypyOkP5SgELWpB1YmC0Yd
Fdl672DGaWVExRowrmfWzaXIhED1vXPyU+4rd1tfF28dmAiHa0+1w5SDZVwNIQmm
WrI5lTNRZIwpDfncp0C3sVoDxXWAWhBLlVmwcmSytTxE/b1tf43daOKfAqPNFbDE
q+sMQbhPYO4=
=KT/y
-----END PGP SIGNATURE-----

[Lapackpp-devel] Error in LaGenMatDouble::copy(...) and other questions

[Dominik W. <dom...@ar...>]

1. I havent' found the exact error yet, but if I debug my program I will
get a segmentation fault in

LaGenMatDouble B(A);

or

LaGenMatDouble B;
B.copy(A);

A is a (4 x 2)-matrix with some values I have calculated before.
Unfortunately I cannot debug the lapack-libary so I don't know where the
error could be. I try to extract the relevant code parts from my program
to reconstruct it.

2. Is it possible that you forgot to create the copy-function for
LaSymmBandMatDouble? I only get

/usr/local/include/lapackpp/sybmd.h:51: warning: inline function
'LaSymmBandMatDouble& LaSymmBandMatDouble::copy(const
LaSymmBandMatDouble&)' used but never defined

I have created my own copy-function yet but as I see you have used some
templates for this. I don't understand much about templates but it would
be great if you can fix it.

3. Is there such a simple thing like A := A + alpha*B ? I have only
found Blas_Mat_Mat_Mult and actually I perform

Blas_Mat_Mat_Mult(B, I, A, alpha);

where I as the Identity Matrix. Especially for LaSymmBandMatDouble you
could save a lot lot lot of time if there would be such a simple
operation for different types of matrices. I don't know if there exists
a BLAS-function for it (I haven't found it yet), but I have named my
function

void Blas_Mat_Mat_Add(LaSymmBandMatDouble& A, const LaSymmBandMatDouble&
B, const double& alpha = 1.0)
{
  assert(A.size(0) == B.size(0));
  assert(A.size(1) == B.size(1));

  int n=A.size(0), p=A.subdiags(), n2;
  int i,j;
 
  for (i=0; i<n; i++)
  {
    n2 = (i+p+1 < n) ? i+p+1 : n;
    for (j=0, j<n2; j++)
    {
      A(i,j)+=alpha*B(i,j);
    }
  }
}

4. Same with the operation A = B^T * B. There seems to be no
BLAS-function for it even if you know that A is symmetric. You could
save half of the time. And further if you know that B has a special
structure and A will be banded symmetric...

Greetings, Dominik

PS: I have tested the functions in sybmd.h and sybfd.h and they seem to
work fine. (Ignoring the little copy-incident above!) I will try to
comment the functions...

Re: [Lapackpp-devel] LAPACKPP

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Reza Seyedshohadaie schrieb:
> Dear Sir,
> 
> I am a graduate student using the LAPACK library in my research that
> requires calculating eigenvalues for a very big matrix. I am trying to use
> LaEigSolve function that takes LaVectorComplex as an argument. After
> compiling my code I get the following error:
> 
> 1>c:\program files\lapackpp\include\lapackpp\gmc.h(47) : fatal error
> C1189: #error :  "The macro LA_COMPLEX_SUPPORT needs to be defined if you
> want to use complex-valued matrices."
> 
> Could you please let me know how can I avoid this error?

Define the macro LA_COMPLEX_SUPPORT if you want to use complex-valued
matrices.

Christian

> 
> I would appriciate your response.
> 
> Regards,
> Reza
> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRVw0FGXAi+BfhivFAQJaXwP/fOobei/26z7onXHEe/AvW+NfctBEpz2j
NAkDjGwAxVIxteTnngF64qgcdpCN0xwZfBKUsSLd7spRXgNKjj0XJnbCr0sFQIpw
vzmrJF3G8Skb1kvsVpfpeOHSc6I4KdggQX83eDMaM+a9zcC4VZdVcagqsJbJePKQ
D89dCMyxPX4=
=/r51
-----END PGP SIGNATURE-----

Re: [Lapackpp-devel] Memory assignment in LaSymmMatDouble

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dominik Wagenfuehr schrieb:
> Hello Christan,
> 
> Christian Stimming schrieb:
>> This approach was chosen by the original authors of the
>> lapackpp-1.x code and this code has never been touched or improved by
>> myself. [...]
>> If you want to use that part of lapackpp and you think the class should
>> be changed, then feel free to propose a code change.
> 
> Yes, I probably will do. It will take a time but I think it would help most
> of the programmers if the header file is documented better. In many cases
> I have to look into the cc-files to see what the function actually does.

Look into the header files of the general/dense matrices, include/gmd.h
and others. The function names are pretty much the same as in symd.h, so
that should give you an idea about what these functions are supposed to
do, and most of the comments can directly copied into e.g. symd.h as well.

I didn't add any documentation there because I wanted to document only
those parts that I  1. understand, 2. tested, and 3. really know they do
the right thing. symd.h doesn't meet those criteria, so I didn't bother
to add any (potentially wrong) documentation.

> If I'm finished I will report later...

Sure. If you are interested, you could also get direct developer CVS
access for lapackpp. (Sourceforge username needed.)

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRVrXtmXAi+BfhivFAQIIHgP+JmmqGo1RiA3IiSIfBj9cxwi8YSjAnLj6
uCS36yad/Fwo6RUlBtF7iKo5S37LahI5pF05KB1dwMeZF6FMFhtAK79qZD9NXEyl
HALvr76pobre9ACupWBUC37jkosnfd5ShhOC99ei5+VlPy4wqHeOt8ny2kb+1bHN
UfIZ0Gn+RE0=
=bDD7
-----END PGP SIGNATURE-----

Re: [Lapackpp-devel] Memory assignment in LaSymmMatDouble

[Dominik W. <dom...@ar...>]

Hello Christan,

Christian Stimming schrieb:
> This approach was chosen by the original authors of the
> lapackpp-1.x code and this code has never been touched or improved by
> myself. [...]
> If you want to use that part of lapackpp and you think the class should
> be changed, then feel free to propose a code change.

Yes, I probably will do. It will take a time but I think it would help most
of the programmers if the header file is documented better. In many cases
I have to look into the cc-files to see what the function actually does.

If I'm finished I will report later...

Greetings, Dominik

Re: [Lapackpp-devel] Memory assignment in LaSymmMatDouble

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear Dominik,

Dominik Wagenfuehr schrieb:
> assigning a matrix per LaGenMatDouble or LaSymmMatDouble does not have
> any effect to memory savings because the constructor of the symmetric
> matrix will only call the standard constructor of a general matrix. Why
> do you choose this approach? You can save some (or better half of the)
> memory you use yet.

yes, that's true, the LaSymmMatDouble doesn't store its matrix content
any different than LaGenMatDouble (although it accesses only half of the
memory). This approach was chosen by the original authors of the
lapackpp-1.x code and this code has never been touched or improved by
myself. You can see that by the fact that there is almost zero
documentation comments in the header file. I've only worked on those
classes where you have a lot of comments in the header file. So if you
think those other classes are badly designed or even contain errors,
then the blame goes on the original authors.

If you want to use that part of lapackpp and you think the class should
be changed, then feel free to propose a code change. Simply submit a
patch here, ideally together with a test case that demonstrates that
your code delivers correct calculations. In terms of the storage
decision, IMHO the matrix should be stored in the same way as the
Fortran-LAPACK expects it. I'm not an expert for sparse or symmetric
matrices in LAPACK (only for dense ones), so I rather don't touch this
part of the code. But if you have any suggestion, feel free to go ahead
with this.

> PS: Your archive
> http://sourceforge.net/mailarchive/forum.php?forum=lapackpp-devel seems
> to be down sometimes. I only get Internal Error 500... I hope the
> subscription will work.

The subscription obviously worked. I know that the link to the archive
on sourceforge is broken and I have no idea why they don't fix it. :-(

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRVnjUWXAi+BfhivFAQKd2QP/dbq9q4uHRn+Frd7rOOpEK1Md3281cKIh
MuanfyVWa8h4v4EzyeOzCS1IWcnHHxc4bJlQasagyDPILqAT79VTjTENQvsAJpaa
c2LmW5EHw1l6+xhYKBp1/3keIXFGhNukpWCUu+W7ArdJUx7QPjQ5YIDng3M+L6qP
/DCmoa8Zu0Y=
=o3Uk
-----END PGP SIGNATURE-----

[Lapackpp-devel] Memory assignment in LaSymmMatDouble

[Dominik W. <dom...@ar...>]

Hello,

assigning a matrix per LaGenMatDouble or LaSymmMatDouble does not have
any effect to memory savings because the constructor of the symmetric
matrix will only call the standard constructor of a general matrix. Why
do you choose this approach? You can save some (or better half of the)
memory you use yet.

Best wishes,
Dominik

PS: Your archive
http://sourceforge.net/mailarchive/forum.php?forum=lapackpp-devel seems
to be down sometimes. I only get Internal Error 500... I hope the
subscription will work.

Re: [Lapackpp-devel] 364 VlAlGRA

[Seth W. <qu...@br...>]

customers. They are the ones that we are interested in. I took out


Cheap VlAlGRA http://www.casdetundelionkas.com

=20
=20
launched into this overamplified and very catchy-if not itchy-number.

Re: [Lapackpp-devel] VdIAGRA

[Aubree T. <ch...@aa...>]

Hi,

VdIAGRA for LESS http://www.oertionpidsadjinde.com

=20
I was barely aware of this because the instant Iron Johns attention
behind us and the music trickled to an end.

Re: [Lapackpp-devel] VkAGRA

[Elysia M. <cad...@gi...>]

Hi,

VkAGRA for LESS http://www.oservehis.com

=20
You didnt see it. It was over before you turned to look. He was
out there is grateful. He turned and smiled broadly at me. A smile

Re: [Lapackpp-devel] Hi

[Th Q. <ha...@de...>]

Hi,

AMBhlEN

VALhlUM

ClAhLIS

VlAhGRA

Save 60 % with http://www.trluzoetro.info
=20
  _____ =20


sealed in an armored case that would take a diamond drill to open. I
appointed now. Plans drawn up to free the women and children from
wine being poured and my brain was dull and empty. You never told me

[Lapackpp-devel] Fwd: Re: Compiling Lapackpp on mac os x

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

For the archives.

----------  Weitergeleitete Nachricht  ----------

Subject: Re: Compiling Lapackpp on mac os x
Date: Samstag, 23. September 2006 10:59
From: "Fabio F." <fab...@gm...>
To: Christian Stimming <sti...@tu...>

Hi,
I finally managed to compile lapackpp 2.4.13 on Apple Darwin 8.7.0,
since it's been a lot of trouble to me I thought I'd post how I've
done it hoping it will be useful to others.

First you need to install g77 and gcc-4 from fink (gcc4 from apple
didn't work)


set FLIBS="-L/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.0.2/ -L/sw/
lib -lm -lfrtbegin -lSystemStubs -lSystem -lmx /sw/lib/gcc4/lib/gcc/
powerpc-apple-darwin8/4.0.2/libgcc.a"

and run the configure script in the following way
./configure --with-blas='-framework vecLib' --with-lapack="-framework
vecLib" CC=/sw/bin/gcc-4

after that you can run make and make install

To use lapackpp on Xcode you will need to disable the "Allow
Zerolink" option (if enabled) under the build menu
then set "Other C++ flags" and "Other Linker flags" to have value "-L/
usr/local/lib -llapackpp". Last thing set the "Header search path" to
value "/usr/local/include/lapackpp/"

and you are all set.

let me know if you want the binaries.

Thanks again for your time,

Fabio Franconeri.

On Sep 18, 2006, at 1:42 PM, Christian Stimming wrote:
> Hi,
>
> no, unfortunatly I have no idea how to help here. I would guess you
> should experiment with the ordering of the linker flags. Like,
> removing
> - -lg2c completely or putting it to the front or the end of the linker
> command in question, or trying to switch the linking order of the
> veclib
> and g2c libraries (since those two are colliding here).
>
> Christian
>
> Fabio Franconeri schrieb:
>> Hi,
>> I'm a member of the VCG developing team on sourceforge
>> I'm really sorry to bother you with this but I can't really seem
>> to find
>> any help on this topic on the web.
>> I'm trying to compile Lapackpp on my apple Darwin woth G4 processor
>> I set  FLIBS="-L/sw/lib -lfrtbegin -lg2c -lSystem"  as adviced and
>> also
>> set LDFLAGS to point to Accelerate and VecLib frameworks
>> but the compiling process stops at some point with this error:
>>
>> --------------------------
>> ld: warning multiple definitions of symbol _second_
>> .libs/liblapackpp.lax/libg2c.a/Lsecond.o private external
>> definition of
>> _second_ in section (__TEXT,__text)
>> /System/Library/Frameworks/Accelerate.framework/Versions/A/
>> Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib(single
>> module) definition of _second_
>> ld: Undefined symbols:
>> _G77_date_y2kbuggy_0
>> _G77_vxtidate_y2kbuggy_0
>> /usr/bin/libtool: internal link edit command failed
>> make[2]: *** [liblapackpp.la] Error 1
>> make[1]: *** [all-recursive] Error 1
>> make: *** [all] Error 2
>> ---------------------------

Re: [Lapackpp-devel] Lapackpp problem

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

no, unfortunatly I have no idea how to help here. I would guess you
should experiment with the ordering of the linker flags. Like, removing
- -lg2c completely or putting it to the front or the end of the linker
command in question, or trying to switch the linking order of the veclib
and g2c libraries (since those two are colliding here).

Christian

Fabio Franconeri schrieb:
> Hi,
> I'm a member of the VCG developing team on sourceforge
> I'm really sorry to bother you with this but I can't really seem to find
> any help on this topic on the web.
> I'm trying to compile Lapackpp on my apple Darwin woth G4 processor
> I set  FLIBS="-L/sw/lib -lfrtbegin -lg2c -lSystem"  as adviced and also
> set LDFLAGS to point to Accelerate and VecLib frameworks
> but the compiling process stops at some point with this error:
> 
> --------------------------
> ld: warning multiple definitions of symbol _second_
> .libs/liblapackpp.lax/libg2c.a/Lsecond.o private external definition of
> _second_ in section (__TEXT,__text)
> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib(single
> module) definition of _second_
> ld: Undefined symbols:
> _G77_date_y2kbuggy_0
> _G77_vxtidate_y2kbuggy_0
> /usr/bin/libtool: internal link edit command failed
> make[2]: *** [liblapackpp.la] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
> ---------------------------
> 
> can you give me some hints on this or point me to someone who can help??
> 
> Thanks a lot for your time
> 
> Fabio Franconeri
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRQ6GDWXAi+BfhivFAQL1pwP/c/mdq03B/MEH4GLtg72uRWMu1YFHrb3b
qHcBV/vTEApbP29tZHQGLYE1NyZOHVbaMnErwTTzxiER5XTKRtYgkA6TFLYsLNHp
aMEelcdK1vcGsM0jS+x4IvbSneqCzogpq+ZRyFPgHBp2vTT9MDeOFMApSXT9SLJ0
o23D+R1gfj4=
=iPY1
-----END PGP SIGNATURE-----

Re: [Lapackpp-devel] PHnfARMA

[Guto D. <sl...@di...>]

Hi
=20
All yo f ur P j HARM n AC r Y dir b ectl d y from the m x anuf k actu p
rer,
Your ch a anc z e to eco d nomiz a e wit z h us
http://hujadetrunkadesin.com

Re: [Lapackpp-devel] cyRXie

[Channah K. <wal...@in...>]

Hi,
Goo l d news for you.
=20
PHA y RMA q CY d u ire n ctly from the m z anufa i ctu p rer,
Ec c onom w ize u d p to 60 l % w r ith us http://heranrtionketer.com

, x=20

, p=20

, i=20

Itchy foot, itchy foot, itchy foot itch!
Keeping me going from place to place
Gotta keep going, what can I do?

Re: [Lapackpp-devel] Some problems when Compiling lapackpp-2.4 .13 codes with MSVC++ 6.0

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

yzj_0928 schrieb:
>    Stimming,I have downloaded your codes about lapackpp-2.4.13.I have
> encountered some problems when Compiling those codes with MSVC++ 6.0.

lapackpp-2.4.13 is tested only with MSVC 7.1 (Microsoft Visual Studio
.NET). It probably doesn't work with the older MSVC 6.0. One of the
older lapackpp versions used to work fine with MSVC 6.0, though, so you
should consider going back version by version of lapackpp to see which
one works fine. (The libblas32.lib et al are unchanged for all
lapackpp-2.4.x versions, so you don't need to install any different
versions there.)

>    If it has been compiled succfully ,how to use it ? In the same
> workspace ,are the other projects such as tgd or tgc files the test
> programs ? 

Yes.

> MSVC++ 6.0 seems can't recoglize the .cc file .I renamed the
> tgd.cc to tgd.cpp ,then compiled the project.

That's a problem with MSVC 6.0. Newer MSVC will accept them without any
problem.

> If copy the lapackpp.dll to the project directory and append in the
> linker >input options ,it has only 1 errors,
>  
> --------------------Configuration: 1 - Win32 Debug--------------------
> Linking...
> lapackpp.dll : fatal error LNK1136: invalid or corrupt file
> Error executing link.exe.
> 1.exe - 1 error(s), 0 warning(s)
> ----------------------------------------------------------------------
>  
>   So,summarizing above information ,I have several questions,
> 1.Is the compiling process I have done,correctly?

Yes, except that you have to copy both lapackpp.dll *and* lapackpp.lib
into your project directory. In the Linker->Input option, you insert the
filename "lapackpp.lib", but when starting your compiled program, it
will need the lapackpp.dll.

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRPKeuWXAi+BfhivFAQKRdgP/ZOA02S03+GXwIPRpc+NIwfW7tK6cTsYd
WwBv87KtbMUsPpFY0sWOKw0xyH4Nu50RnLBODps7dsbOQWBHI9RTXIAq/cczNOPx
YLVeko5BKvt1bHd15klXgKShwTlazFuPcA8ajYXVxNKGq5vOZhmtP5df4KiYsQYb
v6AHoRCvKTQ=
=zKxG
-----END PGP SIGNATURE-----

[Lapackpp-devel] Testing works fine

[Aosheng R. <ro...@gm...>]

Hi Christian,

I compile lapackpp using VC++.NET 2005. and link VC++ libaray of
lapackpp into my applications. It works. The results are almost the
same as those obtained under Linux.

Thank you very much for great job.

Regards,
-----------
Aosheng

Re: [Lapackpp-devel] MSVC and complex matrices very well available

[Aosheng R. <ro...@gm...>]

Christian,

Fantastic!

Thank you for your great job.

I will CVS your update package and do some tests.

Many, many thanks to you!

Regards,

Aosheng

On 8/21/06, Christian Stimming <sti...@tu...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Aosheng,
>
> now that I'm back at my windows machine, out of curiosity I gave MSVC
> and LA_COMPLEX_SUPPORT a try. To my surprise this works right away; no
> problem with include/lacomplex and MSVC at all. I've now updated the CVS
> code so that the MSVC project file will immediately compile the full
> lapackpp including complex-valued matrices.
>
> Have fun,
>
> Christian
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.1 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iQCVAwUBROlu4mXAi+BfhivFAQJ8igQAt55bRtRJiSrMkVky10LnFa2e/a21gMfY
> wgwUAwTAXUCl3vR8Qm3mC3xhADDdWEw23sb4vifrhIeIU3b7xZ6dPfa9h+lXfQrx
> uTbh6rM6Yf60fpzktdNwWgrk6DKhAmtd/2FC/tz8q+v8jZpsVIRh/QwGQbJolFig
> DJrTZl0a46M=
> =LC8S
> -----END PGP SIGNATURE-----
>

[Lapackpp-devel] MSVC and complex matrices very well available

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Aosheng,

now that I'm back at my windows machine, out of curiosity I gave MSVC
and LA_COMPLEX_SUPPORT a try. To my surprise this works right away; no
problem with include/lacomplex and MSVC at all. I've now updated the CVS
code so that the MSVC project file will immediately compile the full
lapackpp including complex-valued matrices.

Have fun,

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBROlu4mXAi+BfhivFAQJ8igQAt55bRtRJiSrMkVky10LnFa2e/a21gMfY
wgwUAwTAXUCl3vR8Qm3mC3xhADDdWEw23sb4vifrhIeIU3b7xZ6dPfa9h+lXfQrx
uTbh6rM6Yf60fpzktdNwWgrk6DKhAmtd/2FC/tz8q+v8jZpsVIRh/QwGQbJolFig
DJrTZl0a46M=
=LC8S
-----END PGP SIGNATURE-----

Re: [Lapackpp-devel] Compiling errors of tCmplxSolve.cc with updated lapackpp 2.4.12

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

Am Sonntag, 20. August 2006 20:31 schrieb Aosheng Rong:
> From headfile lacomplex,  I noticed that you indeed define
> complex<double> for gcc only, but not check the definition for msvc.
>
> I would try to make the modification, after I carefully check
> lacomplex, complex on MSVC and complex on GNU C++ . If you have any
> good suggestions, just let me know. I need to figure out the
> architecture of lapackpp.

First, look into the file include/lacomplex.h and read all the comments from 
top to bottom. As you can see, Fortran needs the COMPLEX type, but that one 
is too difficult to use from C++. C++ instead uses the class from the 
compiler's #include <complex> header file for the std::complex class. The 
only missing part is a class that has automatic conversions from COMPLEX and 
std::complex and vice versa. This is achieved for gcc by copying the normal 
compiler's <complex> header file content into the include/lacomplex header 
file. Look into the file; you will see it's copied from gcc's system library. 
You need to do the same for MSVC's <complex> header file. Look into 
include/lacomplex file, you will see it says "(Almost) All changes by 
Christian are marked with "CS:"". So search for the string "CS:" and you will 
see which parts have been added by myself. Everything else has been taken 
unchanged from the <complex> system header, and you need to do just the same 
for MSVC.

Christian

PS: It is allowed to redistribute the copied gcc code with lapackpp because it 
is LGPL licenced. On the contrary it is probably not allowed to redistributed 
copied code from MSVC because that one is not freely licensed at all.

>
> Regards,
> -------------
> Rong
>
> On 8/20/06, Christian Stimming <sti...@tu...> wrote:
> > Am Samstag, 19. August 2006 13:35 schrieb Aosheng Rong:
> > > Can you add complex-value matrix support  on Windows?  The
> > > complex-value matrices are of essential to my applications. Lapackpp
> > > supports the complex-value matrices  very well on Linux.
> >
> > Lapackpp supports complex-valued matrices on Windows as well, only with
> > the gcc compiler and not (yet) with the MSVC compiler. (And C++, in
> > contrast to C, is not compiler-independent.) I only need those matrices
> > with the gcc compiler, so I have no motivation for myself to spend this
> > extra effort.

Re: [Lapackpp-devel] Compiling errors of tCmplxSolve.cc with updated lapackpp 2.4.12

[Aosheng R. <ro...@gm...>]

Christian,

>From headfile lacomplex,  I noticed that you indeed define
complex<double> for gcc only, but not check the definition for msvc.

I would try to make the modification, after I carefully check
lacomplex, complex on MSVC and complex on GNU C++ . If you have any
good suggestions, just let me know. I need to figure out the
architecture of lapackpp.

Regards,
-------------
Rong

On 8/20/06, Christian Stimming <sti...@tu...> wrote:
> Am Samstag, 19. August 2006 13:35 schrieb Aosheng Rong:
> > Can you add complex-value matrix support  on Windows?  The
> > complex-value matrices are of essential to my applications. Lapackpp
> > supports the complex-value matrices  very well on Linux.
>
> Lapackpp supports complex-valued matrices on Windows as well, only with the
> gcc compiler and not (yet) with the MSVC compiler. (And C++, in contrast to
> C, is not compiler-independent.) I only need those matrices with the gcc
> compiler, so I have no motivation for myself to spend this extra effort.
>
> You are invited to implement this yourself. In fact, why haven't you tried
> what I said? Add the macro LA_COMPLEX_SUPPORT to the MSVC project properties
> (C++ -> precompiler), and maybe add a few source files that haven't been
> added to the MSVC project because they only contain complex-matrix related
> code. matrix/src/gmc.cc, vc.cc and lavc.cc would be some that come to my
> mind.
>
> The only real problem that could occur is the definition of the
> la::complex<double> (typedef'd as LaComplex) in include/complex. The template
> complex<...> class definition in that file was initially copied from gcc's
> definition of complex<...>. Someone who wants to add complex support to MSVC
> would have to check whether these definitions can be used in MSVC as well,
> and potentially add some
> #ifdef __GNUC__
>  // existing code for gcc
> #else
>  // new code for MSVC instead
> #endif
> everywhere.
>
> Good luck.
>
> Christian
>
>
> >
> > Thanks,
> > ----------
> >
> > On 8/19/06, Christian Stimming <sti...@tu...> wrote:
> > > Seems to me you didn't compile the library lapackpp itself with the macro
> > > LA_COMPLEX_SUPPORT defined. In the included vcproj file this is not (yet)
> > > defined because, as I already said several times, the support for
> > > complex-valued matrices in MSVC is untested so far.
> > >
> > > Christian
>

Re: [Lapackpp-devel] Compiling errors of tCmplxSolve.cc with updated lapackpp 2.4.12

[Aosheng R. <ro...@gm...>]

Christian,

Following your hints, I added LA_COMPLEX_SUPPORT to precompiler of
project in MSVC and added gmc.cc, vc.cc and lavc.cc into source files.
Unfortunately, it dosn't work. I cannot generate the dynamic library,
when LA_COMPLEX_SUPPORT is added. I am not sure if we should modify
lacomplex.h?  Right now, I have no ideas about the modification of
lacomplex.h, because I have no knowledge about the difference of
complex type definition between MSVC and GNU C++.

Thanks,
-------------
Rong