Re: matrix library ?

From: hankel_o_fung_at_[hidden]
Date: 2001-03-24 02:24:42

--- In boost_at_y..., "David Abrahams" <abrahams_at_m...> wrote:
> > IMHO, it is natural to use both index styles in a single problem,
> 
> (!) How does /that/ situation come up?
A typical scenario is that you want to index n+1 increasing time
points as well as the n time intervals (or their lengths) bracketed
by these points. In some problem domains (e.g., financial option
pricing), it is natural to use 1-based indices for time periods
and 0-based indices for the time points.

> > and a good array library should support both styles.
> > A matrix library, however, can only and should at least support
> > the 1-based index, because matrix indices are 1-based in math.
> 
> Are you using some subtle semantic distinction between "array"
> and "matrix" here?
In terms of arrangement of quantities or symbols, a matrix is
always an array. However, a matrix is more than an array. An
array without supporting functions for matrix operations is not
qualified as a matrix. An array whose data type doesn't support
ring (oh, I mean a ring in abstract algebra) operations is not
qualified as a matrix. You might think this is a bias towards the
language of mathemeticians, but the term "matrix" was never (or
seldom) used in a way related to entity arrangement until
mathematicians first used it (around 1850, IIRC). "Matrix" is a
mathematical term.

In terms of operations, I just wonder to what extent do matrix
operations and operations for arrays in other domains overlap.
Since I don't know much about these "other domains" (perhaps 3D
graphics or multidimensional database???), I really don't know
if it's a good idea to design a multi-purpose super array (or
matrix, whatever) class and put all related (if not conflicting)
operations inside. Not distinguishing different concepts can
confuse users and scare them off.

> > Yet, even if the index convention problem is fixed, we still need
> > to solve the row-major/column-major problem ...
> 
> What problem is that? I thought row-major/column-major was just a
> distinction describing underlying storage format, and thus an
> implementation detail.
Sorry for my poor presentation. I simply meant that one has to
make a design decision on whether the i in A(i,j), for instance,
means the i-th row, the i-th column, or both (depending on the
storage format). This is not just an implementation detail because
it concerns whether expressions like
   (A*u)(1) = A(1,1)*u(1) + ... + A(1,n)*u(n)
are promised to be identities.

> > I hope the Boost folks can draw a line between vectors, matrices
> > and arrays in their matrix & array library.
> 
> What sort of line did you have in mind?
Uhh, I don't have one in mind, because I don't know how other people
use arrays. At any rate, it is essential to identify different
orthogonal concepts, and not to let the base array class (if any)
assume too much. If I just want to interface my old legacy array
architecture with the library functions (exchange two rows, slice,
... etc.), I don't want to define array element multiplication
just because the library assumes that my array is a matrix.

Cheers,
Hankel