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

[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

[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

[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

[Siemel Naran]

"Charulatha Kalluri" <ck******@mathworks.com> wrote in message news:csfdc0

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();

There's no need to write a copy constructor, operator=, or destructor as the
compiler generated one will suffice.

But I'd opt for one private member variable std::vector<int> m_Data that
would store the data by rows or columns. I find that on my implementation
(Windows or Linux on PCs, g++ or Borland or other compilers) you get faster
performance because memory allocation is faster. Then you'd implement
operator() like this

int Matrix::operator()(int row, int col) const {
return m_Data[row*numcols+col];
}

You can also easily write row and column iterators that don't do the
arithmetic, so will be very fast.

[matthias_k]

Charulatha Kalluri wrote:

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

First of all, you should make your Matrix class a template. Often
enough, you don't want matrices of integral values, but of double or
boolean.

Second, I can't see that part of the interface which gets you access to
the matrix data. You should implement operator[][] for example.

Third, I would consider not to hold a vector< vector<T> >, but separate
vectors, one for rows, one for columns (I think that was already said).
I can tell from my personal experience because I am currently
implementing a solver for linear optimization problems for a math
project at the university, and I found it most annoying to work with
vectors of vectors of T as matrix representations, because you can only
get the data in form of rows or values. However, by-column access is
needed quite often. I wish I would have known from the beginning.

As to the memory thing, I think std::vector<T> handles it as follows:
It will acquire space for several entries on construction (how much by
default is implementation defined I think, but you can explicitly pass
an initial size on construction). Now each time the vecor becomes too
small, it will -again- allocate as much space as it did on construction.
This makes sure the vector won't resize with each and every insertion.
In your case, size m for the row vector and size n for the column vector
seem to make sense (consider though, is it appropriate to resize a
matrix which was constructed as mxn? I don't think so. You would rather
discard it and create a new m'xn' matrix).

Just my 2 euro cents.

[Dave Moore]

"Charulatha Kalluri" <ck******@mathworks.com> wrote in message
news:cs**********@fred.mathworks.com...

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.

Yes, in fact a vector of vectors is a very bad way to implement a Matrix (at
least a mathematical one), because there is nothing that says the internal
vectors all have to be the same length.

The way to do it is to use a vector<T>, or perhaps a valarray<T> to provide
the internal representation of your data. You then have to build various
ways to view the data, keeping in mind the appropriate striding for the
matrix. There are tons of references about how to do this on the web .. try
a google search. A couple that I found useful in the past are:
Object oriented numerics: http://www.oonumerics.org/oon/
and the POOMA library: http://acts.nersc.gov/pooma/

Also, in chapter 22 of TC++PL 3rd ed., Stroustrup shows an example of how to
implement a Matrix using a std::valarray, along with some associated STL
helper classes for building different kinds of views. For me, the
non-aliasing restrictions placed on std::valarray were too strict, and I
ended up rolling my own using std::vector as an exercise, but the general
approach and examples he laid out were certainly useful.

HTH,

Dave Moore

[E. Robert Tisdale]

Charulatha Kalluri wrote:

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();
....................................

} g++ -Wall -ansi -pedantic -c Matrix.cc Matrix.cc:1: error: expected unqualified-id before ')' token
Matrix.cc:3: error: expected `,' or `;' before '{' token

It doesn't even compile.
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.
Have you considered valarray?
Bjarne Stroustrup, "The C++ Programming Language: Third Edition",
Chapter 22: Numerics, Section 4: Vector Arithmetic,
Subsection 6: Slice_array, page 672.
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?

Take a look at
The C++ Scalar, Vector, Matrix and Tensor class Library

http://www.netwood.net/~edwin/svmtl/

then take a look at
The Object-Oriented Numerics Page

http://www.oonumerics.org/oon/

[Charulatha Kalluri]

This is great - thanks for the responses!!

I've decided to go with a vector<T>, rather than valarray. (I don't have the
Stroustroup book, and there are time constraints on the project)

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"?

Thanks in advance
--CK

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:cs**********@nntp1.jpl.nasa.gov...

Charulatha Kalluri wrote:

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();
....................................

}

> g++ -Wall -ansi -pedantic -c Matrix.cc

Matrix.cc:1: error: expected unqualified-id before ')' token
Matrix.cc:3: error: expected `,' or `;' before '{' token

It doesn't even compile.

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.

Have you considered valarray?
Bjarne Stroustrup, "The C++ Programming Language: Third Edition",
Chapter 22: Numerics, Section 4: Vector Arithmetic,
Subsection 6: Slice_array, page 672.

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?

Take a look at
The C++ Scalar, Vector, Matrix and Tensor class Library

http://www.netwood.net/~edwin/svmtl/

then take a look at
The Object-Oriented Numerics Page

http://www.oonumerics.org/oon/

[Siemel Naran]

"Charulatha Kalluri" <ck******@mathworks.com> wrote in message
news:csjfjt$bb8

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.

[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
FindEigenVectors or RotateMatrix, then one can write specialized functions
for each matrix type, possibly using templates

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

Then Rotate(AbstractMatrix&) 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 FindEigenVectors or RotateMatrix,
then one can write specialized functions
for each matrix type, possibly using templates

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

Then Rotate(AbstractMatrix&) 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 :)