RE: [Lapackpp-devel] RE: Lapack++ column ordering, derivations, exceptions, lwork size

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

>  This is the key word here: "calling a virtual" function/method. Calling a
virtual function is a *considerable* overhead in C++, because 
> there is an additional lookup for the right virtual function in the
object's vtable. This overhead is comparable to things like a bounds 
> check on *every* access -- they are nice and negligible if you do some
simple things, but if you really want to crunch numbers, then you 
> rather try to get along without them. Since the operator() IMHO is in fact
a speed-critical method (as opposed to e.g. 
> the constructors), it should rather be avoided to switch this to a virtual
method (unless there is some really really strong argument for 
> doing it anyway).

I never thought about these vtable 'lookup' issues; I guess I haven't done
too much optimization of this nature.  Do compilers not cache these things?
I think operator() is already inline, but if its not, it probably should be;
is the overhead for these lookups still an issue with inline code?  

> COMPLEX should not be made into a class for a simple reason: The type
COMPLEX exists only to have *the* fortran-compatible complex number 
> type around. By definition we cannot change that type or make it into a
class -- it is fixed to be the thing that fortran expects it to be. 
> This is why there is this class LaComplex (or la::complex) -- these are my
try to provice a "nicer" C++ complex data type. But, as its 
> documentation says, these are only wrappers to make the COMPLEX handling
easier. At the interface to fortran, Lapack++ has and will have to 
> deal with this stupid simple COMPLEX.

I'm sure there are other simple workarounds for operator<< and COMPLEX.
Worst case scenario, you have a single operator<< function for all matrices,
except for complex.

> If you have any ideas about *adding* such operators so that a user can
optionally use them, then just go ahead. Yes, operator*= might be a 
> good idea.

Should I add things like operator*, operator+ with a warning in the
comments? Or just operator*=, etc.? 

> Thanks for your comments. Do you get progress with lapack++ in your
application? I hope so.

I'm getting some progress now that I've gotten the SVD and LinearSolve
working, thanks..

A few more questions..

A) I've modified the operator<< algorithm in gmd.cc (at least for personal
use) to output matricies in a fashion that can be easily pasted into MatLab.
Ultimately, I'd like to create some sort of a display flag to select
standard, matlab, or maple output.  Any thoughts about how this flag should
be implemented?  Shall I create a global variable somewhere?  

B) Are there any Lapack (or Lapackpp) functions for transpose or inverse?  I
know lapack takes transposed input; however, we've essentially forced data
to work in 'N'ormal mode with the wrappers.  Although a physical transpose
takes time, the fixing of this flag is reasonable, as it avoids the
complexity of dragging this 'N'/'T' flag around.  However, it should be
replaced with the ability to actually do a transpose.  

Jack

-----Original Message-----
From: Christian Stimming [mailto:sti...@tu...] 
Sent: August 11, 2004 4:53 PM
To: Jacob (Jack) Gryn
Cc: lap...@li...
Subject: Re: [Lapackpp-devel] RE: Lapack++ column ordering, derivations,
exceptions, lwork size

Am Mittwoch, 11. August 2004 22:32 schrieb Jacob \(Jack\) Gryn:
> Just to respond to some previous comments I haven't had a chance to 
> before..

sure

> > About a virtual base class: I guess you mean that there should be 
> > one common base class for the different element types.
>
> I think operator() could be done if the class hierarchy is setup properly.
> If in, for example, a matrix class, instead of using specific 
> VectorDouble, VectorComplex, etc..  There is one base Buffer class, 
> and there is one base Matrix class, the operator() would call the base 
> operator() that translates the 2D coordinates into 1D; it then does 
> the lookup by calling the virtual
> operator() in the Buffer class.

This is the key word here: "calling a virtual" function/method. Calling a
virtual function is a *considerable* overhead in C++, because there is an
additional lookup for the right virtual function in the object's vtable.
This overhead is comparable to things like a bounds check on *every* access
-- they are nice and negligible if you do some simple things, but if you
really want to crunch numbers, then you rather try to get along without
them. Since the operator() IMHO is in fact a speed-critical method (as
opposed to e.g. 
the constructors), it should rather be avoided to switch this to a virtual
method (unless there is some really really strong argument for doing it
anyway).

> Another example, may be operator<< .  All of them are identical, 
> except for COMPLEX; however, we still only need one operator<< if 
> COMPLEX is made into a class with its own OPERATOR<<.

COMPLEX should not be made into a class for a simple reason: The type
COMPLEX exists only to have *the* fortran-compatible complex number type
around. By definition we cannot change that type or make it into a class --
it is fixed to be the thing that fortran expects it to be. This is why there
is this class LaComplex (or la::complex) -- these are my try to provice a
"nicer" C++ complex data type. But, as its documentation says, these are
only wrappers to make the COMPLEX handling easier. At the interface to
fortran, Lapack++ has and will have to deal with this stupid simple COMPLEX.

> > Therefore I rather stick to the fortran structure and leave it up to 
> > the application programmer whether he runs DGESDD resp.  LaSVD on a 
> > matrix or on a temporary copy of it.
>
> I see your point.  Although, one may want the option of having the 
> simplicity of such operators, as long as their forewarned that such 
> 'intelligence' comes at an expense.  It should be noted that 
> operator*= can be done easily while overwriting the original matrix.

If you have any ideas about *adding* such operators so that a user can
optionally use them, then just go ahead. Yes, operator*= might be a good
idea.

Thanks for your comments. Do you get progress with lapack++ in your
application? I hope so.

Christian