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

Jon Heggland wrote:
> In article <1134310021.361013.248720_at_f14g2000cwb.googlegroups.com>,
> boston103_at_hotmail.com says...
> >
> > > But how do you reconcile this with his THETA-SELECT example, where R[A =
> > > r] does produce a result? By your definition, A is certainly not equal
> > > to r.
> >
> > A is a variable that may or may not be equal to 'r' when it ranges over
> > some domain of values.
>
> Ah, so the presence of range variables change the interpretation of '='?

No, it does not.

> Let me quote some old parts of our discussion (I'm even, you're odd):
>
> > > Let me try an analogy. If, in Java, you say "if (4 == 2 + 2) ...", what
> > > is the if statement testing, equality or equivalence? Or does my
> > > question not make sense in some way?
> >
> > Equivalence, of course.

I was too glib.

After having this discussion about equivalence, biconditionals, NULL and such, I do not think any more that talking about fine points of equivalence vs. equality in the context of *algebraic* expressions like the one above is very productive. Let me explain.

There are two ways to look at expressions on both sides of the '==' sign. One can consider the expressions themselves (or using a fancier language, 'intensions'), or the values such expressions evaluate to ('extensions'). Now, one can say that although the expressions are different, their extensions are the same, so one could say that expressions are *equal* extensionally and *equivalent* intensionally (by virtue of the extensions being the same). So, '==' is the equvalence sign intensionally, but the equality sign extensionally.

Abandoning the fancy intension/extension language, one can also say. OK, in the programming language context we do not care about expressions but rather the values the expressions evaluate to. So, in this context, '==' can always be interpreted as the equality sign/predicate.

When one would care about expression equivalence would be if one were to write a compiler expression reduction/transformation module or something of the kind (I believe I mentioned that in one of my messages). Also, one gets familiar with expression equivalence idea during one's years at the secondary school doing all those algebraic expression 'simplifications'.

In short, I suggest that we'd better talk in terms of equality of values in the context of algebraic expressions (like x+3 == x-1+4) forgetting about the idea of expression equivalence since, in practical tems at least, that's how people usually think about this sort of stuff.

> >
> > >
> > > > Two 3vl expressions are equal iff they are the same. E.g. (X and Y) =
> > > > (X and Y).
> > >
> > > So (X and Y) is not equal to (Y and X)?
> >
> > Obviously, it's not.

See above. Differentiating between expressions (equivalence) and the values they evaluate to (equality) does not appear to clarify the picture, but rather the opposite.

>
> (End quote)
>
> So... In a THETA-SELECT R[2 + 2 = 4], '=' would be equivalence, but in R
> [2 + 2 = A], '=' would be equality?

No, if you wish to dwell on expression equivalence vs. expression value equality a bit more, then 2+2=4 can be *interpreted* as both equivalence and equality (see the the earlier explanation) with both equality and equivalence evaluating to TRUE. I suggest we treat 2+2=4 as just equality and forget the talk about equivalence in the context of similar arithmetic expressions in order to make the discussion simpler

'2+2=A', on the other hand can be interpreted *only* as an equality predicate because 'A' is a variable and there is no way the expression '2+2' can be transformed to A, or in other words, for two expressions to be equivalent they have to evaluate to the same value for all possible values the constituent variables can assume (sort of stuff one does at school with algebraic expressions), and clearly, it's not the case with your example because A can be, say, 5.

(X and Y) is "obviously" not equal
> to (Y and X), but what if X and Y are range variables? Can you imagine
> why you often confuse me?

(X and Y) is *equivalent* to (Y and Y) because you can transform the first expression into the second knowing that 'and' obeys the commutative law , or just by looking at the truth tables you might have written down. Doing so, you'd have proved that both (X and Y) and (Y and X) evaluate to the same for all the possible values of X and Y and therefore are equivalent.

>
> > > I still don't understand what the 'lethal' problem is. Can you give an
> > > example?
> >
> > Evaluating w=w to w where = denotes equality.
>
> That may be the *cause* of a problem. What is the *problem*?

Not being able to say whether two truth table for arbitrary expressions are in fact the same. Did not I say that, like, a dozen times ?

>
> > > It would have helped your case if Codd had included that word. Seems to
> > > me that either:
> > >
> > > 1. There is no problem, even if you apply this to truth values
> > > 2. There is a problem, but Codd wasn't aware of it
> > > 3. Codd was aware, but was really bad at explaining things
> > > 4. The problem is so obvious that it is pointless to mention it
> > >
> > > I lean towards 1 or 2. Do you subscribe to 4, or do you have other
> > > alternatives?
> >
> > I subscribe to (4). I am also curious as to how one can subscribe to
> > anything but (4) assuming one understands that a logic is not
> > available any more if (1).
>
> That understanding is the crux of the matter, I guess. :) Note: You may
> very well be right, but in that case I believe Codd was wrong. His using
> the same symbol for for 'missing' null and unknown truth value, and his
> "uniform treatment" phrase have *no* purpose and serve *only* to confuse
> if (4) is the case.
>
> And for what it's worth: The SQL-99 standard seems to have interpreted
> Codd the way I do. But I'm not sure if that weakens or strengthens my
> position. :)

Codd, at least, never called a contraption with three wheels a bicycle. They also define a number of predicates, like '=', '>' over their 'Boolean' domain not even realizing that '=' is in fact Kleene's biconditional/equivalence, but they probably never heard about the fellow so it's hard to blame them. It's unclear (for obvious reasons) what they are going to do with their truth tables too.

> --
> Jon
Received on Mon Dec 12 2005 - 15:37:24 CET