Re: Constraints and Functional Dependencies: Notation

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Fri, 02 Mar 2007 15:57:07 +0100
Message-ID: <45e83ab4$0$320$e4fe514c_at_news.xs4all.nl>


Cimode wrote:
> ...attempt at better formalism.
> ...Guess3 is correct only.

<Guess3>

You actually were looking to write:

     ∀a ∈ R,∀R(a)

, using the Set-notation ∈, element of' (Unicode 2208) sign, for something similar, but slightly different.

</Guess3>

What, in words, are you saying with

     "∀a ∈ R,∀R(a)" ?

> ... I was trying to point out some
> additional elements making the formalism closer to what math requires
> to gives one the right to exploit a definition in further
> demonstrating perspective:
>
> 1) It is preferable to express all domain of values for any element
> present in the definition.
>
> For instance speaking of R(a) or S(b) one *must* define what a, b, R
> and S. In set theory, such definition can be done in two possible
> ways : *naively* using symbols ∀, ∃, ∃!, ∈ ...(+ others such as
> include etc...) such as or *explicitely* using formal operation
> definition such as *| a = R(a) /\ S(b) = somevalue*.

                                  ∩, intersection (Unicode 2229), right?

> I personally favor the latter.
> Bourbaki's naive operators have been strongly criticized for
> some vagueness they induce in further demonstration.

Remarks like this don't help me.
Is it a sidetrack? - it doesn't look like one.

What is the gist? Do not use these: ∀, ∃, ∃!, ∈ ...? Do not use them naively? Just: use them with care?

> It was the purpose of completing the definition stated.

Back to:

 > 1) It is preferable to express all domain of values for any element  > present in the definition.

The OP stated that R and S are relations, and (not to my liking) that a and b are used both for denoting an attribute and for denoting an attribute value.

> We can use the existing attribute
> names as the names of the logic variables.

In

	R(a) レ S(b) ≡
	∀R(a): ∃S(b)| a=b

For a=b (values) to be possible, the domains of a and b (attributes) must have a non-empty intersection.

> 2) Second, math rigor dictates that a definition must be first
> expressed and systematically demonstrated (or negated).
> In other words, a definition should be considered a hypothesis and
> demonstrated thanks to set theory axiomatic (extensionnality etc...)
> and set theory operations. Only when demonstrated, it becomes
> acceptable.

I think you'll like http://us.metamath.org/mpegif/mmset.html

> ... demonstration should
> be done not using attribute based structuralism but domain based
> structuralism...
>
> In such direction, R is a relation and a is relation variable
> representing an NTuple set as opposed to current's structuralism.

A third, completely different meaning for 'a'? That, at this point, introduces /more/ possible misunderstandings instead of less.

> In other words,when using R(a) - a being an attribute, one often ends
> up with tons of undemonstrated definitions based on naive operators.
> Oppositely, defining R(x) - x being a relation variable that may
> *filled* by NTuples set values helps getting easier to demonstrate
> (mostly by equations, inequations resolutions) new definitions.

Sorry, I do not understand this. I get the feeling you are using the term 'relation variable' in a (to me) strange way - but there may be something else blocking my understanding.

> This is in no sense a conclusion but
> an observation after several hundred
> attempts going the way you described.

You mean the way Marshall described, right?

> I would be glad to share few interesting discoveries made (after tons
> of dead ends reached) but I do not want to be insulted by some hostile
> people who have a tendancy to confuse RM and RM structuralism and
> favor conservative attitudes (not to be mistaken for healthy
> skepticism) to exploration of new concepts that maybe useful for
> future computing implementations or resolving matters that are off
> limits.
>
> Sincerely hoes this makes sense. I write in English but I still think
> in French.
Received on Fri Mar 02 2007 - 15:57:07 CET

Original text of this message