Re: [ublas] Transition to default handling of possible lvalue aliases

From: Ian McCulloch (ianmcc_at_[hidden])
Date: 2005-06-20 04:44:55

Gunter Winkler wrote:

> On Monday 20 June 2005 09:46, Michael Stevens wrote:
>> For : Me, Ian, Christopher (I assume)
>> Against : Dan, Kres, Greog
> 
> I am still indecisive, but I tend to prefer exactness over speed. Is there
> no way to have a global switch 'alway use safe assign'/'always use
> possible unsafe assign'? This way we could give the choice to the user and
> have him override the default via (no)alias() functions.

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.

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.

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'.

So, how about

Vector<double> x;          // default: forces 'safe' handling of aliases
Vector<double, noalias> y; // fast: user takes responsibility for aliases

These would be roughly analagous to C99 restricted and non-restricted
arrays,

double x[];
double y[restrict];

in their expression semantics.

Cheers,
Ian