Re: So what's null then if it's not nothing?

From: vc <boston103_at_hotmail.com>
Date: 3 Dec 2005 06:04:26 -0800
Message-ID: <1133618666.699908.63940_at_g44g2000cwa.googlegroups.com>


Jon Heggland wrote:
[...]
>. And you don't agree with Clement-
> Davies, that it would be a "curious mixture" "suggesting that a RDBMS
> should use two-valued logic to detect tautologies, and three-valued
> logic for everything else."?

No, for the reason I stated above: there cannot be a general tautology mechanism , even in the 2vl, anyway, so why fret about it ?

>
> > > I rather obviously meant the zero to denote the very same logical
> > > constant in both statements.
> >
> > You did not specify the meaning explicitely and I cannot rely on the
> > standard interpretation in this sort of discussion.
>
> Ah, but wouldn't it be convenient if you could? :) Or at least the
> "standard interpretation" that something is equal and equivalent to
> itself.

Sure it would and it is with the exception of NULL. NULL due to its very vague nature cannot be equal to itself since obviously it does not denote a certain unique thing/idea/etc as opposed to say 5 in the standard interpretation as an integer.

>
> > > Based on his article, it is *not* blindingly obvious (to me) that Codd
> > > means null=null should ever evaluate to anything but unknown. That is
> > > the core of my argument, and probably the reason why this discussion has
> > > gone on for so long.
> >
> > I cannot undestand how you came to this strange conclusion. Please
> > provide facts for the conclusion that Codd thought that NULL=NULL
> > always eavluates to UNKNOWN.
>
> "Here, we shall concern ourselves with only the =3Fvalue at present
> unknown=3F type of null and denote it by w"
>
> "[W]hat is the truth value of x = y if x or y or both are null? An
> appropriate result in each of these cases is the unknown truth value,
> rather than true or false."
>
> "We use the same symbol =3Fw=3F to denote the unknown truth value, because
> truth values can be stored in databases and we want the treatment of all
> unknown or null values to be uniform."
>
> What does he mean by "uniform treatment", if unknown/null/w is treated
> *differently* as a truth value and as any other kind of "value"?

I think you have a point here. The treatment is certainly not uniform de facto despite his saying so.

>
> Now *you* provide facts for the conclusion that Codd thought that
> NULL=NULL sometimes evaluates to TRUE.

The very fact of using thruth tables to define logical operator meanings says unambiguously : look, I have three logical constants {true, false, null} (or { true, false,w) in Codd's notation) and here how I define AND, OR, NOT connectives. If one says, that {true, false, null} are *not* logical constants, then one talks about anything whatsoever but logic.

Let's assume Codd is confused, and he says NULL=NULL always evaluates to unknown/NULL. Then he contradicts himself by using the truth tables where NULL = NULL evaluates to TRUE by virtue of being a logical constant and not an unknown value as it might be in other contexts. I find it hard to believe that, being a mathematician, he was confused by elementary logic notions, althought it might have been the case.

>
> > > If it were common to mix integer arithmetic and boolean logic in the
> > > same formulae, yes! Fortunately, it is not---but such a mix of null as
> > > 3VL truth value and as missing value marker does indeed occur in SQL,
> > > and in Codd's article.
> >
> > But in SQL, one never uses any logical constant explicitely {UNKNOWN,
> > TRUE, FALSE} appear only in descriptions of how this or that should
> > function.
>
> So the boolean datatype, boolean columns and expressions are *still* not
> part of the standard? I thought they were supposed to be part of SQL2
> (or whatever it's called now).

They are not and that's the reason why using NULL in two different contexts is not so much of a problem.

> Codd, at least, wanted truth values to be
> stored in databases, cf. the quote above.

Indeed he did.

>
> > I meant that, if you need to deal only with values of some domain
> > (strings), not with unknown/missing markers thereof, there is no
> > problem. Clearly, if one needs to name two different
> > things/object/ideas in the same context/domain one would use two
> > different labels.
>
> And if you use NULL for the unknown truth value, how do you designate a
> missing one?

But as I said multiple times, the real label is 'logic_context.NULL' or 'integer_context.NULL', not just NULL.

>
> > The logic vocabulary exists in its own context and I personally do not
> > see any problem in separating logic constants from any other domain
> > labels. Are you as much confused when using the label 'a' as an
> > English article, the first letter of alphabet, or a variable, or
> > something else ?
>
> See above. Alternatively, consider it a matter of taste. Why make things
> more messy than necessary by overloading symbols just for the hell of
> it? What makes NULL a better symbol than UNKNOWN for the truth value?

Nothing, and in this specific case of the 3vl (but not in the others)  I actually agree with you, although I might have come through as meaning something entirely different ;)

>
> > > > > I'll ask you yet again: Do you claim that when null is encountered as a
> > > > > 3VL boolean (lukasiewiczian?), Codd (or SQL) says null = null should
> > > > > yield true?
> > > >
> > > > As a logical constant, yes, as an unknown/missing value, no.
> > >
> > > Can you back this up with quotes from the article, or the SQL standard?
> >
> > The standard, or the article, does not discuss elementary notions of
> > logic. maybe they should, I do not know.
>
> Then what do you base your assertion on?

On knowing what the logical constant is, very much in the same fashion as you'd base your knowledge of '7 times 8 = 56' on being acquainted with the multiplication table. You would not require a text beyond the first grade textbook treating anything related to multiplication be equipped with the multiplication table, would you ? I'd concede though, that based on our discussion, a sketch of what the 3vl ideas are might have been a useful addendum to the standard.

>
> > > I assume the 3VL meaning for the symbols; not that it matters much. You
> > > say Codd's rule that null=null is unknown has an exception for the case
> > > when null is a 3VL value.
> >
> > It's not an exception.
>
> Codd says: "[W]hat is the truth value of x = y if x or y or
> both are null? An appropriate result in each of these cases is the
> unknown truth value, rather than true or false." This is his rule,
> whereas ...

He talks about NULL in contexts *other* than that of logical constants.

>
> > I'll try again one last time. NULL in the
> > context of some domain of values, integers, characters, whatever,
>
> (Truth values is also a domain.)

Right, it's a trivial observation, but so what ? It's a different domain with different rules.

>
> > means an unknown/missing value (as defined by Codd and the SQL
> > standard). NULL in the context of the 3vl is just another logical
> > *constant* which has got nothing to do whatsoever with the meanning of
> > NULL as a missing/unknown value.
>
> ... this is a different rule. Codd does *not* say this, and neither does
> the SQL standard, by your own admission.

In Codd's case, it's stated by virtue of his using the truth tables. The standard does not, although as I said probably it should have, given the level of familiarity with logic elementary notions (not only the 3vl).

>
> > Substitute whatever string of
> > characters you like most for NULL as a logical constant, and nothing
> > will change.
>
> On the contrary. If Codd had used U instead of null/w for the truth
> value unknown, we wouldn't be having this argument.

I meant nothing will change in stating the rule of the 3vl. I did not imply that nothing would have changed in our discussion ;)

> --
> Jon
Received on Sat Dec 03 2005 - 15:04:26 CET

Original text of this message