Re: [boost] Re: questions on ublas ?

From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2001-12-06 04:45:59

jhrwalter wrote:

>>what's the complexity guarantee of `resize`. I guess it is intended 
>>to reshape a matrix without having to allocate memory. 
>  
> If possible, yes (the actual implementations are occasionally 
> suboptimal ;-). It's an open question, whether there is need for a 
> similar operation which conserves matrix data. Complexity guarantees 
> depend on operator new, but should be quadratic.
>  
> 
>>For instance if I 
>>need a temporary matrix in a loop, but in every loop the total size 
>>of the matrix can be different, I can allocate a matrix with some 
>>maximal size and resize it in every loop to something smaller in every  
>>loop in constant amortised time ?
>>
> 
> Currently not, but it should be possible to change this. May be we 
> need to differentiate size() and capacity()?

Definitly. This would minimise memory allocation !

>  
> 
>>How should I create a sub-matrix using the matrix<T>.project 
>>member ?
> 
>>I can do :
>>Matrix::const_matrix_range_type mr( m, numerics::range(0,subsize), 
>>numerics::range(0,subsize) );
>>but the following does not compiler :
>>Matrix::const_matrix_range_type mr( m.project(0,subsize, 0, 
>>subsize ) );
> 
> A couple of issues. First, member function project is deprecated. 
> Please use the free function project(m, ...). Second, the usage of 
>     project (m, range(0,subsize), range(0,subsize)) 
> vs. 
>     project(m, 0,subsize, 0,subsize) 
> is an open interface question: the former describes the intent more 
> specific (I hope) and is consequently implemented, the latter is 
> easier to type (and avoids two objects :-). I'd like to deprecate one 
> of these forms also, but which? 

maybe using the range is more instructive and thus the best interface, 
but it creates two temporary objects ;-( So I'm unsure.

> Third, typedef's like 
> const_matrix_range_type are deprecated. BTW, please have a look (and 
> define) at NUMERICS_DEPRECATED in config.h.

OK. Thanks.

>  
> Summarized: I'd prefer to write something like
>  
> matrix_range<Matrix> mr(project(m, range(0,subsize), range(0, 
> subsize ));

Thanks.

> 
> Bonus question: what's the best namespace name?

I guess you mean the namespace for the whole ublas package ? boost or 
boost::numerics I guess.

>>Most important : I'm curious where the name `ublas` comes from ?
> This shall be our small secret ;-) But it's certainly a tribute to 
> these Fortran guys :-)

I can imagine. The leading `u` intrigues me though.

>>Does the sparse matrix also support COO (coordinate) and 
>>most important CSC (compressed sparse row or Harwell-Boeing) 
>>format ?
> 
> No. Our base containers vector, matrix, sparse_vector and 
> sparse_matrix were designed to use std::vector and std::map as 
> storage and prove interoperability. CRS and CCS storage formats have 
> to be implemented. With regard to COO I'm unsure.

To assemble our big sparse matrices, we first generate the COO structure 
from which we generate the CSC structure and then perform the assembly 
of the FE model using this structure. So COO is just an intermediate 
step because a CSC needs to built up column per column to avoid copying 
the whole content back and forth.

>  
> 
>>In that case I'm going to deploy it in my own projects ASAP ! Nice !
>>
>  
> Sorry, we're not as fast ;-)
I would be interested in doing it myself (with a little support of course)

if you think it's feasible.