|
|
Ublas : |
From: Dan Elliott (dan_elliott_at_[hidden])
Date: 2005-06-19 16:13:17
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!
>>
>>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