
Boost : 
From: Joerg Walter (jhr.walter_at_[hidden])
Date: 20020501 14:45:47
 Original Message 
From: "Peter Schmitteckert (boost)" <boost_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, April 30, 2002 8:36 PM
Subject: Re: [boost] ublas: matrix clear() and operator=
> Salut,
>
> On Tuesday 30 April 2002 18:09, Toon Knapen wrote:
> > Currently, the matrices can be clear()ed such that all elements are set
to
> > 0. I would find it even more convenient to be able to use
> > operator=(some_value_type) to assign a specific value to all the entries
in
> > the matrix. But I figure there's some good reason one has to use clear()
> > instead of operator=() ?
>
> As fas as I understand, this is only true for raw memory, if you use
> std::vector, then std::vector().clear() will be called, erasing the
elements.
> If I'm correct than one has to be carefull to use ublas::matrix<
> std::vector<..>, ... > to interface with FORTRAN libraries, since one
> must not call clear() before calling FORTRAN routines. (This question
> was raised some time ago on this list).
> Jörg, am I'm correct ?
AFAIK, Toon needs to first initialize a matrix to zero and then to add parts
consecutively, something like
matrix<> m;
m.clear ();
for (...)
m += ...;
He wants to express the intent of m.clear() more clearly ;). This is one of
the drawbacks of the decision not to initialize numerical vectors and
matrices for performance reasons.
May be, it would be a good thing to add initializing constructors.
> Concerning your operator, one might instead define a matrix with all
elements
> set to 1, similar to matrix_identity, otherwise
> matrix A = 2
> might be confusin. I'd expect this expression to set the diagonal elements
> only, while you might expect that all elements are set to 2:
> Matrix A = 2 * matrix_identity;
> Matrix B = 2 * matrix_all_elements_one;
I've already played with something like a scalar_matrix<>, which is constant
in all elements. But such a (dense) matrix doesn't harmonize with sparse
matrices.
Regards
Joerg
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk