Re: Function

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:

>>>> [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.