## Glas :## Re: [glas] Block matrices |

**From:** Karl Meerbergen (*Karl.Meerbergen_at_[hidden]*)

**Date:** 2005-10-21 03:32:59

**Next message:**Peter Gottschling: "Re: [glas] Block matrices"**Previous message:**Wolfgang Bangerth: "Re: [glas] Block matrices"**In reply to:**Wolfgang Bangerth: "Re: [glas] Block matrices"**Next in thread:**Peter Gottschling: "Re: [glas] Block matrices"**Reply:**Peter Gottschling: "Re: [glas] Block matrices"

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

**Next message:**Peter Gottschling: "Re: [glas] Block matrices"**Previous message:**Wolfgang Bangerth: "Re: [glas] Block matrices"**In reply to:**Wolfgang Bangerth: "Re: [glas] Block matrices"**Next in thread:**Peter Gottschling: "Re: [glas] Block matrices"**Reply:**Peter Gottschling: "Re: [glas] Block matrices"