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

In article <1133896860.912140.197720_at_f14g2000cwb.googlegroups.com>, boston103_at_hotmail.com says...
>
> > > > > Sorry, one cannot get more specific than defining truth table as
> > > > > that's the only way to describe what the logical operations mean.
> > > >
> > > > Of course one can. One can define the truth table for equivalence, for
> > > > one thing!
> > >
> > > So what ? What substance does equivalence as a logical connective add
> > > to the game ? It's just another truth table, that's all.
> >
> > Now you really boggle my mind. One minute, you claim that truth tables
> > are the end all, be all desideratum for Codd's meaning; the other, you
> > say they don't have any substance!
>
> I do not understand that, especially the part about my claiming that
> "they don't have any substance".

Read your own statements, quoted above. I really can't make it much clearer than that.

> I'll try to re-phrase. The usual way to define what a logical
> connective is about is to provide its truth table. The truth table
> uses logical constants to do so. Therefore, it's immaterial whether
> or not the logic designer gave a complete set of such tables in order
> to *see* that some strings of characters indeed are logical constants.

I'll say it yet again: That's not what I am contesting. The only thing we are arguing about, as I see it, is whether Codd intended his missing truth table for equivalence to look like this:

  T w F

T|T w F
w|w T w
F|F w T

... or this:

  T w F

T|T w F
w|w w w
F|F w T

> It's intersting that you've mentioned that. In Lukasiewicz's 3VL,
> they are not, but in Kleene's style 3VL, they are. Since we do not
> know what 3VL variety Codd used, it would be prudent to refrain from
> trying to criticize him for alleged 'oversights' with respect to the
> 3VL.

Yay! A fresh argument! Can you give a link to Kleene's 3VL, or a short summary? Or the equivalence truth table?

> > > "they should be treated uniformly" because the latter begs the question
> > > "what do you mean by 'uniformly' ?" whilst the former does not.
> >
> > No, *your* interpretation begs the question "what do you mean by
> > 'uniformly'?". My interpretation does not.
>
> Your interpretation is based on what ?

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. Thus, the "treated uniformly" has an obvious and simple meaning: w = w is *always* w, regardless of context.

> Gee, I wonder how SQL manages to define constraints, then. The values
> are used implicitely, you've not provided sufficient rationale for
> storing them in the database.

Neither have Codd. Read some database textbooks. Most suggest "flag" attributes (booleans) for implementing overlapping entity subclasses.

> > Then suggest another name you'd prefer I use. I've asked you for such a
> > name three or four times. I'll call it Lukasiewiczian, if you don't come
> > up with anything easier to type.
>
> Why not call it a logical value ?

Because that will be confused with Boolean?

> > > if I were to store a 3VL constant I would
> > > just do so regardless of what's it called NULL, UNKNOWN, 1/2, or
> > > something entirely different.
> >
> > "Just do so", as if by magic? Please. If NULL is used both as 'missing'
> > and as a normal value for a data type, how do you formulate your DML
> > statement?
>
> Please provide an example of a statement that one cannot formulate if
> NULL is used as a logical constant.

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.

But our apparent disagreement here is plainly based on a misunderstanding; see further down.

> > > > What do *you* think it means?
> > >
> > > I have no clue.
> >
> > But you are certain it does not mean what I think it means? Why, if you
> > have no better alternative?
>
> How do you know what it means ? Codd did not dwell too much on what he
> meant by it.

Of course it's just my opinion, but it explains his statements well, I think. Your interpretation begs several questions: What does "uniform treatment" mean? What is the point of using the same symbol for 'missing' and UNKNOWN? In my interpretation, these questions are answered.

> > > > No. He doesn't define equivalence;
> > >
> > > So what ? It's enough to define a *single* truth table, say, for
> > > AND, and it would have been clear that the strings he uses {true,
> > > false, w} are indeed logical constants.
> >
> > Irrelevant. They may be logical constants, but that has no bearing at
> > all on whether or not he uses the conventional 3VL equivalence relation.
> > In fact, as I may have said before, the text suggests that he doesn't.
>
> What do you mean by "3VL equivalence relation" ? '<->' is not a
> relation.

Strike the word "relation", then.

> Then he would be using Kleene's 3VL. We just do not know since he
> never had need to define or use '<->' anywhere. Besides, I hope you
> realize that whilst 'w<->w' may be defined as evaluating to UNKNOWN,
> 'w=w' always evaluates to TRUE by virtue of being a logical constant
> denoting the same thing/notion.

Earlier, you said

'As. I believe Tarsky. said, "x = y if, and only if, x and y have every property in common." In simpler words, x and y are equal iff they are the same.'

Codd says null=null is UNKNOWN. Either he is here redefining the notion of equality, 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. 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?

> > > It's unclear what use such connective ['<->'] might have.
> >
> > No, it's very clear. "Truth values can be stored in databases and we
> > want the treatment of all unknown or null values to be uniform."
>
> What has the '<->' connective got to do with the idea of storing
> logical values in the database ?

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

'=' here obviously means equivalence, not equality.

> > > > It is strange to suggest that a DBMS should have the capability to store
> > > > the result of the evaluation of a condition?!
> > >
> > > What utility storing "the result of the evaluation of a condition"
> > > might have except leading to data redundancy ? Presumably, all the
> > > true facts are already in the database.
> >
> > Orthogonality, completeness, simplicity, power.
>
> Please, elaborate on each of the those four words.

You don't know what they mean? That does explain a few things.

Consider this example:

create table test2 ( a integer, b integer ); select * from test2 where (a < 12) = (b > 15);

This query is a syntax error in SQL, or at least in Oracle. You can reformulate the condition to an equivalent, syntactically allowed expression, but why should we have to? Do you know how hard (and embarrassing) it is to teach SQL, due to its lack of consistency, orthogonality and lack of adherence to simple language design guidelines? Do you know how hard it is to create a parser for SQL, for the same reasons? But this is a different discussion.

> > > > For the exact same reason that we don't call zero NULL for the integer
> > > > domain.
> > >
> > > Not calling zero NULL is a matter of convention/tradition, nothing
> > > else.
> >
> > And you don't see any problems at all if we called zero NULL in SQL? I
> > am beginning to find it hard to take you seriously.
>
> That's your problem. You did not specify the context or in other
> words did not mention that you wanted to use the word NULL *both* to
> represent the integer 0 *and* to represent a missing value in the same
> domain which is clearly impossible,

Hey! This may actually have been enlightening. Let me try to summarise your position:

1. Logical values don't need to be stored in the database.
2. If we nevertheless were to store 3VL logical values in a database, it makes sense to use NULL for UNKNOWN.
3. Attributes of the type "(3VL) logical value" cannot be 'missing' NULL, only UNKNOWN NULL.

Correct? This is consistent, so my only objections to it is on the grounds of good language design. Those objections are strong, of course, but not a matter of logic in its formal sense.

> and now you blame someone else for
> your failure to comunicate what exacly you've meant.

FWIW: You have also failed to communicate that you mean to forbid the usage of NULL for 'missing' when you use it for something else.

> If using the same name for different entities (3I vs. 3R) belonging to
> different domains is OK in one case, why is it a problem in the other
> ? NULL in Codd's 3VL does not denote a missing value, but rather a
> logical constant, so there should be no confusion as long as one knows
> in what context the name NULL is used.

Very well, but that precludes the use of 'missing' NULL for "logical value" attributes.

-- 
Jon