Re: All hail Neo!

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 25 Apr 2006 15:01:58 GMT
Message-ID: <GRq3g.65574$VV4.1249904_at_ursa-nb00s0.nbnet.nb.ca>

Frank Hamersley wrote:

> Bob Badour wrote:
>

>> Frank Hamersley wrote:
>>
>>> Bob Badour wrote:
>>>
>>>> Frank Hamersley wrote:
>>>>
>>>>> Bob Badour wrote:
>>>>>
>>>>>> Frank Hamersley wrote:
>>>>>>
>>>>>>> Bob Badour wrote:
>>>>>
>>>>> [..]
>>>>>
>>>>>>>> In that line of thought, here's an interesting question that 
>>>>>>>> Date et al have posed before to the n-VL folks:
>>>>>>>>
>>>>>>>> If "exists but empty" is true and "doesn't exist" is false, what 
>>>>>>>> is null?
>>>>>>>
>>>>>>>
>>>>>>> Neither and both!
>>>>>>
>>>>>>
>>>>>> I find that sort of handwaving to be a complete non-answer.
>>>>>
>>>>>
>>>>> I suspect you are wearing the darkly tinted glasses of 
>>>>> preconception. Whilst I was trying to show a little wit, the 
>>>>> current 3VL state of affairs still seems to me to fit that 
>>>>> description.
>>>>>
>>>>>> A much more intellectually honest reply would be: "I don't know."
>>>>>
>>>>>
>>>>> Not from this black duck (on this occasion)!
>>>>>
>>>>>> or "Null has no similar analog in set theory."
>>>>>
>>>>>
>>>>> I wasn't comparing/contrasting the RM with set theory.  Perhaps for 
>>>>> you it is implicit?
>>>>
>>>>
>>>> No, it is quite explicit.
>>>
>>>
>>> I am quite interested in exploring this area so please bear with me 
>>> as my analysis is heavily tainted with practical experience and less 
>>> (recently) so with formal theoretical studies. My response may be 
>>> somewhat affected by the serial reading and responding to your post 
>>> and I never feel comfortable with long posts when it finally is time 
>>> to click send!
>>>
>>>> Relations are sets.
>>>
>>>
>>> ALL relations are sets?
>>
>>
>> Yes, ALL relations are sets of tuples. SQL tables are not relation 
>> variables and do not contain relations.

>
>
> OK - I presume the dichotomy is practice (SQL) vs theory (RM) in that
> with the former tables can exist with repeated rows but in the latter it
> presumes in a relation all tuples are distinct?

Since SQL and RM are both theory and practical, your sentence is nonsense.

>>> I understand this puts us at odds
>>> from inception.  From there I expect anything brought to this issue 
>>> by theory will be elegant, symmetrical _and_ compelling.
>>
>> Relations are elegant, symmetrical and compelling. Bags and null are 
>> none of those.

>
> Relations it seems are E,S+C until missing information is added to the
> mix. Bags and nulls are quite apparently not but from where I am now
> the null at least seems the lesser of evils viz my post in the
> "beautiful mind" thread.

Missing information is messy and we have no theory at all for addressing it. Adding it to the RM in no way reduces the elegance, symmetry or compellingness of the RM. Either one can use the E,S&C to tackle the difficult problem, or one can pretend the problem doesn't exist.

Null pretends the problem exists. It reduces the expressiveness of the language and hides people's errors from them. Can you imagine a compiler that refused to reject any program or issue any warning?

>>> [2nd editing]
>>> Having read the texts, below I felt inclined to retract the above 
>>> para, but then decided to leave it so you could form your own view on 
>>> how wacky my thinking might be.  That said perhaps the fact that 
>>> nulls do exist in the RM today taken with your confirmed view that 
>>> they shouldn't (from a theoretical basis) is implied confirmation of 
>>> my rather unlikely original thought...he says stepping back two full 
>>> paces - did I write that?
>>
>> Whether nulls exist in the RM today is a topic of some controversy.

>
> Sure is - in biological terms noting that the bastard child SQL inherits
> only half its genome from the known parent (RM) then the question is -
> is it a meiotic mutation or a pre-existing recessive allele now
> homozygous and perhaps deleterious?

