|
|
Ublas : |
From: Karl Meerbergen (Karl.Meerbergen_at_[hidden])
Date: 2005-01-25 12:48:57
Hello,
Here is what I have got in the report from the uBLAS meeting.
Karl
Resizing
Recall the discussions on the mailing list about resize()! We decided that
resize never preserves the data. On the other hand, we provide free functions
that perform a resize with preservation of the data in some way. This always
creates temporaries to store the old data and copy them in the new data. The
latter operation is clear for vectors, but for matrices, sometimes we may
want to copy the old data into a matrix_range corresponding to the old,
sometimes we may want to copy the data array. The user can better do the
resize with preservation. It keeps the containers slimmer and allows for more
freedom.
Clear
The member function clear() is defined for matrix and vector containers and is
used in type checking. We assume that value_type is zero (0) constructable.
This may not always be the case. We may also need one constructability.
There was suggested to add these value dependent operations in the
type_traits, for example:
struct type_traits< double > {
...
double zero() { return 0.0 ; }
double one() { return 1.0 ; }
...
};
On Tuesday 25 January 2005 11:02, Gunter Winkler wrote:
> On Monday 24 January 2005 20:33, Daryle Walker wrote:
> > I don't know much about uBLAS, so sorry if I sound like an uneducated
> > newbie. This sounds like you use "value_type(0)" whenever you need a
> > zero value for a type. What's wrong with "value_type()"? Every built-in
> > and user-defined numeric (scalar) type I know of makes the explicit
> > default constructor evaluate its object to zero. This policy would be
> > easier to accept for types that didn't want an "int" constructor. You
> > have to use the explicit syntax because implicit default construction for
> > built-in types leaves them as a bucket of random bits (for C
> > compatibility and to not add extra code).
>
> We already discussed this issue at the developer meeting. We finally
> decided to use value_type(0) because value_type could be a big algebraic
> object, e.g. a matrix. For matrices there is a big difference between
> allocating an empty matrix using the default constructor and allocating a
> matrix full of zeroes using the "int" constructor. Maybe this behaviour
> will be replaced by some traits classes in a future version of ublas. The
> traits classes can provide other useful information like value_type(1),
> too.
>
> mfg
> Gunter
>
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas