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
_______________________________________________
glas mailing list
glas lists.boost.org
http
://lists.boost.org/mailman/listinfo.cgi/glas
|
