Two Specifications of Tabulated Equations

The input must be a sentence derived from the non-terminal productions of grammar given below. Note that (a) an equation can span multiple lines, and (b) terms of the same variable may occur multiply either in the rhs or in the lhs or both.

eqns ::= eqn ',' eqn  '.'
eqn ::= lhs '=' rhs
lhs ::= exp
rhs ::= exp
exp ::= term | term '+' exp
term ::= number | coeff varid
coeff ::= empty | ['+'] number
varid ::= letter

(Requirements Analysis: It is not clear if long equations are presented on multiple lines in the input. We will de facto allow it as our grammar/parser of input takes care of it. If our client insists that that should not be permitted, our task becomes more complex. The required grammar is no longer context-free. )

[Other than using some kind of grammar, I know of no way to describe this precondition. Syntax diagrams etc. are, of course, other ways of specifying context-free grammars.]

[Why should we let coeff begin with an optional plus? Is the grammar "unambiguous"? What does unambiguous mean in this context? The same as in an "unambiguous specification"? If duplicate-var-id terms are not to be permitted in an equation, why does the required grammar become more complex? For that matter, are PLs context-free?]

[Item 3 was easier to do than item 2. So we do that next.]

The output is also a sentence derivable from {\bnf eqns}. The \(i\)-th equation of the input is {\sl semantically equivalent} to the \(i\)-th equation of output. Two equations \(e_1 = e_2\) and \(e_3 = e_4\) are equivalent if \(e_1\) is equivalent to \(e_3\), and \(e_2\) is equivalent to \(e_4\). An expression \(e\) is equivalent to \(f\) if both \(e\) and \(f\) have the same terms, same number times in each. Note that permutations of terms is allowed. Simplification of terms is not even attempted.

(Requirements Analysis: Since we impressed our customer by remarking that we will imagine the paper width to be infinity, we choose to output each equation as one line, regardless of its length.)

Let n be the number of lines in the output.

The output consists of equations printed one per line. The order of the equations is the same as that of input.

To describe the formatting of the output, imagine dividing the 2-d output into columns of rows as follows. Draw vertical straight-lines, from the topmost line to the bottom-most spanning the n lines of output, immediately surrounding each variable id letter, each '+' and the '=' . Similarly draw a line to the immediate right of each number, and one straight line at the leftmost edge of the output.

The first (i.e., the leftmost) column must be a number-column. Each row in a column of numbers must be either a string of blanks, or a right-justified number.

Each row of the equals-column must contain " = ". Each row of each plus-column must contain either a " + " or three blanks. All the rows of a variable id column must be either one blank or contain some letter, and all these letters must be the same.

Should we also say "no column is all blanks". I think not; what say you? What about "The first (i.e., the leftmost) column is a number-column"?

1. Imagine [better yet: You write it!] a predicate parses-ok(G, N, s) that yields true iff the string s is a sentence derivable from the non-terminal N in the grammar G.
2. Input must be a well-formed sentence of G: parses-ok(G, eqns, input).
3. Let us call the required program as TE. Its signature is: function TE(fi: seq of eqn) returns fo: seq of line where eqn is a sentence generated by the non-terminal eqn of the grammar above.
4. [The auxiliary function that obtains the fi and fo sequences from their derivation trees is left as an exercise to you. Note that while the commas and the period in the input are helpful in parsing, the fi sequence does not contain them; but the fo does.]

1. Two equations e: e₁ = e₂ and e': e₃ = e₄ are semantically equivalent, semantically-eq(e, e'), if
   1. bag-of-terms(e₁) = bag-of-terms(e₃), and
   2. bag-of-terms(e₂) = bag-of-terms(e₄).
2. semantically-equal-eqns(input, output) is-defined-as
   1. ∀ i: 1..n (
      1. parses-ok(G, eqn, fo[i]) and
      2. semantically-eq(fi[i], fo[i]) ).
3. [Note that in parses-ok(G, eqn, fo[i]), it is fo and not fi. Why? What is the signature of semantically-eq? Is it ok to write semantically-eq(fi[i], fo[i])?]

1. output is-defined-as tabulateeqns( input ),
   1. where tabulateeqns(input) is-defined-as TE(convert-to-eqn-seq(input))
2. [convert-to-eqn-seq(input) is a companion to parses-ok.]
3. This output is such that
   1. semantically-equal-eqns(input, output) and
   2. ∃ c: nat ( looks-good(output, \#q, c) ).

The following are some imagined questions from students.

{\sl If we have some 40 minutes to spend on this problem, do you expect us to finish it this well?}

{Well, if you want an A, yes! More seriously, an answer along the lines of Section 2 is certainly expected. Section 3 is home work that you should be able to do a good draft in a few, say 4, hours. Such a draft probably contains errors. It is best to let others read it. If that is not possible, read it yourself, but after a day or two.}

{\sl Is it worth spending this much effort in specifying instead of producing a couple of hundred lines of code?}

{I think so. There are no statistics that can validate or invalidate this belief. Assuming that the program being developed is not a throw-away program, but has a long lifetime, the careful translation of requirements to specs and then paraphrasing them back to the user/client is an effective technique to prevent expensive design and coding errors.}