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

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

Dear Jack,

Jacob (Jack) Gryn schrieb:
>> This is the key word here: "calling a virtual" function/method. 
> 
> 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?  

Inlining and virtual functions are mutually exclusive. Either you get 
one or you get the other -- it's a contradiction to have both. Inlining 
means that *at compile time* it is known which function is going to be 
called, thus the compiler replaces the function call by the inlined 
code. A virtual function, however, means that the actual function to be 
called is determined *at run time*: The compiler only sees that there is 
a pointer to the base class, but the compiler doesn't know which derived 
class that pointer actually points to, so it doesn't know which virtual 
function (i.e. function of the derived class) will actually be executed. 
This can only be determined at runtime, by the mentioned "vtable lookup".

>> COMPLEX should not be made into a class 
> 
> 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.

By the way there already is a operator<< for COMPLEX in lacomplex.h -- 
did you look for something else?

>> 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.? 

For now I would prefer to only have operator*= and similar, where it is 
totally clear that the operations work on specific matrices.

> 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?  

In theory, global variables are bad and should be avoided. In practice, 
we already have some, like the LaException::_print static variable. 
Maybe there could be a similar static variable in some class? But it's a 
bit unclear where... la::complex, LaGenMatComplex, LaException... I'm 
unsure. The output function that is used is the one in <lacomplex> line 
480, so such a flag should probably be put into la::complex.

> 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.  

Transpose: Are you really sure that you need to calculate the 
transpose/hermitian explicitly? I found that everytime when I thought I 
need to that, eventually I saw that I only needed to choose the correct 
Blas_Mat_xy function (blas2++.h, blas3++.h) which uses the matrix either 
normal or transposed. Calculating the transpose explicitly usually 
should not be necessary at all. For which operations would you need that?

Inverse: Run a LaLinearSolve(A, Ainv, eye) where A is the input, Ainv is 
the output, and eye is an identity matrix. There you are. Again, you 
should rethink whether you really need to calculate the inverse -- or 
whether you rather need to solve a system of linear equation. In 90% of 
the cases, talking about the inverse means the latter, and directly 
solving that system (instead of calculating the inverse and then 
multiplying with the inverse) is way more efficient.

Gee, maybe I should start adding my explanations directly into the 
documentation :-))) I like these discussions.

Christian