[boost] Re: Boost Mathematicians

From: Michael Stevens (Michael.Stevens_at_[hidden])
Date: 2004-07-06 05:42:33

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.

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
    http://bayesclasses.sf.net
___________________________________