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

From: vc <boston103_at_hotmail.com>
Date: 8 Dec 2005 06:31:21 -0800
Message-ID: <1134052281.291970.61920_at_g44g2000cwa.googlegroups.com>


Jon Heggland wrote:
> In article <1133992308.569062.326920_at_g14g2000cwa.googlegroups.com>,
[...]
> > > 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?

Lukasiewicz's dates circa 1917 and Kleene's 1950.

>
> > 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?

I am not sure ;)

>Is Kleene's logic and Lukasiewicz's
> equally accepted?

There are quite a few works on both. I do not have statistics as to which one is studied more... Besides, there are folks like Goedel, who also played with a 3VL.

>Wikipedia seems to equate "ternary logic" with
> Lukasiewicz's but that doesn't mean much, of course ...

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.

It sure would.

> > > 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 the context of a 3VL, you have to ask yourself the question, what '=' really means. If it's the equality predicate, then you get one answer, if it's the equivalence connective, you might get a different answer depending on what 3VL you use.

>
> > >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.

Right. See above.

> > > 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.

That has a whole lot to do with yours or similar examples. Instead of storing precomputed truth values/judgements, one should arguably rather store actual facts. You suggest to store:

(person, opinion, veracity).

I suggest to store (person, opinion) where opinion is a set {opinion1, opinion2,..., UNKNOWN} and then derive veracity. You probably do not need to handle MISSING which would be automatically handled by just not storing the fact. The judgement as to whether the opinion is missing can also be derived form the stored facts.

>
> > > 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.
>

Sorry, but saying null=null evaluates to UNKNOWN is already a redefinition of the equality predicate. Along with that, he, as well as the SQL standard, also redefines quite a few other predicates (<, >, !=) as well as mathematical operations (+, -, *, ...).

> > > 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.

You do not need to take anybody's word for that. It's rather an obvious statement. Take for example De Morgan laws or any other logical expression transformation. Saying that two such expressions are *logically equivalent* means (by definition) that they have the *same* truth tables. Now, with your suggested approach to redefine equality for truth values, one would never be able to determine if two truth tables are in fact *the same* as some attempts at such comparison would produce UNKNOWN should any row of such table contain UNKNOWN or some such.

>
> > >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.

I might be able to tell if say what you mean by "compare two logical expressions in a WHERE clause in SQL".

>Or in a restriction in the
> RM, to be more technology independent.

For example ?

> --
> Jon
Received on Thu Dec 08 2005 - 15:31:21 CET

Original text of this message