Re: [ublas] Aliasing for += and -=

From: christopher diggins (cdiggins_at_[hidden])
Date: 2005-06-14 18:32:19

----- Original Message ----- 
From: "Robbie Vogt" <r.vogt_at_[hidden]>
To: "ublas mailing list" <ublas_at_[hidden]>
Sent: Tuesday, June 14, 2005 6:58 PM
Subject: Re: [ublas] Aliasing for += and -=

> Hi all,
>
> Ian McCulloch wrote:
>
>>FWIW, I have pretty much come to the conclusion that noalias should be the
>>default, but my reasons are (1) I think it IS easy, in *most* cases, to
>>determine when incorrect aliasing occurs - I guess Fortran programmers
>>learn very quickly, and (2) even if there is an aliasing problem, it is 
>>not
>>necessarily most efficient to copy the final expression.  There are some
>>cases where making a copy of a subexpression would suffice.  And (3) in
>>debug mode, the assignment operators can compute the expression both ways
>>and assert that the result is the same.
>>
>>
> I would like to second all of Ian's points above.  I always thought it a
> strange decision in the design of uBLAS to go the "safe" route at the
> expensive of performance, particularly in light of common practice in
> C/C++ library (and language) design to trust the programmer (eg.
> std::copy can also have aliasing issues if the programmer isn't
> careful).  I also believe a trust-the-programmer approach would have
> lead to far simpler code to maintain and enhance.
>
> Alas, as Christopher points out, this type of fundamental change in
> design would require an enormous effort to re-implement the entire
> library and would probably no longer be uBLAS as we know it.  I have
> been inclined in the past to suggest a complete rethink on the design
> and a "uBLAS 2," but hopefully MTL3 will fill this role.  Possibly our
> best plan of attack is to get more involved in the development of the
> new MTL so that it is brought to life as quickly as possible.
>
> Regards,
> Robbie.

I still don't understand why aliasing is used in the first place. Nobody has 
bothered to explain how it warrants the additional complexity and unsafety 
and performance penalty.

Christopher Diggins
http://www.cdiggins.com