Nonsensical handwaving.

>>>> Relational algebra is the equivalent of set theory, and relational 
>>>> calculus is the equivalent of predicate calculus.
>>>
>>> I have no beef here.
>>
>> With null or without logical identity, they lack the equivalences 
>> mentioned.

>
> By logical identity I take it you mean the distinctness of each tuple?

The identity of every explicit value in every relation. Since tuples are values, logical identity includes those.

>>>> Thus, the equivalence of dee and true and of dum and false are very 
>>>> important. And the question of what relation value equates to null 
>>>> is a very good question.
>>>
>>> Lets put that aside until the first question has been addressed.
>>
>> Shall we get back to this now?

>
> Yep - although there probably no debate to be had once the various and
> varying starting points are determined.

More nonsensical handwaving. You have succeeded in one thing with your evasiveness: you have demonstrated your lack of intellectual honesty and integrity.

>>>>>> True and 1 both have the exact same analog in set theory. False 
>>>>>> and 0 both have the exact same analog in set theory.
>>>>>
>>>>> Perhaps but insistence on a parallel form for the RM does not seem 
>>>>> to lead anywhere practical*...FWICT.
>>>>
>>>> Are you suggesting that query transformations lack practical benefits?
>>>
>>> No sure where you are going here, can you be specific or illustrate?
>>
>> The equivalence between relation values and boolean values facilitates 
>> certain query transformations such as between a union and an 'or' 
>> predicate and vice versa.

>
> OK. Obviously useful for the theorist to explore stuff (apols to Alexi).

Obviously useful for the practitioner to explore as well. If the practitioner never considers where the pitfalls lie, he will only discover them from the bottom of the pit.

>>>> With respect to {}{} either it is completely meaningless, or perhaps 
>>>> you intend the juxtaposition of two sets to mean conjunction or 
>>>> disjunction, in which case:
>>>> {}{} = {} = false
>>>
>>> It was just a wild punt - the intent was to suggest that two empty 
>>> sets were distinct and that their intersection was indefinable.
>>
>> One wonders in what way they are distinct. Is 1 distinct from 1? Is 0 
>> distinct from 0? Obviously, as values, they are indistinct. One must 
>> then posit that they differ in location.

>
> So {1} and {1} are not distinct when conceptually imagined in an OO
> instance frame of mind?

An OO instance is a variable. Thus the values of the two variables are indistinct even if the variables themselves are distinct and distinguishable by physical location.

   Thus it would take something like {1,2} and
> {1,3} at which point the sets are distinct? In this case are the 1's
> distinct?

No, they are not. The value 1 is the value 1. They are equal. You have given no other way to distinguish the values. In fact, in set theory:

{1} = {1,1} = {1,1,1}

>> However, a single attribute within a single tuple within a single 
>> relation variable has a unique logical location.

>
> True.
>

>> How then can null equate to two locations?

>
> I'm guessing a bit here about your question - I take it to mean {1,null}
> and {1,null} should not be seen as distinct but nVL insists they are?

No, I was shredding your earlier try at an answer when you replied with "{}{}=null".

>> What then does it mean when the null appears in a derived value which 
>> has no location at all?

>
> But the RM proscribes every value (derived or not) has a location does
> it not - that is putting aside the stuff about nameless or duplicated
> attributes etc?

In the RM, logical identity locates a value within a variable. One can change part of a variable for instance and the value at one or more physical location(s) will change. The fact that values outside of variables have no location further shreds your attempt at a reply with "{}{}=null".

>>>> If null and false are the same, we can do away with null.
>>>
>>> They aren't but I guess it may be feasible to do away with null in 
>>> the truth table ie. null implies false.  I expect you would still 
>>> need its physical presence in the manifestation of tables/relations.
>>
>> If null is not the same as false, then it is not the same as {}. Does 
>> it then have an equivalent set representation?

>
> No, I don't think it does. As you say it is not {} and {null} does not
> equal {null} - this is as I said before a paradoxical state of affairs
> and clearly does not marry well with the formal approach to analysis.

And since all of programming is about formalism, I suggest null has no effective role to play in any aspect of programming.

> [..]
>

>>> Thanks for the pointers - admittedly I have only limited time and 
>>> have had to skim through the material, however it was apparent that 
>>> there remains substantial areas where consensus has not been achieved 
>>> (yet).
>>
>> I suspect your statement is true of all of mathematics and in fact of 
>> all fields of study.

>
> Which is why we two are assembled here today - not enough of us for a
> riot however!
>

>>>>> * (for another post perhaps) I don't see any great leap forward in 
>>>>> the aspects of TTM that address the extinction of nulls.
>>>>
>>>> If nulls cause great damange without serving any particularly useful 
>>>> purpose, why should one address their extinction?
>>>
>>> No quite sure what your thrust is here, perhaps you would like to 
>>> edit it given the damage (sic) it has suffered?  In advance of that, 
>>> I can state that I don't hold that nulls cause _great_ damage 
>>> (although neither does Semtex in capable hands for a proper purpose) 
>>> and I certainly believe (at this point) that they do serve a purpose.
>>
>> Are you familiar with Date's various _Writings..._ books? He and 
>> Darwen and others have demonstrated that null causes great damage.

>
> I don't need them to postulate it as I've seen it first hand. My
> opinion of Date mainly and Darwen to a much lesser extent (more by
> association than real research) is that whilst they have taken a pot
> shot at a low flying albatross, they haven't come up with anything even
> close to better.

I disagree. They have correctly identified that missing information as of yet has no theory to address it. While I disagree with some of their ad hoc attempts to address it differently than null, I suggest the RM -- without any special feature for missing information -- already handles it as well as we can until someone establishes a valid theory addressing missing information.

Null takes a bad situation and makes it worse. It does harm. Removing it improves our lot.

> Given the lesser evil option I expect to rely on skilled practitioners
> to mitigate the risk of that damage arising. Sadly they don't grow on
> trees!

All the more reason to make simple queries easier to express correctly so casual users do not have to waste the time of skilled practitioners for very common, mundane queries.

>> Nulls attempt to address missing information but do so with no basis 
>> in theory. I suggest that the null elixir only offers the illusion of 
>> power:
>> http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD898.html

>
> I understand your view. For the record mine is that null is no elixir -
> more like Cod Liver Oil and there ain't no illusions when swallowing
> that stuff.

If one takes the average age of a group of people where some of the ages are unknown, then the average is unknown. With a relational dbms, I can model the ages so that it returns the correct result, unknown.

When the user gets the result, the user has to ponder what that means and how to proceed. If the user discovers that back in the old days nobody bothered to record birthdates, the meaning is different than if the ages are unknown because some of the people are fetuses as of yet unborn.

Null is less expressible than the RM because it obviates the possibility of returning the correct result. The result it returns is incorrect and in the cases mentioned above is not even approximately correct, but the user has no alert to the problem.

If that is not an illusion of power, I don't know what is. As a solution for the problem of missing information, null is an elixir. Since your earlier evasiveness has revealed your lack of intellectual honesty, I will dismiss your denials as groundless.

>>> As to
>>> Date and Darwens attempt to remove nulls as shown in the Tutorial-D 
>>> slides it didn't seem to meet the elegance or compelling stature I 
>>> mentioned before.
>>
>> Missing information is messy, and we lack any theory to address it. 
>> Pretending otherwise may put the mess out of sight and out of mind, 
>> but that just makes the mess worse and the problems more surprising 
>> when re-discovered.

>
> That is how I would characterise "D". On the theory side I am in a
> prolonged contemplation on the missing dimension in SQL (as compared to
> the RM) which is the temporal capability. I have made what I consider
> to be some progress but it is premature to discuss publicly lest I end
> up wearing lots of egg, suffice to say the null thang has a parallel in
> temporal matters. BTW I don't rate Date & Darwens offering on this
> either, nor FWIW much of the Snodgrass et al stuff that preceded them.

Yes, well, get back to us when you have something substantive to offer that won't leave egg on your face. Received on Tue Apr 25 2006 - 17:01:58 CEST