CSCI 1321 (Principles of Algorithm Design II), Spring 2001:
Homework 41

Assigned:
February 23, 2001.

Due:
March 2, 2001, at 5pm.

Credit:
20 points.


Contents

Problem statement

You are to implement a class for mathematical vectors, as (briefly) discussed in class. In mathematics, a vector is an n-tuple of real numbers, which we could write as (x1...xn). n is called the length of the vector. Many operations are defined on vectors, including the following.

The objective in this assignment is to define a C++ class MVector to represent mathematical vectors. Program mvector-use.cpp illustrates the intended use of the class. Our strategy for implementing MVector is to represent a mathematical vector by a C++ STL vector of doubles. We will need to write functions to support the following operations on MVector objects (using syntax as illustrated in mvector-use.cpp).

We also need to define a type size_type, to be used to represent the size (number of elements) of an MVector and indices of its elements. (Yes, we could just use int, but defining a new type makes it clearer that values of this type are sizes or indices, and it allows us to be more compatible with the STL vector class, which also defines such a type.)

Details

mvector.h contains a partial definition of the MVector class; your mission is to complete this class definition. Comments in the code (ADD SOMETHING HERE) indicate what you need to implement. Note the following:

What files do I need?

There is one essential file and one recommended file.

To test your MVector class definition, you will need a C++ program (a .cpp file) containing a main function definition and an #include "mvector.h". mvector-use.cpp is an example of such a program; you may modify it or write your own program. Compile the .cpp file containing the main program; for example,
g++ -Wall -pedantic mvector-use.cpp -o mvector-use
Remember to put file mvector.h in the same directory as the .cpp file you are compiling.

Testing

You are encouraged to test your code thoroughly with the example-use program (mvector-use.cpp), extended with additional tests. As currently written, this program will not compile unless you implement all the desired MVector functions. If you want to implement and test functions a few at a time, you can do so by commenting out the parts of mvector-use.cpp that test functions you have not yet implemented.

What to submit and how

Submit your source code as described in the Guidelines for Programming Assignments. For this assignment, use a subject header of ``cs1321 hw4'', and submit a single file containing your revised version of mvector.h. You do not need to send mvector-use.cpp; I will provide a more thorough test program when I test your code.

Programming tip/rant

It is often reasonable and convenient to write functions in which ``sane'' assumptions are made about function inputs; for example, in the unary-numbers class of Homework 2, we assumed that the natural passed to sub1() would not be zero. If such assumptions are made, they should be documented in comments preceding the function. Whether to check that the actual values passed to the function meet the precondition (and what to do if they don't) is at least in part a matter of programming style. For preconditions that should be checked in a calling program (but might not be, if the programmer writing the calling program is careless), I like to use the assert() function (#include <assert.h>) to double-check. assert(boolean_expression) tests boolean_expression; if it is false, the program halts with an error message pointing to the call to assert(). Here is a throw-away program illustrating use of assert():


    #include <iostream.h>
    #include <assert.h>
    int main(void) {
      assert(false);
      return 0;
    }
When compiled and executed on a Linux system, the program produces the following output:
qq: qq.cc:4: int main(): Assertion `false' failed.
Aborted (core dumped)
mvector.h contains additional examples of using this function.

Notice that while the error messages produced by assert() can be very helpful to a programmer (either the person who originally wrote the code, or another programmer using it), they are less likely to be useful to end users of application programs. Therefore, I recommend using assert() to check for things that ``should not happen'' (e.g., calling functions with parameters that don't meet the preconditions) rather than for potential user errors (e.g., the program expects the user to supply file SomeFile, but no such file can be found). For end-user errors, I prefer to print a message that would be meaningful to the user and bail out of the program as gracefully as possible.

For this assignment, the directions for several functions indicate that you can make assumptions about the parameters (e.g., ``+'' is applied only to vectors of the same length). You are not required to check that the actual parameters satisfy these assumptions, but you may if you wish. assert() might be a nice way of doing this.



Footnotes

... 41
© 2001 Jeffrey D. Oldham and Berna L. Massingill. All rights reserved. This document may not be redistributed in any form without the express permission of at least one of the authors.


Berna Massingill
2001-02-23