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

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

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