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
>>> 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
> 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
> This is very odd. In linear algebra there is no such thing as a matrix
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
> passing matrix to an algorithm (not necessarily part of the uBLAS
> that uses operator* and not unreasonably makes the assumption that
> is commutative. The assumption is not unreasonable as all built in
> operator* is exactly commutative.
> That said I have also argued in favour of operator* instead of prod in
> past. It's central role in LA certainly argues in favour of using
> 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
> 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
> 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
>>> 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
> 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
>>> objects because of the intrusive base class. Sadly uBLAS was designed
>>> enable_if. Any pointers to compile/runtime effects of the enable_if
>> I can't really imagine what you're asking for here.
> I was looking for any publications/links to compare how compilers do
> the two solutions. Anyone have any pointers?
> Michael Stevens Systems Engineering
> Navigation Systems, Estimation and
> Bayesian Filtering
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk