Re: All hail Neo!
Date: Wed, 26 Apr 2006 14:28:02 GMT
Message-ID: <SrL3g.66121$VV4.1263767_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: >>>>>>> >>>>>>>> Frank Hamersley wrote: >>>>>>>> >>>>>>>>> Bob Badour wrote:
>
> [..] time for a haircut!
>
>>> 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.
>
> Preempting some of your various replies below you seem to be getting
> fatigued of this topic. Regardless, for me the RM is the theory and SQL
> is the practice. Sure the latter "contains" some or all the former but
> using this distinction adequately provides terms or reference for me as
> "where we are" against "where we want to be". I don't think I can help
> you much more than that.
It's rather presumptuous of you to think I need any help. SQL is rather flawed theory based on multisets or bags and 3-vl, sort of. Ignoring the principle of cautious design, those who first created SQL made arbitrary and unecessary decisions that altered the theory dramatically from where it started in the RM.
> [..]
>
>> 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.
>
> Rubbish - IMO the whole is less for the adding the messy bit without
> resolving it to meet the ES+C criteria. Sure the other parts are just
> as ES+C as they were before when taken in isolation. This is akin to
> the mess that existed in the prediction of planetary orbits prior to
> Newtons apple.
>> Either one can use the E,S&C to tackle the difficult problem, or one >> can pretend the problem doesn't exist.
>
> This sounds overtly minimalist on your part. If I read it correctly on
> the one hand you state there is no theory to support missing info and
> then you propose to solve the issue solely with the theory at hand
> whilst dismissing all other possibilities - to toss in a barb that seem
> as ostrich like as it gets.
>> 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?
>
> Nup - unless the optimizer deduced the erroneous code was unreachable!
> That of course would be pointlessness^2.
>>>> 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.
>
> Is this code for I don't understand or simply can't be bothered?
>>> 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.
>
> More fatigue?
No, just a realistic evaluation of your worth as a participant here.
>>> 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.
>
> Sure - and these pits are often filled with tar! What I was alluding to
> is a practitioner accepting the theory can avoid exploring the pits by
> sticking to the provided map. Of course it is a worthy goal for all
> practitioners to understand as well as apply best practice.
>>> 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.
>
> No drama here.
But what is the physical location of a variable in a distributed database.
>>> 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}
>
> OK.
>
>>> 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.
>
> Very sloppy words! I would say intellectual honesty arises when you are
> prepared to say something like "since all of programming *theory* is
> about formalism, I suggest null has no effective role to play ..."
A program itself is a proof of some theory. Sadly, most programs written prove the wrong theory.
> Of
> course I would be interested to see you ante up and describe a
> fundamental and complete solution rather than simply taking your bat and
> ball home.
>>>> 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.
>
> That is a trivial conclusion! Where's the beef? You don't need to be a
> luminary to get this far - do you?
That's a preamble not a conclusion. Duh.
>> 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.
>
> I'm all eyes! I'm happy to consign null to oblivion if you give me a
> _credible_ solution which means it must meet ES+C to accommodate my
> limited analytical abilities.
>>> 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.
>
> I can relate to that - but I for one don't see your mundane queries as
> in the problem domain. Viable practitioners can design RM compliant
> systems using SQL if required. The real issue is solving the difficult
> queries - something which D+D skate glibly over as I pointed out.
>>>> 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.
>
> I can cope with that - I would have no problem being forced to write
>
> "select avg(age) from table where age is not null"
>
> to get the crappy statistic that it is if the user demanded it. But I
> thought you wanted to eradicate the nulls period?
>> 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.
>
> You are taking on too much methinks - if a mug user wants to buy
> birthday presents for fetii why should the RM be saddled with saving him
> from his own stupidity. Better IMO to focus on those who want to be saved.
Where did I say anyone was buying mugs? Your straw man is pointless; stick to what I said. I have postulated two users issuing similar queries in very different circumstances where the correct answer to an average is unknown.
>> 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.
>
> Unskilled users yes
>> 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.
>
> Ah well we all have crosses to bear - suffice to say there are no
> illusions on my part.
Suffice to say I have demonstrated otherwise.
>>> 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.
>
> No problem. In the meantime I am happy for you to advance something
> more than a simple change to the behaviour of avg().
You are an idiot. Plonk. Received on Wed Apr 26 2006 - 16:28:02 CEST