|
|
Glas :Re: [glas] Vector Spaces vs. "Objects called vectors" |
From: Karl Meerbergen (Karl.Meerbergen_at_[hidden])
Date: 2005-02-04 05:42:05
Kevin Wheatley wrote:
>Ian McCulloch wrote:
>
>
>>Clearly, in a lot of cases it doesn't make sense to resize the vector.
>>eg, "x += y", x and y should be the same size. The only case where it
>>would be sensible to consider resizing is for ordinary assignment. Here,
>>I don't think it is even sensible to fix a policy, if only for
>>interoperability reasons (how would you prevent a resize for std::vector?
>>How would you allow resize for a fixed-size array?).
>>
>>
>
>x += y, what if x has a sparse representation? (OK so I'm playing
>advocate here)
>
>I think what your meaning is that the size (math?) is like the
>capacity (CS) and that x and y have the same notional
>capacity/dimensionality. This would be a different thing to the
>underliying storage capacity/size which may need to be modified.
>
>Is this a desirable property of a vector (and thus by orthoganally a
>matrix), to be able to allow the user of the objects to stop
>themselves from incurring this 'hidden' memory allocation cost. I
>think it is.
>
>Conversly is it desirable to allow flexibility and the user to care
>less about the underlying representation, also a yes I think.
>
>Conclusions:
>
>a point of variation in policy is probably needed for storage
>reallocation
>maybe dimensionality miss-match is an error - provide an explicit
>conversion mechanism like a dimensionality_cast<>() ?
>a glossary/dictionary of terms and concepts is important (most
>important?) to progress anywhere between the two meeting groups
>here...
>
>Kevin
>
>
>
I think you have made an interesting comment here about the sparse case.
Do we want to change the sparse structure of a sparse vector with an
assignment?
I would say: yes we have to allow it, but we also have to have a
mechanism that forbids it (i.e. there is only an assertion on an equal
structure). The same holds for sparse matrices, since operations on
sparse structure are slow. The performance penalty for +=() can be quite
high.
From all reactions we have had so far, I believe that we have to
provide two assignment policies:
* allow assignments that allow changing the size and the sparse structure
* and assignments that do not allow it. The argument of efficiency for
the dense case is not proven (in this mailing list that is), but this
might be different for the sparse case (I say might, it has to be
verified). On the other hand, the argument of robustness of codes where
the size is assumed not to change is very valuable.
Karl