A scientific or mathematical discourse concerns itself with entities
external
to the text (e.g. an electron or a circle; or equally the
meaning
of some ((typically) other) text); the discourse describes
relationships among the external entities. To simplify the description of
relationships, context may provide names for some entities; were a text within
the discourse describes a relationship among external entities, it does so by
associating names with the external entities so related and making some
statements
employing those names; the reader notionally
substitutes
the extenal entities in place of the names, in the process of
reading meaning into the text, so that the text's meaning says things
about
the external entities, thereby characterising the relationships among
them. The text of the statement may also, of course, use names to which that
text itself gives meaning; and names to which the discourse's context has given
meaning.
There may be arbitrarily many external entities (hence names) involved in a
given relationship and there need not, necessarily, be any intrinsic
order
to the names. Generally, one endeavours to break down
relationships in some way that ensures the namespaces are not huge; and one does
not tend to think of the text as describing a relationship
unless there
are two or more names involved. The degenerate case involving no external
entities is simply a statement; that involving just one amounts to a
specification of a property that an entity may have.
Where the namespace involves many names, one can employ the following trick
(due to Haskell B. Currie): select one name, pretend it is n
; interpret
the relationship's text as if n's meaning had been supplied by context; this
reads it as a relationship among the entities associated with the remaining
names; call this the curried
relationship. We can now construct a
two-name relationship using n
and some name not otherwise used in the
text, pretend m
: in so far as our original relationship's text holds true
with some particular meaning for n, our two-name relationship relates this
meaning to the curried relationship, m, obtained by having context provide this
meaning for n in the original relationship. By this means we can describe any
many-name relationship as a two-name one, one of the names in which expects to
mean a relationship with one fewer name – which can again be described as
a two-name relationship either because it is one (we started with a three-name
one) or because it still has many names; many
, for these purposes, means
more than two
. Thus we can encode all relationships using relationships
with at most two names each.
This process obliges one, when encoding a many-name relationship, to select
an ordering of the names; so one may as well use the ordering to describe
two-name relationships in terms which don't attend to the names used. I'll
define a relation to be a two-name relationship accompanied by
a choice of order among the two names; and say that r relates x to y
whenever r is a relation and, when x is used in place of r's first name with y
in place of the second in the text of the two-name relationship, the statement
thus made holds true.
We can also describe any one-name relationship
as a relation which
relates a to b if a and b mean the same thing and the relationship holds true
when that meaning is used in place of its one name. If we really want, we can
even describe a no-name relationship, i.e. statement, by a two-name relationship
which relates x to y, regardless of the meanings of x and y, precisely if the
statement is true. For many-name relationships, we can use Currie's trick; by
convention, I'll take the name selected at each step as the last
(or
rightward) name of the two-name relationship at that step (see below). This enables us to describe all relationships in
terms of relations.
There are other ways of encoding relationships, some of which I shall use: but the tools needed to do so can be built using relations. For example, one can encode a relationship, R, as a collection of mappings, each of which, f, is a mapping from R's names to meanings, one per name; for which R's text reads true when each name is replaced by f's meaning for it. But for that, one needs collections and mappings.
The way evaluation of functions
is (orthodoxly) written has
g(f(x,y))
call for x to be passed to f as in input, followed by y, and
for f's output to be passed on to g. Thus functions are evaluated in
right-to-left order while inputs are supplied in left-to-right order; keeping
subtexts near to the subtexts they are most closely involved in (and having
(f(x))(y) and f(x,y) equivalent) obliges argument-supply and function-evaluation
to read in opposite orders.
When g or f is replaced by some substantial text which denotes a function,
it will be easier for readers to follow what is happening, in function
evaluation, if the rightward end of each function's text discusses its input
– which appears to the right of the function when it is evaluated –
and the leftward end of each function's text discusses its output, which will be
needed by a function applied to its left – i.e. after
it
in evaluation order. So, in support of right-to-left order for evaluation,
texts I'll use to denote mappings (which will be my approximate equivalent of
othodoxy's functions) will discuss output at their left-ward end, input at their
right-ward end.
Such texts will be particular uses of denotational templates which will, in
general, denote relations; now r(x) lacks an orthodox meaning when r is a
relation, so I'm not obliged to tie standard reading of relations to the
unavoidable reversal implicit in function evaluation
, or to my consequent
right-to-left reading of mappings. Given that the flow of text, as I write it,
is left-to-right, I chose to read relations in that order: a relation relates
its left values to its right values, though reading the relation as a mapping,
if it is one, we find it maps its right values to its left values; so, as a
relation, a mapping relates its outputs to its inputs.
Mappings decidedly care about being read from right to left; relations are
less fussy; so where a relation relates one value, x, to another, y, I'll
indicate this using the token ← (which might conceivably display as a
left-pointing arrow) with x on its left and y on its right; as far as reading a
text as a relation goes, x ← y
just says the relation relates x to
y; but when the relation is given to be a mapping, x ← y
says y is
mapped to x – i.e. that there is only one value the relation relates to y,
namely the given x.
One case in which I shall use Currie's encoding is in the description of binary operators. In general a binary operator is really a three-name relationship: it combines two values to produce a third. Given the above order for mappings, c = b*a can be encoded by *'s associated relation relating c to a relation which relates b to a. This maps, to each possible composite, c, the relation (: c = b*a; b←a :), which looks like it offers an interesting (if unorthodox) perspective…
Equally (and more orthodoxly), for any a, we can identify the mapping which maps b to a*b for each b for which this is defined: thereby identify the mapping, call it s, which yields this as output when given a as input; which clearly also encodes *, this time as a relation which relates s(a) to a, wherein s(a) relates a*b to b; when s(a) is a mapping, a*b = s(a,b).
Inevitably the two descriptions are equivalent – via permutation operations the determined reader can build out of transpose and reverse – and I may well exploit both. The second description (is more (familiar and) orthodox and) has practical virtues which make it my preferred encoding of the binary operator.
An expression using a binary operator, *, denotes the result of combining a with b as a*b. One may use an arbitrary relation, star, to define a binary operator, *: the expression a*b then asserts that star relates, to a, some relation which relates, to b, some value, c; and a*b denotes an arbitrary value c for which this holds true. When * is then used to define ({non-empty relations}: (: a*b ← b :) ← a :), call this s, the relation (: a*b ← b :) = s(a) is the union of the relations which star relates to a (whenever at least one such relation is non-empty): star and s encode the same 3-relationship, but may encode it as distinct relations.
Two no-name relationships immediately arise, corresponding to the statements
false
and true
: these I encode as relations empty and all;
empty relates x to y
iff false
; all relates x to y
iff
true
; i.e.
I encode a one-name relationship as a relation which relates x to y precisely if x and y mean the same as one another and, when that meaning is substituted for the single name of the relationship, the resulting statement holds true. The one-name relationship which is false regardless of what is substituted for the name is thus encoded by empty – it doesn't relate anything to anything.
The one-name relationship which holds true for every meaning gives us a
relation for which the name the universal identity
is appropriate: it
relates x to x for every meaning x but otherwise doesn't relate anything to
anything; it subsumes the encoding of any one-name relationship; any relation,
r, that it subsumes may be interpreted as an encoding of a one-name relationship
– namely, using name n
, r relates n to n
. So relations
subsumed by the universal identity are synonymous with one-name relationships,
a.k.a. unary predicates
; I call their encodings collections
(which
correspond loosely with orthodoxy's sets).
A classic paper on representing information as relationships: Codd's paper from June 1970's
Communications of the ACM, A Relational Model of Data for Large
Shared Data Banks.
Written by Eddy.