|
|
Glas :Re: [glas] Block matrices |
From: Karl Meerbergen (Karl.Meerbergen_at_[hidden])
Date: 2005-10-21 03:32:59
Hi,
Reading the reactions I think it may be wise to allow the value_type to be
anything. The algorithms for vector of matrix, e.g. depend on the concepts
that value_type applies to.
This implies that some more concepts are needed for the value_type's in order
to deal with any user defined value_type, possibly containers.
Having said that, I still think that if the goal is the creation of block
matrices, it should be a class by itself with the scalar values as value_type
since the blocked matrix bahaves like a matrix.
On the other hand, if the goal is to make a vector of matrices, it should
behave as a vector of matrices.
At this stage, the collections have some value_type that satisfies some
concepts. If the value_type is a Ring, it has a * and +, and so, we can
compute the dot() of two vectors.
In order to use a vector of matrices in dot(), the matrix should also be a
Ring: the matrix_type::operator*() (matrix_type) exists and returns some
type. (at this stage, in glas this is
operator_times_function<matrix_type,matrix_type>::result_type)
The dot product is the sum of matrix products (using *).
Similarly, norm_1 = sum of norm_1 of the matrices. This implies we have to
provide norm_1() for scalar types: this is just abs().
All clear? Agreed?
Karl
On Friday 21 October 2005 00:33, Wolfgang Bangerth wrote:
> > I dont know if "nested matrices" is a clever way or not but this is the
> > way we designed our LA library applied to deterministic transport codes.
> >
> > http://parasol.tamu.edu/asci/labfest-may05/lp-Generic_Programming_Experim
> >ents.pdf
> >
> > Anyway, our point is that we have to deal with complex matrix
> > structures. Symbolically, we have deal with objects like
> >
> > DenseMatrix< DiagonalMatrix< UpperTriangularMatrix < double > > > >
> >
> > In this respect the block view seemed a bit restrictive.
>
> What I meant to say is that if you do something like this, there is no way
> to access the element with _global_ coordinates (i,j), because the outer
> diagonal matrix can't just pass it through to its components (it doesn't
> know their sizes, for example). In effect, at least for element access,
> your outer matrix is more like an array than a matrix, and to write into
> the matrix requires you to step through its building blocks until you got
> to the innermost one.
>
> That being said, I can completely see the need for what you do (and we
> have exactly the same things in our radiative transfer code -- what a
> coincidence). I guess everything depends on whether you want the object to
> look more like a matrix or an array. I prefer the former view rather than
> the later, but that's fine because I can always get it by building the
> outer classes myself and using only numbers as template arguments for the
> proposed GLAS classes.
>
> Best
> Wolfgang
>
> -------------------------------------------------------------------------
> Wolfgang Bangerth email: bangerth_at_[hidden]
> www: http://www.math.tamu.edu/~bangerth/
>
> _______________________________________________
> glas mailing list
> glas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/glas
-- ============================================== Look at our unique training program and Register on-line at http://www.fft.be/?id=35 ---------------------------------------------- Karl Meerbergen Free Field Technologies 16 place de l'Université B-1348 Louvain-la-Neuve - BELGIUM Company Phone: +32 10 45 12 26 Company Fax: +32 10 45 46 26 Mobile Phone: +32 474 26 66 59 Home Phone: +32 2 306 38 10 mailto:Karl.Meerbergen_at_[hidden] http://www.fft.be ==============================================