|
|
Ublas : |
From: Michael Stevens (mail_at_[hidden])
Date: 2006-11-30 04:37:41
On Tuesday, 21. November 2006 17:11, Gunter Winkler wrote:
> On Monday 20 November 2006 16:29, Max Weinberg wrote:
> > For 1): If I get you right, the index type used for matrix and vector has
> > to be identical. That sounds logical. There has to be a template
> > parameter for IA that specifies the difference_type (now difference_type
> > is taken from the allocator, which makes no sense at all).
> >
> > For 2): No, a cast from IA::value_type to size_t makes no sense.
> >
> > There is another type "array_size_type" that you didn't mention. It is
> > intended to be used for indexing values in the index array. This could be
> > a small integer for most applications, since it is related to the number
> > of non-zeros you want to store in a sparse container.
> > If you want to store elements with big coordinates, you need a big
> > integer type for the index type (which is IA::value_type and
> > matrix::size_type). Unfortunately, in the current code array_size_type
> > and size_type are not used properly.
>
> So lets collect the requirements for the matrix class:
>
> size/difference type for data containers: usually native size_t, ptr_diff_t
> index type: IA::value_type
>
> matrix::size_type := index type
> matrix::difference_type := signed version of index type
Agreed. The difficulty is specifying the later since it is not deducable in
general. For dense containers it is easily specified by using the
difference_type from the storage arrays allocator. For sparse types I think
we need to explicitly specify it.
> this matrix should work together with a vector class that has the same
> size_type and difference_type. These types should be used by the underlying
> storage array as well.
Same type is good. In principle they just need to be convertable. Sadly
convertability is not commutative. So when dealing with binary operations we
need to make an arbitary choice of which type to use and which to convert to.
In my changes to functional.hpp I have simply chosen the LHS and taken the
types from there.
All the best,
Michael
--
___________________________________
Michael Stevens Systems Engineering
34128 Kassel, Germany
Phone/Fax: +49 561 5218038
Navigation Systems, Estimation and
Bayesian Filtering
http://bayesclasses.sf.net
___________________________________