<!–Converted with LaTeX2HTML 2022 (Released January 1, 2022) –> <HTML lang="en"> <HEAD> <TITLE>Contents of What is the Problem?</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8"> <META NAME="viewport" CONTENT="width=device-width, initial-scale=1.0"> <META NAME="Generator" CONTENT="LaTeX2HTML v2022">
<LINK REL="STYLESHEET" HREF="docu.css">
<LINK REL="next" HREF="node4_mn.html"> <LINK REL="previous" HREF="node2_mn.html"> <LINK REL="up" HREF="node2_mn.html"> <LINK REL="next" HREF="node4_mn.html"> </HEAD>
<BODY bgcolor="#ffffff" text="#000000" link="#9944EE" vlink="#0000ff" alink="#00ff00">
<H1><A ID="SECTION00210000000000000000"> What is the Problem?</A> </H1> I wrote this code to solve some of my matrix algebra problems for my research. I needed a generic program that could handle matrix algebra on a PC, for instance <P><!– MATH
<P> <PRE> VMatrix b,X,Y; // code to read in X and Y . . . b = Inv(Tran(X)*X)*Tran(X)*Y; </PRE>
<P> where b, X, and Y are matrices. This not quite as powerful as some matrix interpreters, but it works. C++ is powerful enough for this problem since it can overload functions for objects. It also flexible enough to handle the recursive and nested function calls needed for matrix algebra.
<P> The next problem was to minimize the overhead of manipulating the data structures required for keeping track of all of the matrices. The ability to bind functions to data structures using objects solved this problem. It was reasonably easy to write a stack of matrices to keep track of the intermediate calculations, and then delete the unnecessary matrices. It also made it reasonably easy to assign matrices using the equals operator.
<P> The next problem was the 640K barrier on the PC class machines. Most of my problems are too big to keep all of the data in RAM, so I have to resort to special data IO tricks. This is fine for any single problem, but it does not generalize very well. I found a virtual memory allocator to solve this problem. It writes to a disk file. The new class of 386 machines can keep RAM disks in extended memory, so there is only a modest performance penalty for accessing the data in electronic memory. The virtual memory scheme only keeps about 64 elements in RAM, so finding elements in a large matrix is slower than direct access to the heap. This tradeoff suited me since I would rather be able to use matrices that are potentially larger than 640K. A 3 or 4 meg RAM disk would suit most of my needs. The hard drive can be used too. Again, it ain't fast, but it works.
<P> The properties of C++ helped solve these problems. This document will develop a matrix class from lower level functions. The first step is to explain the virtual memory allocator. The next step is to explain the string functions. The third step is to develop a vector class based on the virtual memory allocator. The next step is to explain the matrix class and matrix stack classes. The virtual vector class is the base class for the matrix class. The matrix stack is derived from the matrix class. Developing a general matrix program is hard without encapsulation and inheritance.
<P>
<HR>
</BODY> </HTML>