|
|
Ublas : |
From: Karl Meerbergen (karl.meerbergen_at_[hidden])
Date: 2007-09-20 16:47:43
It is my feeling that assignment of sparse matrices is not uniquely
defined. Assuming that sparse structures are the same for LHS and RHS
are too strong in many cases. But such an operation should be provided,
because it is efficient and happens in many applications.
There are many types of assignment that could be thought of, but it is
my feeling that they cannot all be covered by ublas. It is too
application dependent.
I have no suggestion for the default meaning of assignment.
Karl
Vardan Akopian wrote:
> On 9/20/07, Gunter Winkler <guwi17_at_[hidden]> wrote:
>
>> Am Donnerstag, 20. September 2007 11:44 schrieb Vardan Akopian:
>>
>>> Given 2 sparse
>>> matrices a and b, it looks like doing
>>> noalias(b) = a
>>> does not transfer a's full structure to b, i.e. a's structural 0's
>>> are lost. For example after that assignment a.nnz() may not be equal
>>> to b.nnz(). Note that, "b = a" works as expected. So is this intended
>>> behavior?
>>>
>> The answer can be found in matrix_assign.hpp at line 922. There is a
>> check if the value to be assigned is zero. When this is true the
>> assignment is skipped.
>>
>
> Thanks for finding that, matrix_assign.hpp is not the easiest file to
> parse visually, even when I knew what I was looking for ;-)
>
>
>> The expression noalias(b)=a is equivalent to b.assign(a) which directly
>> calls the matrix_assign mentioned above. Thus all stored zeroes are
>> dropped.
>>
>> The expression b=a does the same in most cases. Only if b and a are of
>> the same type the assignment is optimized (see matrix.hpp line 2862) to
>> exactly copy all internal arrays. Thus the structure is preserved.
>>
>
> Right. The question however is really the guarantee: is this
> documented, and future-proven? Can code rely on that fact, or is it
> just an implementation detail, that can change at any time.
> Another question: is it a bug (by the user) to rely on information
> about the internal structure of the compressed matrix (or the fact
> that 2 matrices have the same structure)?
>
>
>> We can now discuss whether this is a bug (missing optimization of
>> assign) or a design decision. What do you think?
>>
>
> Or maybe the bug is the other way around: matrix_assign optimizing
> where it shouldn't be?
>
>
>> IMO the behavior of operator = () and assign should be identical.
>>
>
> I'm tempted to agree, but I can see that some people might want to
> take advantage of either version. I for one needed the "structure
> preservation" feature. Perhaps a clone() type of method could
> accomplish such a thing?
>
> I think any solution (including the status quo) is fine if it's
> documented, and maybe even added as part of the sparse matrix concept.
>
> -Vardan
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
>