Date: Sun, 20 Jan 2008 12:18:51 +0100
> 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.
> 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
> 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
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