Re: [boost] Re: slicing and ranges of matrices

From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2002-01-22 02:49:51

rwgk wrote:

> --- In boost_at_y..., Toon Knapen <toon.knapen_at_s...> wrote:
> 
>>dynamic allocation will always involve a pointer dereference, 
>>
> would'nt it ?
> 
> Yes, but there is a difference in how you present it to
> the user. IMO it is most convenient if the user is presented
> with the same interface, irrespective of the details of
> memory handling. To my knowledge this means the smart
> pointer must be embedded inside the array class.
> Also, generic functions for operations on arrays require
> that the interfaces are identical.

Maybe it would be good that you make the dereference explicit, this way, 
developers clearly see what they are doing and thus are accessing the heap.

But if you really want the embedded smart pointer, I'm pretty sure you 
can do that in ublas too by defining your own storage scheme. I'm 
willing to take a look at it if you would be really interested.

> What is a row, what is a column?
> When porting FORTRAN code to native C++ I needed a type
> where the first index is the the "fast index"
> and the second is the "slow index." Otherwise I would need
> to torture my brain with rewriting all the algorithms.

A policy (row-major, column-major,... )defines which index is the fast 
one, the mathematical notation always stays the same. Indeed if you care 
only about dense matrices, you could combine access scheme and storage 
scheme but this does not scale to sparse matrices. But there's no harm 
to distinguish these two concepts for dense matrices either.

> Great. But why are you still looking at multi_array?

because I want to stay up to date to what is being developed in boost 
and I'm interested how others solve the matrix-handling problem in C++ 
(there's definitly a need for a standard matrix in C++, the only reason 
why people still stick with fortran)

> For me the answer is that I do not want a linear algebra
> package but a versatile array handling package.
> There seems to be a consensus that this needs to be
> cleanly separated.

I'm not using multi_array but in few occasions I could benefit from a 
multi-dimensional container I suppose. Nevertheless I'm not sure that 
such a generic component is a good basis for a linear-algebra package 
(MTL) but that's of course for Ron and Jeremy to figure out ;-)