• No results found

The Polynomial Data Structure

Programming Projects 4

3. Stubs and Testing

4.5.3 The Polynomial Data Structure

Let us now turn to our principal task by deciding how to represent polynomials and writing methods to manipulate them. If we carefully consider a polynomial such as

3x5 2x3 +x2 +4

we see that the important information about the polynomial is contained in the coefficients and exponents ofx; the variablexitself is really just a place holder (a dummy variable). Hence, for purposes of calculation, we may think of a polyno- essence of a

Section 4.5 Application: Polynomial Arithmetic

145

computer, we could similarly represent a polynomial as alistof pairs of coefficients and exponents. Each of these pairs constitutes a structure that we shall call aTerm. We implement aTermas astructwith a constructor:

structTerm{

Term intdegree;

doublecoefficient;

Term (intexponent = 0, doublescalar = 0); };

Term::Term(intexponent, doublescalar)

/*Post: The Term is initialized with the given coefficient and exponent, or with default parameter values of 0.*/

{

degree = exponent;

coefficient = scalar; }

A polynomial is represented as a list of terms. We must then build into our meth- ods rules for performing arithmetic on two such lists. When we do this work, however, we find that we continually need to remove the first entry from the list, and we find that we need to insert new entries only at the end of the list. In other words, we find that the arithmetic operations treat the list as a queue, or, more precisely, as anextended queue, since we frequently need methods such asclearand

serve_and_retrieve, as well as deletion from the front and insertion at the rear. Should we use a contiguous or a linked queue? If, in advance, we know a bound on the degree of the polynomials that can occur and if the polynomials that implementation of a

polynomial occur have nonzero coefficients in almost all their possible terms, then we should probably do better with contiguous queues. But if we do not know a bound on the degree, or if polynomials with only a few nonzero terms are likely to appear, then we shall find linked storage preferable. Let us in fact decide to represent a polynomial as an extended linked queue ofterms. This representation is illustrated in Figure 4.15. 109 1.0 3.0 5.0 –2.0 1.0 4.0 x4 5 0 3x52x3+x2+4 4 0 5 3 2 0

Each node contains one term of a polynomial, and we shall keep only nonzero assumptions

terms in the queue. The polynomial that is always 0 (that is, it consists of only a 0 term) will be represented by an empty queue. We call this thezero polynomialor say that it isidentically 0.

Our decisions about thePolynomialdata structure suggest that we might im- plement it as a classderivedfrom an extended queue. This will allow us to reuse methods forExtended_queueoperations, and we can concentrate on coding just those additional methods that are special to polynomials.

As a final check before going ahead with such a derived class implementation, we should ask: Is aPolynomialanExtended_queue?

AnExtended_queueallows methods such asservethat do not apply directly to

polynomials, so we must admit that aPolynomialis not really anExtended_queue. (In coding an implementation this drawback would become clear if we tried to prevent clients from serving entries fromPolynomial objects.) Thus, although it would be useful to reuse the data members and function code from theclassEx-

tended_queue in implementing ourclass Polynomial, we should reject a simple

inheritance implementation because the two classes do not exhibit an is-a relation- ship (seepage 83).

The C++ language provides a second form of inheritance, calledprivate inher-

private inheritance

itance, which is exactly what we need. Private inheritance models an “is imple- mented in terms of” relationship between classes. We shall therefore define theclass

Polynomialto be privately inherited from theclassExtended_queue. This means

thatExtended_queuemembers and methods are available in the implementation

of the classPolynomial, but they are not available to clients using aPolynomial. classPolynomial: privateExtended_queue{ // Use private inheritance.

Polynomial public:

voidread( ); voidprint( )const;

voidequals_sum(Polynomial p,Polynomial q);

voidequals_difference(Polynomial p,Polynomial q);

voidequals_product(Polynomial p,Polynomial q);

Error_code equals_quotient(Polynomial p,Polynomial q);

intdegree( )const; private:

voidmult_term(Polynomial p,Term t);

};

We have incorporated a useful method, Polynomial::degree( ), that returns the degree of the leading term in aPolynomial, together with an auxiliary function that multiplies aPolynomialby a singleTerm.

We have not yet considered the order of storing the terms of the polynomial. If we allow them to be stored in any order, then it might be difficult to recognize that

Section 4.5 Application: Polynomial Arithmetic

147

all represent the same polynomial. Hence we adopt the usual convention that the restriction

terms of every polynomial are stored in the order of decreasing exponent within the linked queue. We further assume that no two terms have the same exponent and that no term has a zero coefficient. (Recall that the polynomial that is identically 0 is represented as an empty queue.)