On Tue, 31 Jan 2012 at 06:08:57, in comp.lang.javascript, Michael Haufe
(TNO) wrote:
>On Jan 31, 5:06*am, John G Harris <j...@nospam.demon.co.uk> wrote:
>>
>> But every relation can be re-defined as a function from the inputs to
>> the set {true, false}. This is what C, etc, do with the == 'relation' :
>> it's a function that returns a boolean value.
>
>Not every relation is a predicate, but I think I understand what you
>are trying to say.
I'll say it in more detail. The main, or only, part of a relation is
represented by a set of tuples, each with the same number of elements.
The elements in a tuple are the arguments or operands, whichever you
prefer to say. If a tuple is in the set then the relation is true for
those elements, if not then it's false. There is obviously a function
from tuples to bool that gives the same answer.
>This is where Mathematicians and Physicists tend to get sloppy. When
>it comes to the hand-manipulation of symbols, Math is more an
>impressionistic language than a rigorous one.
Professional mathematicians are usually rigorous, but they have an
annoying habit of switching to shorthand notation without saying so. I
suspect it's because they do it to students and expect them to work it
out for themselves, and provide the full gruesome working just once,
yawn, yawn.
>Generally you'll notice
>that the common practice is to treat single element sets and the
>single element of that set as the same thing, where clearly they are
>not and do not share the same operations:
>
>sqrt 9 != sqrt {9}
>
>One cannot take the sqrt of a set. sqrt is not defined in the Algebra
>of Sets.
I think this is more often something computer scientists do.
>So while we could step back and just say every function is simply:
>
>f : Set -> Set
>
>That lacks an enormous amount of expressiveness.
You should also use the partial function symbol, something like |-> .
Functions defined for all sets are very dangerous. (They can't be
represented by sets for a start).
>> Surely most descriptions of procedures say that they are functions with
>> no return value (void functions in C terminology).
>
>But they MIGHT return a value. They could also launch the missiles as
>a side-effect. They may not return the same value twice when called
>twice. They could also throw exceptions, or a number of other things.
>Regardless of whether the word "function" is used as its name or as
>part of the description, they clearly are not the same "function" that
>has been used mathematically or in PLs with better foundations. In
>most PLs the word "function" is more impressionistic than something of
>substance.
To put it crudely, a procedure doesn't have a return statement, so it
can't 'return' a value.
If you want to describe side effects then you have to say that the
function is from system state to system state. The input state includes
places to hold the arguments, and places holding anything else that
affects the result. The output state includes a place to hold the
result, if any, and places holding the consequences of side effects,
including the effects of an exception.
Defining just the arguments and result is only a part of the complete
description, but an important part of course.
As for launching missiles when your sqrt function goes wrong, the output
state simply has more empty missile silos.
John
--
John Harris
|
Similar Threads
