Re: [boost] uBLAS formal review

From: Joerg Walter (jhr.walter_at_[hidden])
Date: 2002-06-29 08:17:47

----- Original Message -----
From: "Fernando Cacciola" <fcacciola_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, June 28, 2002 4:06 PM
Subject: Re: [boost] uBLAS formal review

>
> ----- Original Message -----
> From: "David Abrahams" <david.abrahams_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Thursday, June 27, 2002 8:23 PM
> Subject: Re: [boost] uBLAS formal review
>
>
> >
> > From: "Fernando Cacciola" <fcacciola_at_[hidden]>
> >
> > > Not using valarray<> prevents fast 'memcpy' optimizations...
> >
> > valarray isn't the only route to those optimizations is it? Couldn't one
> > equally say "not using std::copy() prevents fast 'memcpy'
> > optimizations..."?
> >
> You are right, valarray<> isn't the only route for those optimizations.
> What I meant to say -but I didn't- is that there are at least 3 different
> ublas arrays all sharing a common internal array representation.

The only use of some of the uBLAS classes is to measure the effect of
certain techniques on the abstraction penalty (without increasing the
abstraction ;-). The stack based bounded_array for example seems to be real
useless for numerical work.

> It seems
> reasonable to me to factor this out into a POD-optimized value-based
array.
> That's the purpose of valarray, isn't it?
> I know nobody likes it (valarray), but at least as a concept it is
precisely
> up to this task (being used as the internal storage of a higher level
array
> data structure).
> If valarray<> usual implementations can't be trusted, I would code a
> valarray like, POD-optimized, class as part of ublas and use it. It
doesn't
> need much of the valarray<> interface, so it can be quite simple.

I'm not sure about this. valarray<>'s greatest weakness w.r.t. uBLAS is,
that iterators are missing.

Regards

Joerg