Re: Is a function a relation?

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). Received on Tue Jun 30 2009 - 08:52:53 CEST