Boost logo

Boost :

From: John Fuller (jfuller_at_[hidden])
Date: 2004-07-06 07:49:54

On Jul 6, 2004, at 5:42 AM, Michael Stevens wrote:

> On Monday 05 July 2004 22:59, David Abrahams
> <dave_at_[hidden]>
> wrote:
>>> Almost all the major reference works on BLAS and Matrices
>>> simply state elements are either Real or Complex and are therefore
>>> implicitly a field.  
>> We're not just concerned about the elements of matrices, but the
>> vectors and matrices themselves.
> OK I was assuming you were looking for a clear concept definition for
> the
> element types.
>> This becomes a real issue when you
>> have to write algorithms that might operate on matrices of reals or
>> matrices of matrices -- yes, these things do come up in real
>> applications.
> This is very odd. In linear algebra there is no such thing as a matrix
> of
> matrices.

What about a block diagonal matrix?

> This impacts on the while prod/operator* controversy.
> That is, the primary advantage of not defining operator*. It prevents
> you
> passing matrix to an algorithm (not necessarily part of the uBLAS
> itself)
> that uses operator* and not unreasonably makes the assumption that
> operator*
> is commutative. The assumption is not unreasonable as all built in
> types
> operator* is exactly commutative.
> That said I have also argued in favour of operator* instead of prod in
> the
> past. It's central role in LA certainly argues in favour of using
> operator*.
> This involves so much peoples expectation as for algebraic notation,
> programming practice and just personal taste.
>>>> * Redundant specification of element type in matrix/vector storage.
>> See my reply to Toon.
> Ah yes value_type is specified in both the matrix vector and storage
> type
> parameter list. In itself this is not good as the storage type should
> parameterise the matrix/vector with the value_type. It is simply there
> to
> make the syntax in the default case simple without the need for a type
> generator as in MTL.
>>> For std::slice (valarray) compatibility stride should be last. Not
>>> sure
> why
>>> this was not picked up on a long time ago!!
>>> valarray (and uBLAS) use size (not end) for good reason however.
>> ...which is...?
> The begin end definition fails when stride==0. Slices of finite size
> with
> stride==0 are very useful. Similarly when (end-begin) *stride <0 the
> behaviour would have to be defined.
>>> Interesting solution. Agreed, the current implementation is closed to
> other
>>> objects because of the intrusive base class. Sadly uBLAS was designed
> before
>>> enable_if. Any pointers to compile/runtime effects of the enable_if
> solution?
>> I can't really imagine what you're asking for here.
> I was looking for any publications/links to compare how compilers do
> between
> the two solutions. Anyone have any pointers?
> Thanks,
> Michael
> --
> ___________________________________
> Michael Stevens Systems Engineering
> Navigation Systems, Estimation and
> Bayesian Filtering
> ___________________________________
> _______________________________________________
> Unsubscribe & other changes:

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