Re: [boost] Re: Boost Mathematicians

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
>     http://bayesclasses.sf.net
> ___________________________________
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>