|
|
Ublas : |
From: Ian McCulloch (ianmcc_at_[hidden])
Date: 2005-01-25 06:02:43
Gunter Winkler wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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)
Did we? I know there was a lot of discussion on value_type(0) versus a free
function (perhaps zero<T>() or construct_zero<T>()). I don't remember for
sure what the conclusion was, but I _thought_ it was for a free function.
I don't like the idea of value_type(0), because there are a lot of types
that have no logical need for a conversion from int, but are still useful
to put in a matrix or vector. Having to modify an existing class to add an
artifical conversion constructor from int (what if it is not possible to
modify the existing class?) is asking a lot from uBLAS users I think.
In my own code I have two functions,
template <typename T>
T zero<T>();
// forwards to nullary functor class Zero (for partial specialization)
and
template <typename T>
T zero_or_die<T>();
// uses enable_if on whether Zero<T>::result_type exists or not;
// if it doesn't an exception is thrown at runtime
and also static versions of both (for returning zero by const reference).
zero_or_die is useful in sparse algorithms where you only need a zero in
corner cases that the user may know for sure can never happen (eg, an inner
product of sparse vectors, zero only needs to be constructed explicitly if
there are no overlapping elements. If that can't happen, it is fine to
have element types that have no unique zero.)
> 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.
Exactly.
> 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.
But not a fat traits class, please. One class per quantity. But in general
it is better to avoid depending on having such quantities available, to the
maximum extent possible. I thought construction/resize etc was supposed to
be default construction (ie. uninitialized for POD's, default ctor for
UDT's) ? I thought that was the historic behaviour?
Cheers,
Ian