|
|
Ublas : |
From: Paul C. Leopardi (leopardi_at_[hidden])
Date: 2005-06-22 19:29:42
On Wed, 22 Jun 2005 08:14 pm, Michael Stevens wrote:
> On Monday 20 June 2005 11:44, Ian McCulloch wrote:
> > A global switch like that would be a mistake, IMHO. It would make it
> > impossible to combine uBLAS functions from different sources while sill
> > retaining performance, and force people wanting to write portable code to
> > ALWAYS use either alias() or noalias() on every expression.
>
> Agreed. The ability to combine uBLAS functions from different sources is
> fundamental to me.
>
> > However, something that might be useful is a global option to force
> > alias() to be always on (ie, force 'safe' execution, even if noalias is
> > specified), for debug checking.
>
> Interesting idea. Something like BOOST_UBLAS_CHECK_NOALIAS perhaps?
>
> > Perhaps it would be better to move the alias policy into the containers?
> > The way I see it, you can think of an expression such as
> >
> > Vector x,y;
> > Matrix M;
> > x += M*x + y;
> >
> > in two ways:
> >
> > As an array expression, it is essentially a shorthand for
> >
> > for (i = 0; i < N; ++i)
> > {
> > x[i] += inner_prod(M[i], x) + y[i];
> > }
> >
> > here the aliasing problem is obvious.
> >
> > Alternatively, if you view it as an expression over a ring (or R-module,
> > or whatever), you would expect it to behave the same way as if x,y,M were
> > simple numbers, and x += M*x + y should 'just work'.
>
> Agreed. Two different way of view the problem.
>
> > So, how about
> >
> > Vector<double> x; // default: forces 'safe' handling of aliases
> > Vector<double, noalias> y; // fast: user takes responsibility for aliases
>
> Syntacticly this is elegant but allowing container semantics to change is
> bad!
>
> In generic code this brakes your portable code criteria. For example
>
> template <class V>
> multA (V& l, const V& r)
> {
> l = prod (A, r);
> }
>
> Without knowing it's implementation it is impossible to know if 'multA (y,
> y)' is correct.
Could this problem be solved by using container concepts or traits? I don't
know what the most correct or prettiest syntax would be, but maybe a Boolean
whatever_traits<T>::CanBeAliased ?
There would need to be a uBLAS header file where known types would be assigned
a default behaviour. Using the example above,
whatever_traits< A<B, noalias> >::CanBeAliased would always be false.
I may have no precise idea what I'm talking about, but I think you mentioned
something in this general ballpark before. See eg,
http://lists.boost.org/MailArchives/boost/msg31900.php