Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: Dmitry A. Kazakov <mailbox_at_dmitry-kazakov.de>
Date: Thu, 1 Jun 2006 22:57:25 +0200
Message-ID: <6bxw3slwltut.1hp76mukduj5i$.dlg@40tude.net>


On 1 Jun 2006 13:07:49 -0700, Mikito Harakiri wrote:

> Dmitry A. Kazakov wrote:

>> Operations on functions (subprograms):

>
> These are easily defined in the realtional world (where we consider a
> function as a relation)
>
>> 1. Mapping (call to) the tuple of arguments to the tuple of results
>>
>>    Map : f x x1 x  x2 x ... x xN -> y1 x y2 x ... x yN

>
> Calling a function f(x,y) with two arguments x=1 and y=2 is relational
> join of three relations:
>
> 'z=f(x,y)' /\ `x=1` /\ `y=2`
>
> projected to attribute z.

Where you get z for all possible x and y? Another problem is that this is untyped. You should add some constrains on x and y. You can do it externally, but it should be a function property. The third problem is that you need "=" for all things as well as literals for all things. It is a can of worms. Especially function literals aren't easy. What is a literal of sine?

>> 2. Composition:
>>
>>    o : f1 x f2 -> f1 (f2 (x))

>
> Composition of y=f(x) and z=g(y) is relational join
>
> 'y=f(x)' /\ 'z=g(y)'
>
> projected to attributes x and z.

Same problem as before.

>> 3. Comparison
>>
>>    = : f1 x f2 -> Boolean

>
> Comparison is the symmetric difference of the two relations. It is a
> relation, not boolena value. Empty result means that the relations are
> identical.

This is non-constructive. Are you going to compare all inputs and outputs? Even if they model uncountable sets?

>> 4. Copy (for marshaling, closures etc)
>>
>>    := : f -> f

>
> Copying is not a logical operation.

It is. You should consider the computational state as an additional parameter:

":=" : f x S -> f x S

> Yet it corresponds to a trivial
> relational query that outputs the same relation.
>

>> 5. Convolution
>>
>>    * : f1 x f2 x sum x prod x inv -> sum (prod (f(x), g(inv (x)))

>
> In your description I don't see how convolution is different from
> composition.

You have some free arguments and some bound arguments. Bound arguments run through some set. It can be specified through relations, of course. Anything can be.

>> 6. Extension
>>
>> and so on

>
> What is extension?

This is when you add some prologue and/or epilogue to a subprogram. It is especially important in generic programming and for things like constructors and destructors. In general, when you want to enforce some semantics on the resulting function.

>>>> But that is rather trivial and uninteresting.
>>>
>>> Well, it's hardly trivial for numbers, why it suddenly becomes trivial
>>> for functions?
>>
>> Because in this particular case function is a value and values are outside
>> the language scope. Somewhere in the application domain exists 2. So there
>> does sine. You don't care what they are. You only need some object to
>> represent them. Let the bit pattern 0x1 represent 2 and 0x2 do sine. End of
>> story.

>
> I don't understand this gibberish.

Would "sin" be better?

>> Don't you see any difference between mathematical constructs and
>> programming language objects?

>
> Yes. Programming language objects are bastardized counterparts of
> mathematical constructs.

Right. The problem is that mathematical constructs modeled in a computational framework might be too large for any finite state machine. So an uncountable set of real numbers is replaced by a finite set of intervals. That's the gibberish in which I am talking. We can't have all the table of real-valued functions. The size of this table is aleph-2! Where you find a hard disk of this size? Fortunately, from all this table, today, I need only sine. So I say let sine be denoted as 0x2.

Nevertheless, nothing prevents us to formalize these bastards and use mathematical rigour to handle them. Disagree?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Received on Thu Jun 01 2006 - 15:57:25 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US