Re: [boost] different matrix library?

Subject: Re: [boost] different matrix library?
From: DE (satan66613_at_[hidden])
Date: 2009-08-14 13:19:20

on 14.08.2009 at 20:45
 joel wrote :
>> internally i alwayse use ()
>> but [] are provided for users' convenience
> It's really not needed. operator(i) is the same semantically and I don't
> think any STD concept require [].
> Having matrix be real function object is also a good way to use htem 
> more generically.
i see no contra in you words
so i don't get why to drop nice subscript operator[]

>> but they are handled differently (different public interface)
>> vector is modeled after std::valarray (everybody knows about valarray)
>> and matrix is just a generalization of std::valarray behavior
>> oh and vector is a column-vector
> Just don't name it vector then. In lin. Alg. a vector is a matrix with
> one dimension equal to 1. if not, ppl will wonder why matrix*vector 
> doesn't mean what they think it does.
well i always thought that 'vector' is a column vector if not stated
explicitly otherwise
for me it's obvious
so (matrix*vector) is obviously a vector (column vector)

> You should have one matrix class whose tempalte parameters allow for
> customization.
> Want a matrix with static data : matrix<float, settings<static_> >
i thought about that and i agree that your variant is a better idea
but i have not started to refine the code yet
to my flavor it must be something like

    matrix<double, some_container_like_type<double> >
                                          //^^ double?
or even

   matrix<double, some_container_like_template_type>
   //template template parameter is used

> NRC allocation states that a array of N dimension is stored as N array
> of pointers, each pointinng to sub-element of the next one, the last one
> being a large, monolithic contiguous array of data. This allow for 
> N-dimensionnal acces via chains of [] and ensures cache locality at the
> latest level. It's easy to write, can be recursively extended for 
> arbitrary dimension number and ease the writings of code that requires
> you to extract or work on complex sub-array. performances of access is
> roughly the same that T* (within a 2% margin). this requires to have an
> iterface that takes smthg lika boost::array for handling set of 
> dimensions and indexing.
> sample 2D code here :
> http://codepad.org/nDy8z2iG
> of course this has to be hidden in the implementation.
sounds cool but i have no any tasks with >2 order involved so i was
not even considering
i will think about it
is it a must have feature in your opinion?

>> i've heard and forgotten
>> i've seen and memorized
>> i've done and understood
>> ...or something like thi
> which means ?
which means that if i have not done that i have not understood it

-- 
Pavel