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

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

The LaGenMatDouble class has an instance variable 'v' of type
LaVectorDouble.  I didn't notice inheritance in any of the vector or matrix
classes.

 

Although I realize that my ideas with inheritance are probably too much for
the time being and may need to wait for 3.0 (or whatever), I think the
following would be a good ideal and simplify the system significantly from a
developer standpoint (any changes to matrix or vector code would usually
only need to be made in one central place); I know I'm new to this project,
but here is my "Ideal" class structure for the project, let me know what you
think (even if it were only for the distant future).

 

'virtual' class Buffer - a virtual class of ANY kind of buffer, to be
inherited by DoubleBuffer, FloatBuffer, etc..

  this class will contain code common to all buffer formats.  Access and set
function calls will take up to 3 dimension parameters (x,y,z) for 3D data
(with y and z defaulting to 1 if unused); these calls should be inline and
code x,y,z into an index in the 1D buffer.  The constructor will set the
dimensions (which are type 'protected' to allow access to the inherited
classes)

 

'virtual' class LaGenMat (what does the 'Gen' stand for anyway?) - another
virtual class to be inherited by LaGenMatDouble, etc.   Functions common to
all matrix operations should be put in here and it should contain a pointer
to a 'Buffer' - since this class is useless by itself, the derived classes
will initialize this to whatever kind of buffer it needs.

 

`virtual' class Vector - a subclass of LaGenMat and derive VectorDouble,
etc. from that (alternatively, since most vector operations are matrix
operations, scrap this virtual class and just derive VectorDouble, etc..
directly from the specific Matrix classes)

 

Alternatively, templates could be used (like TNT), but few people truly
understand how compilers do things when it concerns templates, it would be
difficult to code.

 

Matrix classes should contain the SVD and Solve functions (keep the old
syntax for a few versions); i.e,

LaGenMatDouble A;

.

A.SVD(U,D,VT);

 

This last 'thought' may be more controversial, but why not incorporate some
of the blas3 functionality into the matrix classes?  Such as using operator*
to call Blas_Mat_Mat_Mult(), etc?

 

 

With respect to the COMPLEX definition, I agree that it should be taken out;
I find, at the moment, that if I try to compile anything (even just
something that only uses LaGenMatDouble's), it will not compile.

 

Meanwhile, I'll just work on finishing up the row-wise imports; I haven't
had time to get to them as I've been spending my time at work on other
algorithms.

 

Jack

 

-----Original Message-----



> Ideally, there should be better interoptability between the matrix/vector

> data types as there's a lot of duplicate code, and no inheritance.

> For example, it would probably be better to treat a vector as an n x 1

> matrix, inheriting all the properties of a matrix, except that if has a

> coordinate fixed at 1.  This is probably a longer-term thing (maybe for

> 3.0), but since the point is to use C++, why not take advantage of its

> features.  Then, code that, for example, re-orders a matrix upon loading,

> doesn't need to be written 6 times, for each data type.

 

The LaVectorDouble is a derived class of LaGenMatDouble, isn't it? And 

for LaVectorComplex / LaGenMatComplex as well? But the constructors 

cannot be derived, and, yes, there is some code duplication because of 

this. The re-ordering code should indeed not be rewritten more than 

necessary, and it is by definition only necessary in the matrix classes, 

not in the vector classes. Therefore I thought it is necessary exactly 

twice: In LaGenMatDouble for doubles and in LaGenMatComplex for COMPLEXs.

 

> Another thing I was wondering, why is it necessary to #define

> LA_COMPLEX_SUPPORT in files where no complex numbers are used?

 

This define-macro comes from the old v1.1 lapack++ where it was 

*disabled* everywhere. Maybe it should be dropped altogether, so that 

lapackpp will be built with complex support enabled always. If not, then 

this macro should be the switch to turn on or off the declarations of 

the complex data types. In that sense the #define should not be needed 

in files that do not use complex numbers.

 

 >>>I did some testing with the current developer CVS version..

 >>>I still get "Aborted" if the vector S is of an incorrect size.

 >

 >> Right. The code right now will only accept a vector S of the exactly

 >> correct size. Do you suggest to change this behaviour? I think this

 >> behaviour is ok.

 >

 > I think it's a good idea to check the vector size.  My issue is that

 > the word "Aborted" is kind of useless, when the

 > LaException::enablePrint(true)

 > flag is set.  Maybe I'm just picky.

 

The word "Aborted" comes from the fact that the library has thrown an 

exception but the application did not catch it. This is the default 

behaviour of C++ (more precisely: gcc) with uncaught exceptions, and we 

cannot do anything about it. Either the application is supposed to have 

a try-catch-block for LaException, or the user has to use a debugger 

anyway which will then show the origina of the exception in its backtrace.

 

 > I tool a look at the lwork value, according to the documentation at

 > http://netlib2.cs.utk.edu/lapack/patch/src/dgesdd.f

 >

 > LWORK >= 4*min(M,N)*min(M,N) + max(M,N) + 9*min(M,N).

 > (Larger for more performance)

 >

 > I set it to that in both functions that call DGESDD, and it seems to

 > have fixed the problem!  I'm not sure how much higher it should be set

 > to if we want more performance; I guess its ok for now.

 >

 > I have only found the problem with SVDs of LaMatGenDoubles.

 

If this modified lwork definition fixes your problem, then go ahead and 

commit it. According to the documentation, it is possible to get the 

optimal size of lwork calculated by DGESDD itself (by an additional call 

to DGESDD beforehand). In this case this would be the optimal solution, 

but to be honest, I'm too lazy to implement this :-) If you want to 

commit something like that, just go ahead.

 

Christian