[std-interval] Comparisons

[George Corliss]

Sylvain,

>> I've been asked to teach a database class for the first time in my career,
>> so I am reading about SQL (Structured Query Language).  Interestingly, SQL
>> uses a three-valued logic with values TRUE, FALSE, and UNKNOWN.
>> 
>> The rationale seems to be
>>    1. Fields in a database often have values NULL
>>    2. Comparisons with NULL yield UNKNOWN
>>    3. Need "Boolean" operators on results of comparisons
>> 
>> The analogy with intervals is not perfect, but it is informative.  Since
>> databases are more widely used than intervals, their standards have endured
>> severe scrutiny and extensive practical applications.  We may have something
>> to learn.
> 
> Thanks for the information, George.  It's good to see that
> the SQL semantic is covered by our bool_set proposal.  It
> makes one more motivation to standardize something like this.
> 
> I would be curious about the details, though.  What happens
> if you do "if(UNKNOWN)" (or the equivalent in SQL, if there
> is an equivalent) ?

Yes, I think it strengthens our case to say, "We are similar to the
heavily-used SQL practice," if we are.

Others more knowledgeable may correct me, but I do not find control
structures.  SQL is a declarative language, so conditionals act more like
guards, for example,
   SELECT name FROM employees WHERE birthdate > '1936-08-12';

If birthdate has the value NULL, (birthdate > '1936-08-12') evaluates to
UNKNOWN, and the record is NOT selected.  In general, only those
combinations that evaluate to TRUE are selected.  UNKNOWN propagates from
comparisons (birthdate > '1936-08-12'), through logical operators (AND, OR,
NOT), but when SQL needs to make a select/no-select decision, TRUE means,
"I'm sure the condition is true," and FALSE means, "I cannot safely assert
TRUE."

In our context, Boolean TRUE is what we sometimes call CERTAINLY TRUE, and
FALSE is not TRUE.  With a careful interpretation, FALSE is an enclosure of
TRUE, in the sense that the correct value is true, but we cannot guarantee
that, so we return a "larger interval."

At least, that is how I interpret the SQL practice in an interval analogy.

Dr. George Corliss
Electrical and Computer Engineering
Marquette University
P.O. Box 1881
1515 W. Wisconsin Ave.
Milwaukee, WI 53201-1881
George.Corliss at Marquette.edu
414-288-6599 (office); 288-4400 (GasDay);
    288-6280 (Dept.); 288-5579 (fax)
Office: Haggerty Engineering 296
Www.eng.mu.edu/corlissg