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

From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2002-01-21 18:18:10

Ralf W. Grosse-Kunstleve wrote:

>>>FWIW: a few theoretical remarks (born out of very pragmatic needs):
>>>...
>>>Memory management:
>>>  Ultimately any array is a one-dimensional array. Here I
>>>  see six important memory management policies that are
>>>  useful in different contexts:
>>>    - automatic allocation, fixed size() (aka boost::array)
>>>    - automatic allocation (fixed capacity), variable size()
>>>    - dynamic allocation, fixed size()
>>>        deep copy semantics
>>>        reference counted
>>>    - dynamic allocation, variable size() (e.g. std::vector)
>>>        deep copy semantics
>>>        reference counted
>>>
>>is'nt the difference between e.g. 'automatic allocation,
>>fixed size' and 'dynamic allocation fixed size' not more a
>>question of the way you instantiate it instead of being a
>>policy ? (just to sync terminology to make sure that I know
>>what you're saying)
>>
> 
> Do you mean
>     auto_fixed_size<int, 3> a;
> vs.
>     auto_fixed_size<int, 3> *a = new auto_fixed_size<int, 3>;
> ?
> To me it seems that the "new" statement throws you back to
> the stone ages w.r.t. memory management.

> smart_ptr is an improvement, but the expression for
> allocation becomes horrendous, 

I don't agree : object ownership needs to be tackled at the design stage 
in the first place. But that is not the issue here.

> ... and access to the interface
> of the embedded vector requires dereferencing.

dynamic allocation will always involve a pointer dereference, would'nt it ?

> 
>>>  A slice is just a special access scheme, or a generalized
>>>  simple access scheme.
>>>
>>are'nt you mixing storage scheme and access schemes. After
>>all, we want all matrices (sparse, skyline, dense, ....) to
>>have the same interface (and thus 'access'-eable in the
>>same way) but depending on the storage one way provides
>>faster access compared to another access method (or
>>complexity guarantees or dependent on the storage scheme
>>underneath, which is actually similar to the STL)
>>
> 
> My suggestions pertain only to dense arrays...

even in that case, my remark still stands. E.g. for a 2D matrix, the 
first index will always indicate the row, the second always the column, 
independent of the aspect if the matrix is column-major or row-major.

>>BTW talking about access methods. After the performance
>>discussion about multi_array, I'm inclined to say that the
>>generic access methods for a multi-dimensional array lib
>>are probably not performant enough for numerics without the
>>proper specialisations for the 1D and 2D case.
>>
>>I think the linear-algebra world is big enough to justify
>>this specialisation.
>>
> 
> ... because (1) we do not work with sparse arrays (yes, not
> a good reason, but), (2) my instincts tell me that a uniform,
> generic treatment of dense and sparse arrays will incur too
> many performance penalties. However, I believe that a
> uniform treatment of dense arrays is feasible.
>  
> 
>>>A partial implementation of these ideas can be found in the
>>>cvs tree at cctbx.sf.net (e.g. shared_storage.h, ndim.h,
>>>loops.h; maps/ndim.h implements a specialized accessor;
>>>naming is still a bit disorganized). We are currently
>>>refining the design. I would be happy to share more details
>>>if there is an interest.
>>>
>>I'm interested. Does this mean that you have implemented another 
>>matrix-library (no blitz, mtl, ublas) ?
>>
> 
> No. What I have implemented at this point is much less
> ambitious than the packages you mention, and not even
> accessible as a separate package. My ideas and the code
> evolved with an application. This application is meant to
> become a large software system, so I find it necessary to
> generalize as much as possible without losing contact with
> my "real" goals (which is the implementation of a system
> for crystallographic computations).
> Also, my previous message did not address operator
> overloading at all. But see below.
> 
> Let me summarize some basic ideas to see how much you can relate
> to them:

looks interesting but find it a pitty though that you're not using MTL 
or ublas. I'm currently using ublas in my project and it works very 
well. Apparantly you care a lot about memory handling (smart ptrs, 
references .. ) but I think you can achieve all these with the current 
libraries too.