The Science of Programming/Constant Worries

So far, our polynomials contain only a single term, such as: This is rather restrictive. For example, the equation of a line: can be considered a polynomial whose term has power of one plus an added constant, b. In other words: How do we deal with the constant? We could modify our term constructor to take a third argument, a constant. In this case, we would model the line: as: term(3,1,-5) While this would work, the approach is going to make things complicated when we start to model polynomials that are composed of multiple terms. Consider: This polynomial could be represented by the following terms: term(4,4,0) term(-2,3,0) term(5,2,0) term(1,1,-3) with the first three terms having zero as a constant. Alternatively, we could represent the polynomial this way instead: term(4,4,1) term(-2,3,2) term(5,2,3) term(1,1,-9) Now every term has a constant (note all the constants add up to -3 as they should). You should see two problems now with adding a third argument to term. The first is most terms don't have (or shouldn't have) a constant. The second is it is unclear which term, in a collection of terms, should hold the constant. Before I give you a better way, I'm going to tell you a story first. A friend of mine had a brother (or cousin or whatever, I don't remember which) who, lacking a crowbar, used a Craftsman screwdriver to pry some rather heavy and rather stuck piece of machinery out of its housing. The piece refused to budge so the brother (or cousin or whatever) put his full weight on the screwdriver, which promptly bent. Now you may not know this, but a screwdriver that is bent is nearly useless for doing things a screwdriver normally does (like screwing or unscrewing screws). As it happens, Crafstman hand tools had a lifetime warranty, so the brother (or cousin or whatever) took the bent screwdriver back to Sears and asked for a replacement. The clerk happily obtained a new screwdriver and remarked, as she exchanged screwdrivers, "You know, Sears sells Craftsman crowbars as well". What is the moral of the story? It is, of course, Use the right tool for the right job. Sometimes, Computer Scientists ignore this rule, preferring an alternate the moral of the story: Next time, use a bigger screwdriver. This is because Computer Scientists (again with the laziness) don't want to write something from scratch (a crowbar), but would rather use something else that has already been written and can be adapted for the job at hand (the screwdriver). Sometimes, this works nicely, but sometimes it leads to added complications down the road. In this particular case, a constant c could be represented as a term with coefficient c and exponent zero. Instead, we will design our second kind of object in our calculus system. We need a new tool to represent constants. Constant Objects You are probably asking, what's the big deal with constants anyway? Why can't we just use numbers? We could, but consider this exchange: sway> var s = t . diff(); OBJECT: <OBJECT 4369> Suppose t is bound to a term object. Then all is well and good; s is bound to a term object as well. But suppose t is bound instead to the number eight. We get a much nastier response from the terminal: sway> var s = t . diff(); EVALUATION ERROR: :accessError dot operator used on type INTEGER We tried to treat the number eight as an object, which it is not. Since numbers are valid mathematical entities and since it is sensible to take the differential of a number, we are left with two choices: Every time we wish to take the differential or find a value or visualize, we need to test to see if the entity we are dealing with is an object or not. Make sure numbers are objects with diff, value, and toString methods. The first choice means every bit of code we write in the future has to take into account that we have two kinds of things to deal with and we best not forget it. The second choice means spending a little time up front, but never worrying multiple kinds of entities again. Clearly the second choice is the way to go. Before we write our constructor for representing constants, we need to ask ourselves three things: What is the value of a constant at a particular point? What is the derivative of a constant? What is a reasonable string representation of a constant? These three things correspond to the three methods all of our constructors must have. The first of these questions seems to be a bit strange. The value function for a term computed a value of the term given a value of x. As x varies, the value of the term varies as well. But for a constant, there is does not seem to be an x. This is not exactly true, since there is an equation where the value of y remains constant regardless of the value of x. An example is the equation We can plot that equation: Image:ch05-figure01.png and we see that, regardless of the value of x, the value of y remains constant. Thus, the value method of a constant object should ignore the given value of x and return its constant value: function constant(n) { function value(x) { n; } this; } Note how the value method always returns n: sway> var c = constant(5); sway> c . value(0); INTEGER: 5 sway> c . value(3); INTEGER: 5 Moving on, what is the differential of a constant? In other words, how does the value of our object change as the value of x is changed. We see from the interaction above that the value doesn't change at all. In other words the change is zero. You might, therefore be tempted to write the diff method for a constant object as: function diff() { 0; //incorrect } This would be incorrect, however, since all diff methods must return objects that have diff methods themselves. We saw that with terms: the diff method of a term object returns a term object, which has a diff method as desired. For the task at hand, what object should be used to represent the number zero? A constant object! function constant(n) { function value(x) { n; } function diff() { constant(0); } this; } Our final question to answer is how do we visualize a constant? That is easy to answer: we simply convert the number into a string. We are left with our complete constant constructor: function constant(n) { function value(x) { n; } function diff() { constant(0); } function toString() { "" + n; } this; } Using Constant Objects That was quite a detour! Remember, we are trying to model a line using therm and constants. The line: can be represented by two objects: term(m,1) constant(b) What happens when we add them together? sway> var m = 3; sway> var b = -5; sway> term(m,1) + constant(b); EVALUATION ERROR: :argumentTypeError addition: cannot add type OBJECT to type OBJECT What we need now is a way to glue these two objects together. Clear Let's test it out. Recall our term constructor: function term(a,n) { function value(x) { a * (x ^ n); } this; } Let's create a constant with value 7 and see if indeed the resulting value of the term is constant regardless of the value of x. var c = term(7,0); sway> c . value(10); INTEGER: 7 sway> c . value(1000); INTEGER: 7 Confirmed. Questions All formulas are written using Grammar School Precedence. 1. Use Sway to represent the individual terms of the following polynomial . What is the value of this polynomial for . 2. Use Sway to represent the individual terms of the following polynomial . What is the value of this polynomial for . 3. Infant mortality is inversely proportional to income level. What is the relative growing of infant mortality with income level? Footnotes The Simplest Things Guzzintas and other Cipherin'