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

In article <1133992308.569062.326920_at_g14g2000cwa.googlegroups.com>, boston103_at_hotmail.com says...
>
> > Read your own statements, quoted above. I really can't make it much
> > clearer than that.
>
> OK, so you are claiming that I've said that "they [truth tables] don't
> have any substance" even though I, in fact, did not say any such
> thing ? Nice touch.

I'll try to make it clearer anyway, then:

I raised the question how Codd meant equivalence to work in his 3VL. You said the presence of truth tables made this immediately obvious; "one cannot get more specific". I said one obviously could; one could provide the truth table for equivalence. You said "What substance does equivalence as a logical connective add to the game?"---which I interpreted as a rhetorical question meaning that such a truth table would not make any difference; it would not have any substance. That's where my mind boggled, because such a truth table would immediately resolve our discussion as far as I am concerned.

I might have misinterpreted you; I'm pretty sure you misinterpreted me.

> > Yay! A fresh argument! Can you give a link to Kleene's 3VL, or a short
> > summary? Or the equivalence truth table?
>
> It's not a "fresh argument", because we do not *know* what 3VL Codd
> meant.

It's very strange that Codd references neither Lukasiewicz nor Kleene, nor anybody else on 3VL. It casts doubt on his proficiency in it, I'd say. How old is Lukasiewicz' and Kleene's stuff?

> It's assumed, maybe erroneously, that Codd used Lukasiewitcz's
> logic rataher than Kleene's, in particular because Codd talks about
> tautologies that Kleene's logic simply does not have and Lukasiewicz's
> does.

It's silly that we have to assume. Didn't he expound on this in later papers? Which logic is SQL based on? Is Kleene's logic and Lukasiewicz's equally accepted? Wikipedia seems to equate "ternary logic" with Lukasiewicz's but that doesn't mean much, of course ...

> For AND, NOT and OR, Kleene's truth tables are the same as
> Lukasiewicz's, but for the imlication and equivalence, they are
> different. In particular, the equivalence has truth table is:
> [8<]

If this is what Codd meant, I have no further quarrel. It would be nice to *know* instead of guess, though.

> > In my interpretation, the mere presence of truth tables does not imply
> > without a doubt that w = w (equivalence) should be true in a truth value
> > context.
>
> In the truth tables context, 'w=w' is not an equivalence, but an
> equality expression which trivially evaluates to TRUE by virtue of 'w'
> being one of three truth values.

Yes, but now you're talking about the trivial, uninteresting, unused "same string of symbols denoting the same things" equality. When I said in a truth *value* (not table) context, I meant e.g.

create table test ( a TruthValue3VL, b TruthValue3VL); select * from test where a = b;

Will this return rows where both a and b are w/null? In your world, where such a truth value column cannot be 'missing' NULL, only UNKNOWN NULL, I guess this question does not make sense. I see no indications that Codd had this "NOT NULL" requirement, though. And I wonder what the SQL standard says.

> >Thus, the "treated uniformly" has an obvious and simple
> > meaning: w = w is *always* w, regardless of context.
>
> That is wrong, even in Kleene's system w=w evaluates to true assuming
> w is one of the three truth values.

Again, the banal equality is not what I'm talking about. Will "select * from Anything where w = w" return anything? It is the meaning of '=' in that context that is interesting.

> > Neither have Codd. Read some database textbooks. Most suggest "flag"
> > attributes (booleans) for implementing overlapping entity subclasses.
>
> What would be an example of such overlapping entity subclass ?

The example in Elmasri and Navathe (2000) is a Part, that can be a Manufactured Part (with DrawingNo, BatchNo and ManufactureDate) and/or a Purchased Part (with SupplierName and ListPrice). The suggested implementation is a Part table with all the attributes, plus to booleans: MFlag and PFlag. I won't bother to discuss the quality of this example, though. Boolean attributes may be a sign of bad design in many cases, but that is not reason enough to ban them, IMO.

> > Say we have a table of persons. We use a "logical value" column (3VL
> > logic) to store each person's opinion on whether capital of Honduras is
> > Oslo. Some persons say that it is, so we set their column to TRUE. Some
> > say that it isn't, so we set it to FALSE. Some say they don't know, so
> > we set it to UNKNOWN. Some persons haven't been asked, so we set their
> > column to NULL. If we use NULL for UNKNOWN, we can't differentiate
> > between persons who don't know, and persons who haven't been asked.
>
> It's a rather contrived example because what's stored should be a fact,
> rtaher than a pre-cooked evaluation whether the fact is true or not.

What is an interesting fact depends on the application. Here, we are not interested in the capital of Honduras, but in people's knowledge about it (or lack thereof). That is facts as well.

> What you'd like to store is say a (person, location) pair (or tuple,
> does not matter). You'd want to deal with a domain of strings,
> extended by two markers, UNKNOWN and MISSING to represent an address.

What are you talking about now? This has nothing to do with my example.

> > Codd says null=null is UNKNOWN. Either he is here redefining the notion
> > of equality,
>
> Yes, he does.

I don't think so. What would be the point of that? Where is this kind of equality ever used in the RM? I think he is saying that null=null is UNKNOWN in the context of a restriction, like a WHERE-clause in SQL.

> > in which case he might very well do the same for logical
> > constants/values (for reasons of uniform treatment), or he uses '=' to
> > denote equivalence.
>
> No, he might not because if one redefines the equality for logical
> truth values, such logic ceases to exist.

Okay ... I'll have to just take your word for that. Anyway, I don't think Codd does this.

> >This last is the case in most computer systems I
> > know, and in SQL in particular, or else "SELECT * FROM table WHERE 2 + 2
> > = 4" would never return anything. Either way, your argument is
> > irrelevant---and I thought we actually agreed earlier that it is
> > equivalence that matters here?
>
> You might be confused about two kinds of equivalence in logic,
> equivalence as a logical connective (<-->) and equivalence as logical
> expression equivalence (<==>). The former sometimes is called material
> equivalence/a biconditional, the latter *logical equivalence*.

Fascinating. How does this make any difference? If you would like to enlighten me, please tell me what '=' signifies when you compare two logical expressions in a WHERE clause in SQL. Or in a restriction in the RM, to be more technology independent.

-- 
Jon