Boost logo

Ublas :

From: Dan Elliott (dan_elliott_at_[hidden])
Date: 2005-06-19 16:20:51


Michael Stevens wrote:
> Ok,
>
> After Karl wrote
>
>
>>Michael Stevens wrote:
>>
>>>I think Ian's suggestion of changing uBLAS default evaluation to be alias
>>>unsafe and checking on DEBUG builds is the way to go!
>>>
>>>Michael
>>
>>I agree,
>
>
> it would be good to try and agree on how we would make such a transition.
>
> First we will need some syntax to tell uBLAS to expect the lvalue to be an
> alias of something on the RHS and so to use a temporary. My suggestion would
> be to add the 'alias' function thus:
> alias (x) = expression;
>

Would uBLAS still use aliasing by default when dealing with objects like
matrix/vector ranges/slices? This must be what BLAS implementations
(like GSL) do.

> This is equivalent to the current 'noalias' which can be dropped once the
> transition is complete.
>
> Second we would need to document the expected change of semantics. The
> implementation of assignment without a temporary requires the lvalue be size
> conformant with the expression. This is different then the present default
> assignment via a temporary where we get resizing for free.
>
> Would the change of semantics be a big problem for anyone?

Will a uBLAS neophyte still be able to use uBLAS without having to buy a
padded helmet to prevent injury caused by repeatedly slamming their head
  against their keyboard out of utter frustration? In other words, if I
am ignorant of the fact that an operation requires aliasing, will my
program still work?

I would like to express my feeling it is good library behavior to
*always* provide the correct answer while *allowing* the intelligent
user to optimize. I am under the impression that uBLAS, in its current
state, gives us both. Therefore, although this has been an
enlightening, necessary conversation, I fear it is going to yield no
additional features while decreasing its usability.

- dan