Glas List: Re: [glas] Reference counting?

From: Karl Meerbergen (Karl.Meerbergen_at_[hidden])
Date: 2007-10-16 08:30:07

Neal Becker wrote:

>On Tuesday 16 October 2007, Karl Meerbergen wrote:
>  
>
>>Pieter Collins wrote:
>>    
>>
>>>I think that a general-purpose package needs to provide vector/matrix
>>>classes taylored to various uses.  An application using many 3d vectors
>>>will have very different requirements (fast allocation/deallocation,
>>>efficient storage) to an application using 1000x1000 matrices (efficient
>>>manipulation using views/slices).
>>>
>>>As I see it, reference counting will improve safety and may allow
>>>storage and slicing to be implemented by the same class, but does not
>>>introduce extra mathematical functionality. The expense is probably
>>>worth it for large objects, but not for small objects.
>>>
>>>Regarding the copy semantics, how about introducing a new concept
>>>"VectorView" which uses shallow copies to complement "VectorContainer"
>>>which uses deep copies? It seems like this concept is sufficiently
>>>important to be worth adding, though I generally think it's important to
>>>keep the number of different concepts to a minimum.
>>>
>>>Presumably it would be possible to separate storage (including reference
>>>counting) from the rest of the code by using an array template argument
>>>similar to uBlas.
>>>
>>>Regards,
>>>
>>>Pieter
>>>      
>>>
>>Hi Pieter,
>>
>>At this stage, there is no container concept in GLAS, so all options are
>>still open. I am in favour of having two container concepts, as you
>>suggest, View and Container, one with a deep copy constructor, the other
>>with a shallow copy constructor. I am currently using a shared_ptr for
>>this instead of a view.
>>
>>If two types of containers exist, the user has to be aware of the
>>difference in behaviour between copy constructors.
>>
>>I am not sure that a template argument is good enough to make clear that
>>the copy constructor has different behaviour ?!
>>
>>Currently you can do something like
>>
>>dense_vector<double> v( 10 ) ;
>>dense_vector<double> w( 4.0 * v ) ;
>>
>>This does not make sense with a shallow copy. In the case of a shallow
>>copy, this could become:
>>
>>dense_vector<double> v( 10 ) ;
>>dense_vector<double> w( size(v) ) ; w = 4.0 * v ;
>>
>>Best regards,
>>
>>Karl
>>    
>>
>
>That is exactly what I don't want.  Having different types for a view vs. an 
>array will make it much harder to interoperate with other languages.  I 
>believe the unified design is more elegant.
>
>
>An additional benefit of separating a view and memory management is that an 
>externally managed blob of memory can be adopted.  This allows 
>inter-operation with other array libraries.  For example, suppose we want to 
>interoperate with python numpy objects.
>

Neal,

Your concern to try and use unified types is correct.
The unified design you mention is possible to some extent, but it is not 
required for interoperability with other languages. (We actually use 
GLAS with BLAS, LAPACK and MUMPS.) For dynamic binding, it makes life 
clearly easier. I recall this was suggested several times on the ublas 
mailing list. So it could be an interesting feature of GLAS. I put it in 
the todo.

For each concept, we could provide a unified class: e.g.
continuous_dense_vector<T>
strided_dense_vector<T>
Whether this contains a reference count or not is another issue.

>
>If we follow blitz design, then copy constructor will reference the other 
>array data.  BUT, copying an expression will not.
>
>dense_vector<double> w (v.copy()) // deep copy
>dense_vector<double> w (v * 4) // no need to say (v*4).copy()
>  
>

Here, I see the following problem (if I understand well):

dense_vector<double> v ( w )
is a shallow copy when w is of the same type as v and a deep copy when 
it is another type. I do not think this is a good idea, especially, when 
you do not know the type of w, as it often happens in template programming.

I hope my analysis of your proposal is correct.

Karl