Arithmetic on large integers can be done by storing an integer in an array, in binary notation. So each member of the array is either 0 or 1. Functions can be written to perform operations such as addition, subtraction and multiplication.
Write an implementation of addition and multiplication of nonnegative integers, stored in binary, in C++. Make your functions have the following contracts and prototypes.
// sum(A,m,B,n,C,k) stores the sum of integers A and B*2k // into array C. // // All integers are stored in binary as arrays of bits, with the least // significant bit stored at index 0. // // Array A has length m. // Array B has length n. // // k must be a nonnegative integer. It is the amount that B is // shifted by before adding. // // Array C must have at least max(m,n+k) + 1 // cells available. Those cells are set to hold the // binary sum of A and B*2k. // // It is allowed for arrays C and A to be the same array, or // for C to be a different array. When C and A are the same // array, the sum of A and B*2k is put into array A, // clobbering the former contents of A. void sum(BIT A[], int m, BIT B[], int n, BIT C[], int k); // product(A,m,B,n,C) stores the product of integers A and B into // array C. // // All integers are stored in binary as arrays of bits, with the least // significant bit stored at index 0. // // Array A has length m. // Array B has length n. // // Array C must have at least m+n cells available. Those // bits are set to the product of A and B. // // Arrays A, B and C must be different arrays for this function. void product(BIT A[], int m, BIT B[], int n, BIT C[]);For type BIT, use int. So you should write
typedef int BIT;
You are not asked to write a complete application here. Only two functions are to be provided. They are for use in other programs. I will test them by using them in another program.
Your functions should meet the following requirements. (And yes, I will grade down for failure to meet these requirements, even if you have not been asked to meet such stringent requirements in the past.)
Your functions must have exactly the prototypes shown. If they do not, they will not link with my tester.
Your functions must not make any assumptions about how large the arrays are, other than those explicitly stated in the contracts. For example, it is unacceptable to assume that the numbers have no more than 100 bits in them. It must be possible to compile your functions and put them into a library, and find that they can be used for arbitrarily large integers without recompiling them.
Your functions must not have requirements that are not stated in the contracts. For example, it is unacceptable to insist that array C be set to all zeros by the caller before calling sum or product, since the contract does not say anything about that.
Your functions must not have any visible actions not stated in the contracts. For example, the contracts do not indicate that anything is being read or written, so nothing should be read or written. (Don't use cin or cout, for example.) The contract for multiplication does not state that arrays A and B are changed, so don't change them.
Your functions must implement something close to the standard addition and multiplication algorithms. It is not acceptable, for example, to add x and y by starting at x and doing y increments. That is extremely slow. Similarly, it is not acceptable to multiply x and y by adding y to itself x times. That is also too slow.
The multiplication algorithm that you learned in grade shool has you write down all of the intermediate products before adding them all up. It is not necessary to do that. Just accumulate the sum as you generate each intermediate product. Be sure to shift over an appropriate amount. (Shifting is the same as multiplying by a power of 2.)
The multiplication function should call the addition function to perform the additions. The addition function must not call the multiplication function. There is no need. Shifting is just a matter of how you manage your array index counters.
Strive for simplicity and elegance in your program.
Comment your program well. Make it clear and readable. Literate programming is a form of programming where programs are written in a way that is intended to be read, as a textbook would be read. Get as close to literate programming as you can. Write your program for other people to read.
If you feel that these requirements are impossible to meet, or you do not see how to meet them, ask for help.
Test your functions. In order to do the testing, you will want a function that prints a binary number. That is not part of the assignment, and should not be turned in, but software designers often find that they need to write extra functions to aid in testing.
IF YOU DO NOT TEST YOUR FUNCTIONS, YOU CAN REST ASSURED THAT THEY DO NOT WORK, AND THEY WILL FARE POORLY WHEN GRADED.
Here are some recommended tests. You would be well advised to do others as well. All numbers are in standard binary notation (high order bit first). You might get leading zeros, which you can ignore. For example, you might find that the sum of 1 and 1 is 010. (x means times.)
An easy way to do these tests is just to initialize some arrays in your program. For example, write
BIT A3[] = {1,0,0,1,0,1};
BIT B3[] = {0,0,1,1,1,1,1,0,1};
to initialize arrays A3 and B3 to the binary numbers 101001 and
101111100, respectively. Notice that the numbers are written
in the arrays with the least significant bit first.
Turn in your program using the handin program. Put your functions in one file. If your file is called arithmetic.cc, then hand it in using the following command on the Unix machines in Austin 320.
/export/stu/classes/csci3675/bin/handin csci3675 1 arithmetic.cc