Re: Is a function a relation?

"David BL" <davidbl_at_iinet.net.au> wrote in message news:581b4f12-2a79-4bee-a297-e08718d00b6b_at_y17g2000yqn.googlegroups.com...
> On Jun 30, 11:46 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
>> "David BL" <davi..._at_iinet.net.au> wrote in message
>
>
>
>> > I disagree. Variables can have many distinct ways of being
>> > reassigned. This can be modelled by representing changes to variables
>> > as values of various types!
>>
>> Can you please elaborate?
>
> What I mean is that the various changes which can be made to a given
> variable of a given type can be regarded as mathematical objects (i.e.
> values of various types) which I later referred to as operations.
>
>
>> > Let the execution of operation O on state S result in state S' denoted
>> > by S' = S+O. In the OT literature two concurrent operations O1,O2
>> > that are applied on the same initial state S are said to be equivalent
>> > if S+O1 = S+O2. This is not a sufficient condition for O1=O2.
>>
>> I'm cringing a bit here. This reminds me of the problems associated with
>> Sql Server replicating updates as delete/insert pairs.
>
> I think you have misunderstood. I'll repeat my last sentence above:
> This is not a sufficient condition for O1=O2. An update operation is
> not equal to delete+insert.
>
>
>> > This formalises the sense in which it is possible to say that delete,
>> > insert and update can be equivalent to assignment, but not the same as
>> > assignment.
>>
>> I'm cringing again, because this implies that descriptions must be rigid
>> under the intended interpretation. I think that in order to be
>> equivalent,
>> the result has to be not just the same syntactically, but also
>> semantically.
>
> I have no idea what you mean. When I say "equivalent" I simply mean a
> particular equivalence relation can be defined. That in turn just
> means a relation that is reflexive, symmetric and transitive. It
> turns out that an equivalence relation can be defined on operations
> O1,O2, according to the requirement that they act on the same initial
> state and produce the same final state, but in the OT literature this
> is not regarded as a definition of when two operations are equal, but
> instead only of when they are "equivalent".
>
>
>> > When someone uses a debugger to view values of integer variables on
>> > the stack frame, are you saying they aren't variables, or that they
>> > don't exist in time and space?
>>
>> Now you're talking about a physical manifestation of the abstract.
>
> I have no idea what you mean by that and why. There are two different
> kinds of abstractions:
>
> 1) Formal mathematical objects that don't exist in time and space.
> E.g. the integers.
>
> 2) Informal abstractions over the physical which are objects that are
> deemed to exist in time and space. E.g. a human, or a relation
> variable on a real computer.
>
> You appear to be saying that variables cannot be of type (2) because
> they hold values of type (1). Why exactly do you think that is a
> problem?
>
>> I don't know about you, but the right hand side of the assignment,
>>
>> PQ := RELATION { TUPLE { P# P#('P1'), QTY QTY( 600) } ,
>> TUPLE { P# P#('P5'), QTY QTY( 500) } ,
>> TUPLE { QTY QTY(1000), P# P#('P2') } ,
>> TUPLE { P# P#('P4'), QTY QTY( 500) } ,
>> TUPLE { QTY QTY(400), P# P#('P3') } ,
>> TUPLE { P# P#('P6'), QTY QTY( 100) } } ;
>>
>> From page 153, TTM 3rd Edition, looks to me like a relation that just
>> sprang
>> into existence!
>
> No. The rhs of that assignment statement is only selecting a relation
> value, not causing the value to exist (and implying that it didn't
> exist previously). Your position is metaphysical because it doesn't
> make any measureable predictions that can be falsified.
>
> Would you say
>
> x := 5;
>
> causes the integer 5 to spring into existence? I would say that the
> rhs simply refers to one of the integers, and not even talk about when
> or where that integer exists (which is just a waste of time).

I think that there is a misunderstanding here about formality and about the difference between ordinary and abstract objects. I hope that the following will clear a few things up.

I accept as an axiom that there are objects that can have a location in time or space. To formalize this, let C! be a 1-place relation that ranges over the objects in the Universe and expresses the property of having a location in time and space--that is, being concrete. Given C!, the properties of being ordinary, O!, and being abstract, A!, can be defined. Only those objects that can have a location in time or space are ordinary, and those are exactly the objects that possibly exemplify C!; every other object is abstract and as such cannot have a location in time or space, and the abstract objects are exactly the objects that don't possibly exemplify C!.

The integer 5 is an abstract object. Abstract objects do not actually exist: they just are. Under the Domain Closure Assumption, the only objects that actually exist are those that exemplify C! and are represented in the database, but that doesn't mean that abstract objects can't be discussed: it just means that the quantifier forall ranges over every object that can possibly be, which includes all objects that cannot have a location in time and space, all objects that can, but don't, and all objects that actually do. It is a consequence of assuming a fixed domain of quantification for actual existence to be expressed as a predicate--call it E!. Obviously, E! implies C!.

In contrast to the assignment of the integer 5, which as an abstract object does not exemplify C!, for the assignment to PQ to succeed, due to the Domain Closure Assumption the objects that each tuple in the relation maps to must exist--that is, they must exemplify E! which implies that they must exemplify C!. In that sense, the assignment of the relation asserts the existence of the objects that its tuples map to, so it's not that much of a stretch to say that the relation just sprang into existence. Of course, all of this assumes that the user making the assertion is not lying or mistaken. Received on Wed Jul 01 2009 - 19:15:49 CEST