Re: numeric/ublas & gcc 3.0

From: walter_at_[hidden]
Date: 2001-09-19 05:29:10

--- In boost_at_y..., Kresimir Fresl <fresl_at_g...> wrote:
> On Wednesday 29 August 2001 19:50, walter_at_g... wrote:
> 
> > > > Thanks a lot. I incorporated most of your changes and compiled
> > > > with GCC 2.95.2. I hope, that we do not have to differentiate 
> > > > between 2.95.2 and 3.0. 
> 
> Almost. Only remaining problem which I noticed is that the lines
> 
>    #ifdef USE_GCC
>    namespace std {
>        template<class I, class T>
>        struct iterator {};
>    }
>    #endif
> 
> in `iterator.h' must be deleted (or commented out) to compile with 
3.0.1.

Fixed. 

> (Also, there's no need for nonstandard definitions of `copy()' and 
> `swap_ranges()' in `config.h'. Were they really needed for 2.95?) 

Not absolutely. But there are a few differences in the STL 
implementations of MSVC, GCC and BCC and this was a possible solution.

 
> > > There's one more thing which I noticed in my examples:
> > >
> > >     matrix.h should include vector.h.
> 
> > Will be done, thanks for the hint.  
> 
> Still pending ;0) 

Sorry, done.

> There are some other missing includes: 
> 
>   `vector_pr.h' in `matrix_pr.h'
>   `matrix_pr.h' and `matrix.h' in `matrix_sp.h'

I'll have to reconsider the include dependencies.

>  
> > > BTW, do you plan to add const versions of functions
> > > matrix<>::row(), matrix<>::column() and matrix<>::project()
> > > (which probably means introduction of corresponding
> > > types const_matrix_row<> etc.) ?
> >

[snip a first idea]

> I think that `const_vector_range_type' can be defined as: 
> 
>   template<...>
>   class vector {
>         // ...
>         typedef const vector<T, F, A> const_self_type;
>         typedef const vector_range<const_self_type> 
>                     const_vector_range_type;
>         // ...
>    };
> 
> and used as:
> 
>    const numerics::vector<double> cv (v); 
>    typename numerics::vector<double>::const_vector_range_type 
>         cvr (cv.project (b, e)); 
> 
> All legal (const) accesses are then possible. 

Yes.

> (This is `VARIANT 1' of  typedefs and functions that provide const 
> projections -- see below.) 
> 
> > I currently would not like to introduce classes like
> > const_vector_range, because that could result in more 
> > source code or more complex template constructions.
> 
> In fact, there's no need for new types (as I thought before).
> Classes 
> 
>   vector_expression_range<>
>   matrix_vector_unary1<> 
>   matrix_vector_unary2<>
>   matrix_expression_range<> 
> 
> (which are return types of `global' project(), row() and column()
> functions) can be used as return types of  const member 
> functions: 
> 
>   template <...>
>   class vector {
>         // ...       
>         typedef vector<T, F, A> self_type;
>         typedef typename 
>            vector_expression_range_traits<self_type>::result_type
>            const_vector_range_type;
>         // ...
>         const_vector_range_type project (const range& r) const {
>             return numerics::project (*this, r);
>         }
>         // ... 
>    };
> 
> I prefer this second variant; after all, these classes were 
obviously
> designed to provide const projections. 

This is another approach to implement const projections, but 
expression templated projections are mainly designed to provide const 
projections for expressions, for example project (a + b, 0, size). 
IMO there are three reasons to implement const projections for 
containers and proxies using your first approach: 
- we currently can't use range composition with expression templated 
projections
- compile times may slow down with expression templated projections
- expression templated projections seem to be slightly slower at 
runtime
  
> Also, non-const projection classes (vector_range<>, 
> matrix_row<>, matrix_column<> etc.) can then be simplified. 
> For example, there is no need for const and non-const element 
> access operators: 
> 
>   template <...>
>   class vector_range {
>       // ...
>       value_type operator () (size_type i) const {
>            // One has do to this, to get the const member 
dispatched?!
>            const vector_type &data = data_;
>            return data (r_ (i));
>        }
>        reference_type operator () (size_type i) {
>            return data_ (r_ (i));
>        }
>        // ...
>   }; 
> 
> (Quoted comment points to the problem.) 

The mentioned comment concerns problems with sparse access. I'm not 
sure, whether these are really solvable with const proxies. I'll 
think about it. 

> Const version (which returns non-const reference) suffices: 
> 
>        reference_type operator () (size_type i) const {
>            return data_ (r_ (i));
>        }
> 
> This is similar to iterators: derefence operator is const although
> it returns non-const reference to some element of a sequence.
> 
> I added const projection typedefs and functions to all (I hope)
> relevant classes. Diff files (with respect to the latest version 
> in CVS) are attached, if you are interested.  

Yes. We've incorporated an implementation using your first approach 
and checked it in. Thanks.

[snip example]

> First variant does not work with canonical_vector<> 

Fixed.

> and the
> second with banded_matrix<>; 

banded_matrix was an early draft. We've updated it and provide a new 
test.

> strange, it seems that in both 
> cases the reason is that 'iterator' or 'const_iterator' are not 
> defined. 
> 
> (Proposed changes to non-const projection classes are not
> yet done.) 

Regards
 
Joerg Walter