Re: So what's null then if it's not nothing?
Date: 15 Dec 2005 12:42:19 -0800
Message-ID: <1134679339.048493.78900_at_z14g2000cwz.googlegroups.com>
Jon Heggland wrote:
> In article <1134657782.044908.325470_at_g49g2000cwa.googlegroups.com>,
> boston103_at_hotmail.com says...
[...]
> > So you claim that UNKNOWN does not represent the same degree of truth ?
> > So, you reject not only the notion of truth table comparison, but
> > deny any meaning ascribed to truth values for the sake of 'uniformity'.
> > Cool.
>
> *I* don't; I just point to what other people are saying. Codd, in his
> discussion with Date on the matter
> (http://www.dbdebunk.com/page/page/1706814.htm), seems in fact to
> consider the unknown truth value to be a variable that in reality is
> either TRUE or FALSE, but we don't know what it is.
That is not what he said. He said: "Date's argument that true and false are the only truth values, and that, therefore, unknown cannot be treated as a logical value makes no sense to me".
However, his subsequent analogy "After all, it is very common in mathematics to label unknown values by letters such as m, n, x, y, z." is not very enlightening. Nowhere did he say, though, that UNKNOWN is a variable.
One can infer the 'variable' meaning from "The fact that the letters m, n do not "look like" any of the integers does not prevent them from actually having integer values in an expression such as m + n, m - n, or an assertion that m * m = m.", but it would be a strange interpretation. In fact, he said: "an RDBMS must be able to determine whether NOT A, A OR B, and A AND B is true, false, or unknown when A, or B, or both are unknown" which clearly means that 'unknown' is a truth value a logical expression may evaluate to.
[...]
>
> > > > Regarding 'uniformity', witness TRUE OR NULL evaluatiing to TRUE, not
> > > > NULL as a uniformity purist would expect.
> > >
> > > Yes, and I do object to that.
> >
> > And you do not realize that by doing so you destroy entirely what's
> > left of Lukasiewicz's (or Kleene's) logic (after you had removed the
> > notion of logical equivalence) since the AND and OR truth tables are no
> > longer what they used to be ? And it does not bother you that the
> > commonly accepted interpretaion of OR as something being true if at
> > least one operand is true does not work any more ? Most cool.
>
> My preferred solution would involve an actual truth value called (e.g.)
> UNKNOWN, distinct from NULL, and equal to itself (of course). So my
> "destroying" logic would be limited to allowing truth value variables to
> be NULL, letting those NULLs propagate, and not considering NULL part of
> the truth value domain (or any domain at all).
How can you reconcile the idea of an element being a member of some set/domain due to the fact that one can apply all the domain's operations to the element and store the element along with other domain values , and *at the same time* not being a member of such domain ? Further, instead of having a three-valued logic, you've created a four valued logic with some strange rules for its usual connectives (How can one interpret the rule that TRUE OR 'YOUR_NULL' is no longer true ? How would you rationalize such OR ? Also, you did not solve the problem with the truth tables being equal since they now contain 'YOUR_NULL' which makes them incomparable.
>
> > What I meant was that Oracle people were sensible enough to regard the
> > expressions with the same truth tables, even containing nulls, as
> > equivalent which is evidenced by the optimizer behaviour in spite of
> > the nonsensical interface they present to the end user. They did not
> > have much say in this matter but try and conform to the standard.
>
> This is exactly what I suggested, and probably what the SQL committee
> intended.
I am not sure what you've suggested. Was that some truth table rows (containing NULL) cannot be regarded as equal and yet the truth tables can be considered equal ?
>What is the problem?
> --
> Jon
Received on Thu Dec 15 2005 - 21:42:19 CET