Designing a Matrix class

[Charulatha Kalluri]

Hi,

I'm implementing a Matrix class, as part of a project. This is the interface
I've designed:

class Matrix( )

{

private:

vector< vector<int> > m_Data;
pair<int, int> m_size;
public:

Matrix(unsigned int n);
Matrix(unsigned int m, unsigned int n);

~Matrix();
............... ............... ......

}

I have a couple of questions:

1. Is there a better way to model the data structure other than a vector of
vectors? I realize I can write up the Matrix class from scratch, but I want
to use STL containers.

2. If I use a vector of vectors, how would dynamic memory allocation work? I
don't fully understand how STL's vector handles memory. For example, to
resize a matrix, how would I "delete" the memory for the old matrix? Would
the 'resize' and 'clear' functions guarantee proper memory management,
without leaks?

Thanks in advance!!

-CK

[E. Robert Tisdale]

Siemel Naran wrote:

Charulatha Kalluri wrote:

Also, I'm deriving Symmetric, Diagonal matrices, etc.
from the main Matrix class
and plan to have a 'minimize( )' function that uses up less memory.
But this would also involve
overloading almost all operators (arithmetic and otherwise).
Does this approach seem "natural",
or does the inheritance seem "forced"?
It seems forced to me because if Symmetric matrix inherits from Matrix,
it inherits all the functionality of the base class,
inculding its data structure.
Sure, you could modify the base class data structure in the derived class,
but there are easier ways if you are designing from scratch.

You can make class Matrix abstract.
It will just define an interface of pure virtual functions,
including a virtual destructor. For example

template <class T>
class Matrix {
public:
virtual ~Matrix();
virtual const T& operator()(size _type row, size_type col) const = 0;
virtual T& operator()(size _type row, size_type col) = 0;
};

The derived classes will be RegularMatrix, SymmetricMatrix , etc.

I'm not sure what applications Charulatha Kalluri has in mind.
Most C++ programmers avoid this approach
for high performance numerical computing
because, for example, neither

operator()(size _type, size_type) const or
operator()(size _type, size_type)

can be inline'd.

[Siemel Naran]

"E. Robert Tisdale" <E.************ **@jpl.nasa.gov > wrote in message

Siemel Naran wrote:

You can make class Matrix abstract.
It will just define an interface of pure virtual functions,
including a virtual destructor. For example

I'm not sure what applications Charulatha Kalluri has in mind.
Most C++ programmers avoid this approach
for high performance numerical computing
because, for example, neither

operator()(size _type, size_type) const or
operator()(size _type, size_type)

can be inline'd.

Good point. However, if one has numerical intensive functions like
FindEigenVector s or RotateMatrix, then one can write specialized functions
for each matrix type, possibly using templates

template <class SpecialMatrix>
void Rotate(SpecialM atrix&, double angle);

Then Rotate(Abstract Matrix&) calls one of the specialized functions. Not
saying this is the best approach or the worst, but it's at least something
to consider for our particular design.

[E. Robert Tisdale]

Siemel Naran wrote:

E. Robert Tisdale wrote:

Siemel Naran wrote:

You can make class Matrix abstract.
It will just define an interface of pure virtual functions,
including a virtual destructor. For example

I'm not sure what applications Charulatha Kalluri has in mind.
Most C++ programmers avoid this approach
for high performance numerical computing
because, for example, neither

operator()(size _type, size_type) const or
operator()(size _type, size_type)

can be inline'd.

Good point. However, if one has numerical intensive functions
like FindEigenVector s or RotateMatrix,
then one can write specialized functions
for each matrix type, possibly using templates

template <class SpecialMatrix>
void Rotate(SpecialM atrix&, double angle);

Then Rotate(Abstract Matrix&) calls one of the specialized functions.
Not saying this is the best approach or the worst,
but it's at least something to consider for our particular design.

Our particular design?

I'm sorry that I didn't notice that
both you an Charulatha Kalluri work for The MathWorks

http://www.mathworks.com/

I have written *lots* of MATLAB code.
For MATLAB programmers, the priority stack looks like this:

0. convenience
1. reliability
2. performance

For high performance numerical computing
this priority stack is inverted:
0. performance
1. reliability
2. convenience

MATLAB works best if programmers can confine themselves
to the heavy weight functions that MATLAB provides but,
if programmers need to implement their own algorithms
and access matrix elements individually,
they will need to write Fortran, C or C++ subprograms
and call them from MATLAB.

I'm not sure why you want to implement a C++ class library
if you already have MATLAB.
One of the problems with MATLAB is that
there is just one type -- a double precision matrix.
This feature simplifies small MATLAB programs
but it makes it very difficult to write large reliable programs.
For example, there is no way for MATLAB to determine
that a vector or scalar function argument is required
until run time.
If you are going to implement a C++ matrix class,
then I *strongly* suggest that you implement a vector class as well.

[Charulatha Kalluri]

Hello,

You can make class Matrix abstract.
It will just define an interface of pure virtual functions,
including a virtual destructor. For example

Thanks, this is what I've decided to do eventually.
I'm sorry that I didn't notice that
both you an Charulatha Kalluri work for The MathWorks

http://www.mathworks.com/
I'm not sure why you want to implement a C++ class library
if you already have MATLAB.
If you are going to implement a C++ matrix class,
then I *strongly* suggest that you implement a vector class as well.

Yes, I work there. However, this is a school project, not a work-related
one. The goal of the project is to demonstrate various OO concepts -
inheritance, STL, etc.. High performance is a plus, of course, but not the
main goal.

That said, thanks again for all your input :)