Re: Expressions versus the value they represent
Date: Sun, 11 Apr 2010 23:37:18 -0700 (PDT)
Message-ID: <8a4d1c2f-0ba9-4c9d-a939-3db2eb9d8897_at_g30g2000yqc.googlegroups.com>
On Apr 12, 1:13 am, David BL <davi..._at_iinet.net.au> wrote:
> I recommend the articlehttp://en.wikipedia.org/wiki/First-order_logic
> when reading this post.
First a general point about communication. When one is trying to write a post with such an "air" of formalism and precision, then it is especially important to hold to accepted formal vocabulary. Otherwise we end up with a jumble of formal sounding arguments mixed with just enough ambiguous "everyday-man" language to sow confusion and instantiate the Principle of Incoherence.
For example, below we find phrases such as "/returns/ an abstract circle", "/become/ functions", "/play around with/", "only /seen/ for abstract values", etc (where I've highlighted the particular words in question) which at worst are entirely meaningless and incoherent and at best ambiguous.
> In FOL the expression circle(point(0,0),1) is called a /term/. It is
> actually a ground term because there are no variables. It is NOT a
> circle! circle and point are /function symbols/ of arity 2. 0 and 1
> are function symbols of arity 0. Terms can nest (e.g. 0, 1 and
> point(0,0) are all terms).
That is a contradiction. You claim the term circle(...) is "NOT a circle!" then immediately claim that a "circle [is a] /function symbol". Note that in both claims you used the 6 letters "circle".
> The term ellipse(point(0,0),1,1) is distinct from circle(point(0,0),1)
> even though we may regard them as both encoding a unit circle.
What is the point here? If we are talking about a multi-sorted FOL then those two terms have distinct types. If either is equal to some other expression say "UnitCircle()" or whatever, then that must be derivable from the stated axioms and type definitions.
> In FOL one distinguishes between a term and what it encodes under an /
> interpretation/.
No it's more than that. Interpretation is /orthogonal/ to FOL. The extent to which FOL distinguishes is only to state that "FOL says nothing about the business of interpretation".
> Under an interpretation function symbols become
> functions. For example, let circle(c,r) be a function that maps point
> c and number r to a circle centred at c with radius r. i.e.
>
> circle(c,r) = { (x,y) in RxR | (x-c.x)^2 + (y-c.y)^2) = r^2 }
What does "become functions" mean? Anyhow, interpretation is orthogonal and therefore irrelevant to both FOL and RM.
> Terms can be seen as a way to encode values that would otherwise be
> impossible to directly represent on a computer. E.g. a circle is
> uncountably infinite.
That would be conflating the logical and physical layers, a problem we've all seen far too many times. Yes, terms can be thought of as having a type and some extension. However, that extension need never be enumerated, nor have it's structure defined, nor be represented on a computer, nor anything else stated about it (besides existence) apart from any type definitions and other axioms. At least as far as /theory/ goes. Creating a computerized or imagined implementation is a separate physical concern.
> What interests me here is the question of whether or not it is
> appropriate for a formalism underlying database theory to distinguish
> between terms and the abstract values they encode under
> interpretation. At stake is the ability to express ideas such as the
> following clause in Prolog, which states for example that the term 3+4
> should be simplified to the term 7:
>
> simplify(X,Y) :- Y is simplified version of X
> simplify( plus(num(X), num(Y)), num(X+Y) ).
>
> Obviously one cannot satisfactorily manipulate expressions if they are
> only seen for the abstract values that they encode.
Well fortunately the RM does not "see" them as abstract values. It "sees" them in exactly the same when they are "seen" in FOL, as terms, as expressions, they may or may not have a type. So, we are in luck: the RM does not in any way limit the expression of such clauses.
> I note that a D&D /selector/ for type CIRCLE is like a function that
> returns an abstract circle value (e.g. already interpreted and ready
> to be stuck into a relation).
A selector does not "return" a value. It /denotes/ or /selects/ a value. And again this value is not interpreted in the RM because interpretation is orthogonal to both FOL and RM.
> It seems implicit with the RM that there is no concept of interpretation
Yes exactly, just as in FOL interpretation is orthogonal.
> (or putting it another way, interpretation has already taken place).
Non-sequitur. That something defines no concept of A does not imply that "A has already taken place".
> A relation or tuple value encodes nothing other than itself. So to
> for the attribute values of any given tuple.
Correct. Just as a FOL clause "encodes nothing other than itself". Interpretation is left to some other formal semantics system.
> One of my main motivations here is to question the whole premise
> behind RVAs, which I have assumed are used to /encode/ attribute
> values within parent relations. I don't believe the RM should be
> allowed to play around with interpretation after the fact. Having
> multiple phases of interpretation seems extravagant, unnecessary and
> ill defined to me. I think FOL can encode all imaginable data types
> effectively using nothing more than nested terms with a single
> interpretation step.
>
> The FOL distinguishes between function symbols and predicate symbols.
> Under interpretation a predicate symbol becomes a boolean valued
> function, which is the indicator function of some given relation. If
> this is how the RM is meant to fit into the picture then it seems
> inappropriate to use relations to somehow encode the values that are
> normally encoded by FOL terms.
Hopefully we can agree that since there is no interpretation defined in the RM nor FOL that there are not "multiple phases" nor "playing around" nor any other of the problems above.
KHD Received on Mon Apr 12 2010 - 08:37:18 CEST