Re: Object-oriented thinking in SQL context?

On Jun 10, 10:53 am, paul c <toledobythe..._at_oohay.ac> wrote:
> David BL wrote:
>
> ...
>
> > I know Russel's paradox. ...
>
> Sorry, I forgot to say I don't think you do.

I'm guessing that your "issues" have to do with recursive types. I don't put much credence in your understanding of that subject matter (e.g. given your posts in Jan 2007) relating to the following definition by Bob:

    A = { a1, a2, a3, a4, a5 }
    B = { {a,b} | a in A and b in B }

Note that B = {} is consistent with the definition. It is not immediately clear to me whether B is ill-defined. There cannot be any element of B with a finite number of "nestings" of sets within sets, because otherwise we can easily obtain a proof by contradiction as follows: Let x be an element of B with the smallest number n of nestings. Then x = {a,b} for some a in A and b in B. It follows that b has n-1 nestings, which gives us a contradiction.

BTW Bob assumed {} was an element of B, which is obviously incorrect because by definition all elements of B must be sets with two elements.

I concluded that Bob failed to correctly give a recursive definition of a type, and you were unable to realise it. In fact you even seemed generally confused between the distinction of value and type.

Any decent mathematician knows that the right way to understand recursive types (or sets) is to understand its relationship to the principle of mathematical induction. Inductive definitions need a starting point as well as the inductive step. For example, the fibonacci sequence can be defined by two rules:

1. The first two fibonacci numbers are 0 and 1
2. Each remaining number is the sum of the previous two.

Are you going to continue blowing your own trumpet? Received on Wed Jun 10 2009 - 11:19:20 CEST