# Re: Function

Date: Sun, 20 Jan 2008 12:18:51 +0100

Message-ID: <47932cd7$0$85777$e4fe514c_at_news.xs4all.nl>

vldm10 wrote:

> mAsterdam wrote:

>> vldm10 wrote: >>> I think it will be good to have two definitions for the functions in >>> your glossary. >>> Definition1 A function from A to B is a rule that assigns, to each >>> member of set A, exactly one member of set B. >>> And second definition is similar to Jan's suggestion, but slightly >>> changed: >>> Definition2 >>> A function from A to B is a relation between A and B that associates >>> each element of A with exactly one element of B. >>> First definition says that a function do something. You can call it >>> intutive definition of a function. Here the function in fact is a >>> procedure as you mentioned. >>> Second definition is set theoretic. >> Another difference I see with Jan's is a sense of direction. >> >> How about this: >> cdt glossary proposal:

[snipped changed entries]

>>>> [Function] >>>> For now we have to live with different meanings >>>> of _function_ when talking about databases: >>>> "The function of this function is to get the tuples from B >>>> that are functionally dependant on A." >>>> Three different contexts, but just about the same meaning: >>>> 1. General >>>> A purpose or use. >>>> 2. Math >>>> A binary mathematical relation over two sets D and C that >>>> associates with each element in D exactly one element in C. >>>> Set D is called the domain of the function, C its codomain. >>>> 3. Software >>>> A subroutine, procedure, or method. >>>> In both the math and software context, there is a sense of >>>> direction from domain (input) to codomain (output). >>>> For most purposes, this intuitive picture is good enough: >>>> |------------| >>>> --- x ---- >| f-machine |------ f(x) ----- > >>>> |------------| >>>> Where x is input in the "f-machine" and f(x) is output. >>>> notes: >>>> every operator is a function >>>> every function is a relation

Thank you for the f-machine. It simplifies and clarifies.

> It will be good to say something about some specifics that hold true

*> for a function but doesn't hold for the relations in general.
*

There is a 'sense of direction' in the [Function] entry.

> 1) The rule "f pairs each x with just one y"

*> For example if one step on a scale then the scale will show just one
**> number. The scale will not show two or three numbers in same time. We
**> have here the law: weight = gravity x mass or y = gx. Because "f-
**> machine" compute y, we can say that y is an extrinsic property of the
**> person who step on the scale.
**> Another example for above rule is a sequence of procedures:
**>
**> ----- > f1----- > f2 ------ > ...
**>
**> The sequence is very important for the structural programming and for
**> some other sciences.
*

This however, IMO complicates without need:

'extrinsic'? 'sequence of procedures'? 'structural programming'?

> For presenting function as "f-machine" we can use:

*> Definition1 A function from A to B is a rule that assigns, to each
**> member of set A, exactly one member of set B.
**> Counter - example: In a theatre we can imagine a function from the set
**> of visitors to the set of seats in the theatre. However we can't say
**> what is the rule here. This is weak side of Definition1. We can use
**> set-theoretic Definition2, formally it is OK for this example, but
**> still we don't know what the rule here is. As far as I know there is
**> no good definition for the algorithm; usually the algorithm is defined
**> as the fixed set of rules.
*

I do not understand what you are saying here. Maybe it is a language thing.

*> 2) Construction of a relation
*

> (i) For example the following relation R ( identifier1, A1, A2) -

*> where identifier1 get values from a procedure P, and D1, D2 are
**> domains for A1, A2 - can't be constructed as the product of P x D1 x
**> D2
**> because P is not set, it is the procedure. So to construct a relation
**> we must have ready all sets.
**> (ii) The pair primary key - foreign key, can find each other by
**> matching. However m-n relationship need some third agent, usually a
**> data entry person, who will pair every pair, it can be the millions of
**> these pairs. On the other hand if we have a function, then for every x
**> the function will compute the corresponding y.
**>
**> 3) Codomain
**> The functions don't have so strict codomain as a relation. The
**> codomain of function can be a superset of the range of the function.
**> For example Bourbaki aproach to the function is based on the set of
**> all functions from A to B. Here it is better to work with a codomain
**> than with the range of the functions.
**>
**> This is longer text,
*

That's not really a problem. As it is, it is not ready for inclusion. I can't simply copy and paste it and say: this text improved (which I could with the f-machine). Did you read the 'How to contribute' part?

> but the function is really basic thing. In fact I

*> am surprise that people who are good at this field didn't write
**> anything.
*

Many are not interested.

Maybe it is good enough for the ones who are.

Bob Badour would prefer something different for
>>>> every operator is a function

if he'd care.

-- What you see depends on where you stand.Received on Sun Jan 20 2008 - 12:18:51 CET