What the user wants versus mathematics

"I want you to do A when the segments defined by xy lie fully to the left of zw. I want you to do B when xy overlaps zw on the left side. If xy CONTAINS zw, do C, if xy is inside of zw do d. If xy=zw do E. If xy overlaps zw on the right do F and if xy lies fully to the right of zw, do G".

Clear and obvious, right?

Actually, no. This little bit of prose has the capability to generate really terrible and buggy code.

For example, consider, if x is less than z and y is EQUAL TO w, then it seems ARBITRARY, almost, to consider this a "fully to the left of" situation.

In real number mathematics inside a continuous space, in fact, this would probably work. But if the space is comprised of cells (such as a series of hotel room blocks being compared to keep boys and girls from overlapping) then obviously the user MEANS by "fully to the left" something that has to do with SETS, such that "fully to the left" and fully to the right imply fully disjoint sets.

Whereas it would make perfect sense for the INFINITE sets contemplated by real analysis and topology to share a single common member and yet not overlap. This is because in real space, there is an intermediate relationship between "left overlap" and "to the left" and that is TANGENT. Two balls of gas are TANGENT when their set of common points contains one point.

Which brings up a fascinating possibility. The user hasn't specified what to do when the xy set of hotel rooms are "tangent" in a non-continuum. Perhaps at least one room should exist between the boys, and the Girls Gone Wild.

Integer "tangency" is UNLIKE real-number tangency. For two infinite continuums comprised of infinite sets of points, it appears that they must have two members in common: but "tangency" or "adjacency" for integer finite sets means instead that two and only two points have the adjacency relationship.

The user, who didn't think about adjacent elements, uses an implicit "calculus" consists of the relations left, left overlap, contains, is contained by, right overlap, and to the right and needs to be complexified, adding left tangent and right tangent for the situations that obtain when x=w and y>=w.

I've typically solved this problem by writing a simple method called interval which returns the relationship because the problem is just complicated enough to warrant encapsulation.

Solutions seem arbitrary, indeed governed by "what does the user want", as if mathematics were somehow subject to the whim of those with sufficient power and bad taste. But they are not because the language encapsulates set theory and the solution has to be consistent with the set relations of finite sets; otherwise, ambiguities (read:bugs) occur.

I get real tired of the anti-intellectual reaction to any attempt to just isolate this problem which is genuinely productive of a taxonomy the user can use, and isolates situations (such as Billy Bob hammering on the wall of the Girl Gone Wild) which the user may not have considered.

Therefore...here is the extempore code in bastardized C-like pseudo code:

relation(xy,zw)
assert x<y
assert z<w
if (y<z-1) return fully_to_the_left
if (y=z-1) return left_tangent
if (x<z && y<w) return left_overlap
if (x==z && y==w) return equals
if (x<=z && y >= w) return contains
// Recursion time!!!
select the case relation(zw, xy)
{
contains: return containedBy
left_overlap: return right_overlap
left_tangent: return right_tangent
left: return right
else: blargh
}

NOTES

1. In the test for left_overlap we MUST use y less than w because in left overlap and in right overlap, the sets must have at least one member not in common!!

2. The trickiest case may be the test for contains; it must follow that for equals, otherwise a complex Or would be needed to rule out equality.

3. Note how a simple, guaranteed to be one-level bounded recursion means that we can take it easy after solving the difficulties in equals and contains because whatever the user says, a calculus of intervals would treat the "right" relations as the complements of the "left" relations.

Of course, "recursion" is thought in many circles to be "difficult" and as a result is sometimes verboten, treated as an Eleusinian temple mystery, by adepts. Which is complete nonsense.

4. Blargh is my system's command for error out.

It appears to me that "requirements definition" typically misses such issues because of the emphasis, in "requirements definition", on a reified superficiality (sometimes known as "the big picture").

Entirely too often, former programmers, with an unexamined tendency to reify (to prematurely make something concrete out of something abstract), become "requirements" gatherers somewhat on the model of tax farming in the ancien regime of Bourbon France, where the tax farmer's mission was to gather as many poor and unwilling sods for corvee (road work) or payment in kind or in gold so as to be excused from corvee.

But in this buried psychic model, the "requirement" becomes a sort of thing to be extracted from the bush and beaten into submission. And, the more "requirements" the better even at the cost of self-contradiction, undetected because of the size of the whacking great book of Ten Thousand requirements.

According to an article in Enterprise Systems Journal for May 1999, the state and commonwealth of Virginia went down this road. For five weary years, its MIS people gathered requirements for input into a Peoplesoft system for human foibles management...only to create something which did not work.

Then, a small group of Web programmers gave the Rebs down in Virginia what they needed by new coding innocent of the "reusable" Peoplesoft code, which was completely oriented around client-server, outdated after the five weary years.

Peoplesoft has boasted that there is no inappropriate client-side code in its product of the sort the ordinary Visual Basic programmer encounters, typically, the SELECT Statement from Hell which is continued over several lines and which ties up the network (thanks to Sunil for beating my tendency to code these babies out of me years ago).

The problem was that it had solved a problem on a somewhat out of date platform.

It is a mistake to rush prematurely into code. A mistake of equal gravity is to so postpone code that the insights of intelligent PROGRAMMING (such as the possibility that two sets will be tangent) are lost, and worse, to view PROGRAMMERS as such low-level clerkish dull fellows as to have no insight of any note.

I have met many professionals in medicine and the law, and I have met many entrepreneurs who express amazement at my belief that programming has any intellectual content whatsoever.

When the Venetian artist Paolo Veronese was hauled before the Venetian Inquisition, that charming and most Catholic board which investigated belief and hounded the Jews, for including clowns and Germans in a representation of our Savior's Last Supper, he was roundly condemned not only for painting clowns and Germans but also for believing himself an independent professional able to so depart from the cardinal's requirements as to think that buffoons and Krauts were appropriate in setting the tone.

Which is to say that a profession doesn't pre-exist. It is formed by struggle to be a professional.