[boost] Re: uBLAS: problem with sparse_vector

From: Michael Stevens (support-1_at_[hidden])
Date: 2002-06-28 02:23:21

>
>
>>> I suspect this to be a GCC bug and nothing to do with uBLAS. Looking at
>>> the execution path confirms this. All uBLAS 'v(x)' does is return a
>>> reference to a double
>>    
>>
>
>Something doesn't jibe here. If v(x) really *just* returns a double&, it
>doesn't matter whether v(0) is evaluated before or after v(1) = 42.
>
True! Ok it works out where in memory the double is, and THEN returns a 
reference to it. Obviously the "where it is in memory" part gets 
invalidated between the two assignments. ublas::map_array certainly 
invalidates every time it expands it capacity.

>On the other hand, if v(0) inserts an element in sparse storage, then it
>almost certainly matters. And the order of evaluation of v(0) and v(1) is
>unspecified according to the standard, so this sounds like a library bug to
>me. The "right" way to do sparse container indexing, AFAIK, has always been
>to use proxies. Thus, v(0) and v(1) would return proxies that do not insert
>anything until assigned to. Anyway, it would be a shame if a sparse vector
>becomes dense just because I decide to examine all the (possibly
>not-stored) elements.
>  
>
The way uBLAS implements sparse this is currently the case! This also 
means similar surprises can also happen on the right hand side or 
expressions if an unassigned element is accessed. Looks like this may be 
a serious problem with the current sparse matrix indexing.

>>>  >Note: there is the same problem with Loki::AssocVector.
>>>
>>> This seems to confirm it is a compiler and not a library problem. Anyone
>>> out there know if GCC generaly has problems with returned references?
>>    
>>
>
>Heh, I suppose two separate library authors are incapable of making the
>same mistake... ;-)
>  
>
Looks like we will have to trust GCC on this one :-)

Michael