Boost logo

Ublas :

From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2005-06-16 06:10:18


christopher diggins wrote:
>>This is certainly a good idea in many cases. For instance if you're going
>>to
>>perform a lot of operations on a matrix_range, it might be much better for
>>performance to make sure that the data in the matrix_range is continuous
>>in
>>memory. Currently I advise people to assign their matrix_range to another
>>matrix in such cases. At the end of the operations they should however not
>>forget that they need to assign the matrix to the matrix_range if their
>>intention was to modify the matrix that is pointed to by the matrix_range.
>>
>>To conclude I think both approaches (proxy-views and deep-copy views) are
>>both necessary.
>
>
> Me too. This is why I suggested two namespaces. Perhaps the namespaces would
> better be named:
>
> boost::numeric::ublas::proxy
> boost::numeric::ublas::deep_copy
>
> The other alternative is to use a #define USE_PROXY, but I don't
> particularly like that approach.
>

The '#define' is certainly out of the question. The reason is that the
difference between proxy and deep_copy are semantically very different
similar to the difference between 'pass by reference' and 'pass by value'.

IMHO the way to have both is as I have described below: we know that in
uBLAS different containers are never aliased. Aliasing only occurs when
one is working with views. So from the moment only containers are used
in an expression, the expression engine can safely assume there is no
aliasing.
OTOH, due to the generics, containers and views can easily be
interchanged. It is thus also always possible to assign the content of a
view to a container. Thus if you want the expression engine not to care
about aliasing, replace your view by a container and voila!

> Thanks for so eloquently articulating my point!

I'm happy we have now all the misunderstandings out of the way and
everybody is on the same wavelength.