Boost logo

Boost :

From: Lee Elenbaas (lee.elenbaas_at_[hidden])
Date: 2006-11-13 03:01:51

On 11/10/06, Jason Hise <0xchaos_at_[hidden]> wrote:
> On 11/10/06, François Duranleau <duranlef_at_[hidden]> wrote:
> > On Fri, 10 Nov 2006, Jason Hise wrote:
> >
> > [snip]
> >
> > > This issue arises directly because of the fact that a matrix
> > > conceptually is a compound type, whose components should be accessible
> > > to client code. But a matrix is not just a compound type composed of
> > > elements. A matrix is composed of rows of elements.
> >
> > I agree on your stand about matrix vs vector types as being distinct,
> but
> > I don't agree that a matrix is just composed of rows of elements. It
> could
> > also be columns of elements. Which is it? A matrix should be left as a
> two
> > dimensional array (conceptually), either row-major or column-major or
> the
> > exact layout could be a parameter, as for boost::multi_array, except
> this
> > time maybe as a template parameter.
> Maybe. I have to wonder though if this flexibility adds
> functionality, or just room for confusion. I've heard of doing
> elementary row opeerations, but I have not heard of doing elementary
> column operations. I would think that a standardized means of storage
> and accesss would make code clearer, but I will concede this point if
> you can show me use cases where this flexibility comes in handy for
> client code.
> -Jason
> _______________________________________________
> Unsubscribe & other changes:

above certain rings sometimes it is necessary to perform elementary column
operations rather then row operations, something that i run into when i
attempted to build my own matrix implementation of fixed dimensions (sadly
before i was aware of boost)

Lee Elenbaas

Boost list run by bdawes at, gregod at, cpdaniel at, john at