short, shameful confession

[michael "krill-man" lee]

In talk.bizarre, bhoughto at pima.intel.com (Blair P. Houghton) writes:
| In article <1759 at ontek.com> mikey at ontek.com (michael "krill-man" lee) writes:
| >#define and     &&
| >#define or      ||
| 
| Well, this wouldn't be so bad, except that the real meaning
| of && isn't "if the preceding and the following are both
| true," it's "do the following iff the preceeding was true
| and iff the following is true evaluate to true otherwise
| evaluate to false," and the real meaning of || isn't "if
| either of the preceding or the following are true", it's
| "do the following iff the preceding was false and iff the
| following is true evaluate to true otherwise evaluate to
| false."

I'll take a chance and respond to this somewhat seriously, for a
change.  Computer geeks may find this to be an amusing anecdote.

About three years ago, I wrote a query function for a network[1]
database.  The user interface was a strictly query-by-example sort of
thing, with the added twist that giving extra fields horizontally meant
union, while adding fields vertically meant intersection.  Putting
"not" in a field meant set complement.

The funnest part of writing the program was the part that actually went
out and did the search.  It implemented a fairly complete relational
algebra, with lots of extra code to take advantage of the links in a
network database and any indexes[2] that happened to be hanging around.

During the whole time I was writing this, about every thirty seconds or
so the thought would pop into my head about the similarity of the
Boolean logic operators (and/or/not) and the Boolean set operators
(intersection/union/complement).  It got to be quite annoying that
every time I typed the word "and" in my program, my head would fill
with the complete text of the "intersection" function I was writing.

At some point, it finally dawned on me[3] that I could do a little
optimization by evaluating the operands *out of order*.  I added a bit
of code that did some rough guessing[4] as to which side of the
operator was likely to result in the smallest number of matching
records, looked up those first, then checked each record for matching
against the other side of the expression.   A similar, but less useful
optimization could be had with the union operator, in the odd case that
one side of the expression happened to match nearly everything.

I think my point is:  If there were some way to know whether the
expressions used as operands to && and || were pure and free of side
effects, an extra measure of optimization might be attainable by an
inspired compiler.

      the krill, delusions of utility

--
1. Network as opposed to relational or hierarchical, not network
   as opposed to local.
2. for (i=0; i++; i<100) printf("I will not use the word \"indices.\"");
3. Just as it has dawned on nearly everyone else who has ever written
   any sort of database query code...
4. I lied.  Writing the part that did the "rough guessing" was the
   funnest part.
5. Put the words "CARASSO" and "RDC" into your .signature today!