mikey@ontek.com (michael "krill-man" lee) (02/13/91)
In talk.bizarre, bhoughto@pima.intel.com (Blair P. Houghton) writes: | In article <1759@ontek.com> mikey@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!