]> Plaintext Denotations

Plaintext Denotations

Context I discuss elsewhere. The following will, in places, differ from what I have used outside the new tidy area; I've been more brutal about the order of terms in various texts, and I'm exploring the use of equivalences as infrastructure for manipulating ambiguity.

In widespread support of handling ambiguity and equivalences, I'm generalising in, which relates each member of any collection to that collection, to have any relation in place of the collection, primarily so as to allow that a value is in an equivalence precisely if it's in the equivalence's collection of admissible values. Like Humpty-Dumpty, I declare a meaning for in and presume that meaning for it thereafter: a in A means A relates a to a, a.k.a. a is a fixed point of A. Since I'll encode collections as relations which relate each member to itself, this will carry over its meaning for collections transparently. In many of the contexts where I have used collections in the past, I now support arbitrary transitive reflexive relations (most notably equivalences), indicating the collection of values thereof while asserting that the context respects (and is oblivious to) the relation in relevant senses. The end-collections denotations of relations have become end-relations (via a period as end-equivalences, now – since 2004/June – generalised via subsumes) and, in various contexts, I provide for an arbitrary relation to tacitly provide one of its end-relations as a transitive reflexive relation.

I've also settled on a choice of language: for the sake of composition in a context where a mapping, f, maps x to f(x), texts which denote mappings shall discuss their outputs on the left and their inputs on their right. If f's inputs are the members of some collection, A, and its outputs are all in some collection Z, f will be synonymous with (Z: f(x) ←x :A), which relates f(x) to x yet maps x to f(x). I've now sorted out this tidy zone's use of ← rather than -> or →, but shall leave writings elsewhere alone except in so far as either I'm changing them for other reasons or I have copious free time.

Contents

… with illustrations of the most prominent denotations introduced:

thing is [{ a; an }] mode, thing [ isa mode …]
Templates and meta-denotations, styled words and punctuators, types and isa. See also my discussion of formalised natural language.
this = that, r < t in T ⊂ S, f(x), f(a,…,z)
Expressions with assertions.
left ← right, {quick x: x in C}, &unite;, &intersect;, &on;
Relations, fixed points, sub-… and some combinators.
(A:f:B), (:f:B), (A:f:)
(:f|), (|f:), (|f:B), (A:f|)
(A|f:B), (A:f|B), (A|f|B), (|f|B), (A|f|)
End-relations and restrictions of relations, optionally with assertions.
[], [x], [h,i,j,k], [a,…,z]
Lists
x+y.z, a×b − c·d, e\f ± g/h
Arithmetic and its binary (and unary) operators

Meta-denotations: the language of templates

Each of my definitions of denotations comprises a template and accompanying explanative text. The template specifies a way of combining texts, some given verbatim, others indicated by tokens to which the explanative text refers, stating any constraints on the fragments which may be used in place of those tokens and specifying the meaning of the composite in terms of the meanings of the components. [I try to design templates that someone writing a parser would find useful.] Aside from any ambiguity the definition explicitly introduces or resolves, any ambiguity in the fragments combined (potentially) propagates to the composite: it means each of the meanings it could be given by replacing each ambiguous fragment with any of the meanings it could have consistently with the definition's constraints.

In templates, and where explanative text refers back to a fragment using the following, I'll use text style to distinguish the rôle of sub-texts. Words & punctuators, in this style, (hopefully bold if I got my CSS right) are text to be included verbatim in any use of a template – folk (and programs) reading the text need to be able to recognise the denotation by the appearance of these verbatim fragments. Everything else in a template will be in this style (hopefully italic) and will describe the sub-texts that must appear in conjuction with the verbatim fragments:

Note that one is not expected to use these styles in texts which use the template: I merely use them as a means of expressing the template. At least one browser I've used fails to display (plain) | distinct from (bold) |, others may have similar problems – sorry about that, but you can always read the source (the mark-up is only as fiddle-some as the meaning requires) if you can't work it out from what you browser does display.

Types

For the purposes of giving meaning to templates, it is convenient to package some of the assertions I must make about context giving meaning to some texts, possibly a priori to my definitions. To this end, I'll use the following denotations:

mode is a type

Allow that context may give meaning to this is that as a synonym for this = that: mode is a type asserts that context gives some other meaning (which I'll generally presume to conform at least reasonably well to orthodox and colloquial notions of type) to statements of form thing is [{ a; an }] mode. (The choice between a and an is a cultural issue, not covered here, dependant on the natural language known as English.)

this isa that

Asserts that that is a type and denotes the statement of form this is [{ a; an }] that by which context gives that meaning as a type. In particular, this isa that emphatically does not mean this = that (though it does not preclude the possibility that this = that).

Note that, in the present context, type is a type (so type isa type and type = type); furthermore, the way I formalise use of any leads to: for any type t, any t isa t; in particular, any type is a type.

Each use of a name in a formulaic text requires its context to provide that name with a value; by default, each denotational template propagates this requirement, from the sub-texts it combines, to whatever text is using the compound as a sub-text. However, a denotational template may specify that each compound text it describes may quantify over or quantifies over names used in some of its components, in so far as context has not provided them with values.

For each use of each name, we can identify the smallest text around that use for which that use appears within one of the may quantify components of the denotational template describing the given formula (i.e. the first step back up the parse-tree at which the name can be quantified) or; call this sub-text a value-provider for that use of that name; if this is a sub-text of the value-provider for some other use of that name, call it a forwarding value-provider of that name; each use of each name then appears in a unique non-forwarding value-provider for that name; which quantifies over that name. Only {} denotatons for collections, denotations for relations and [for] {a;an;any;some} … texts do quantify over any names.

Expressions with assertions

left [ { = ; } right …]
Equality

in which left and each right must be (texts denoting) values; this denotation asserts that all those values are equal; and denotes that value.

Note that context is presumed to be providing the notion of equality – it is entirely at liberty to be using some equivalence, Q, and writing modulo Q, x=y to express Q relates x to y: when all comparisons in some context are to be made in terms of Q, the whole text may provide equality is understood modulo Q and thereafter use x=y in place of Q relates x to y; this is particularly handy if Q is not expressed by a nice terse name but by some more convoluted text, such as one would sooner mention once than repeatedly. Although x=y may then be ambiguous, the ambiguity is invisible to Q – the values it can denote are all related to one another by Q.

Where context mediates equality via some such equivalence, it is sometimes necessary to indicate that some values are the same, even without that equivalence. The notion of sameness here shall ultimately relate to an equivalence implied by some broader context; this shall usually be equality as relations provided by my general formulation of mathematics; when it is anything else, I shall (endeavour to remember to) specify what. When such sameness needs to be denoted, I shall use in place of = to indicate the distinction. In a chain of equality assertions, if any of the links uses = then the chain, as a whole, denotes the value only modulo any relevant equivalence, such as Q above; but if all links use then the chain as a whole denotes its value only modulo the implicit equivalence from external context (i.e. it denotes the value more specifically).

value compare value [ compare value …]
Comparison

in which each value must be a (text denoting) a value; and each compare is a symbol or word (e.g. <, ∈, ⊂, in, subsumes or isa) to which context has given meaning as a relation to be denoted using this form. Asserts that each compare relates the value on its left to the value on its right. Does not denote a value.

relation ( [ early , …] last )
function invocation, generalised suitably.

Each early, if any, and last must be expressions denoting values; relation must be an expression denoting a relation.

If [ early, …] is omitted, this simply denotes an arbitrary value which relation relates to last and asserts that there are some such values (i.e. that last is a right value of relation).

Otherwise the text used in place of [ early, …] is of form first,, late, – including the trailing comma – and our given relation([ early, …] last) stands for any value related to last by any relation denoted by relation(first, , late) and asserts, as before, that there is some such value, i.e. that some such relation (exists and) does have last as a right value. Note that this specification is recursive.

Orthodoxy uses such denotations where there's only one such value – i.e. the denotation is unambiguous. For f(x), such uniqueness is exactly what f is a mapping guarantees us; and mappings describe their right values as inputs, left values as outputs, so the value to which a mapping f maps an input x is indeed the output f(x). Further, when f(x) is a mapping and accepts y as input, f(x,y) is the resulting output; which, if it is a mapping and accepts z as input, yields f(x,y,z) as output; and so on. However, I don't require uniqueness as a pre-requisite for using such denotations: nor does unambiguity of f(x,y) necessarily prevent f(x) from being ambiguous – provided there's only one value to which any value for f(x) does relate y. In particular, (: r(x) ←x :) = r shall be fatuously true for every relation, r – not just for the mappings.

[type] [ [ expression , …] expression { , | or | and } ] expression [ compare value ]
type-plural [ compare value ]
expression sequence

The second form is syntactic sugar; type-plural must be the plural noun (as provided by natural language) for values of some type; replace it with that type as type and a single expression comprising a name not used anywhere else; the second form is thus transformed into a special case of the first.

In the first form, each expression must be either the literal token or an expression denoting a value. A use of must either be preceded by or be followed by a value-denoting expression; it stands for further expressions whose form should be clear from context and the value-denoting expressions adjacent to the (i.e. those immediately before and after it, in so far as there are any such); for example, where recent context has enumerated an expression sequence, a subsequent expression sequence may repeat the first (few) and last (few) and replace the rest with to save overtly repeating the others; or an expression sequence whose entries are all of a common form, with some regular variation among them, may be expressed by a few of those values and a indicating the rest, to be inferred by continuing the regular variation as often as may be (indicated by context or) appropriate.

Each expression denoting a value may quantify over any names used in it. In so far as an expression (either overtly given or implied by a use of ) takes a value or quantifies over any names: any constraints, implied by using the given expression in place of e in the following, are imposed. If supplied, type must be a type; its presence asserts e isa type for each expression e. If compare value is supplied; any text of form value compare value must match the comparison template above; and it asserts, for each expression, e, that e compare value.

If the final separator between expressions is and, the expression sequence introduces a context, in which all expressions are constrained to have values; if the final separator is or, the expression sequence denotes any value which any given expression may take; otherwise, unless context indicates the former reading (e.g. by wording such as all of before the expression sequence sub-text), the latter is implied.

In the or case, context (external to the expression sequence sub-text) must discard any constraint (that it would otherwise impose) which: involves any name only quantified over by unused expressions; and involves no name quantified over by the expression we are using. (Thus any positive s, t or 1 with s+t = 1 may take the value 1 even when natural or integer is implicit in positive, causing s+t = 1, a constraint outside the expression sequence, to be unsatisfiable.) Unused expressions – and, in particular, the constraints implied by their presence – are ignored in so far as the non-ignored expressions (used and unused) suffice to quantify over all names not provided for by context but referenced in constraints which are not discarded by the fore-going. (Thus any positive f(s,t), s or t with s+t = 1 can still take any value of any positive s or t with s+t = 1 even if s is not a right value of f, t is not a right value of any f(s) or no f(s,t) is positive.)

Note that this may require care when writing constraints: any positive f(x,y), g(y,z) or h(z,x) with x<y<z can only exploit its h(z,x) in so far as there is a y strictly between x and z for which at least one of f(x,y) and g(y,z) is defined and positive; if f, its outputs and g accept integer inputs, this requires x+1 < z, which might not be what was intended; the result need not coincide with that of any positive f(u,v), g(u,v) or h(v,u) with u<v.

Relations

[[ constraint , …] constraint ; ] left right
left right [ ; constraint [ , constraint …]]
arrow formulae

in which left and right are expressions – which may involve names – and each constraint, if any, is a constraint. [In older texts I have used a , where the first template mandates ; to make reading easier … 2001/May/27. I am now exploring putting the constraint after the template … 2002/Jan/7.] The whole denotes a relation, which relates each value left may take to whatever value right may take, subject to all pertinent constraints. The composite may quantify over names for which any of its sub-texts (left, right and any constraint) require context to provide values.

Thus, for instance, f(x) ← g(x) denotes the result of composing f (which is f(x)←x) to the left of (i.e. after, when f and g are mappings) the reverse of g; the latter being x←g(x). Most usually, however, right will be a simple name; left will usually be some formula involving that name; though not uncommonly both will be simple names, with some constraint to specify the details. Almost invariably, ← denotations will be enclosed in (:…:) if in nothing else: for reasons which shall emerge below, this is fatuous, but the enclosure is often an aid to reading.

{ [ expressions [ : constraint [ , constraint …] ]] }
formulaic collection

in which (in so far as each is given): expressions must be an expression sequence, as above (in or form, generally implicitly, with optional type qualifiers and filtering) and each constraint must be a constraint. Each member of the collection is a value of expressions subject to any constraint. Note that everything inside the { } is optional, so that { } is a collection: there being no expressions, no value is a member of this collection, so { } denotes the empty collection. [I'll more usually write empty as {} without the space inside it; or call it by its name, empty.]

A formulaic collection implicitly quantifies over all ambiguity in the value of expressions. Note that use of expression sequences provides for an implicit union, i.e. {a, b: a in A, b in B} stands for the union of (the collections of fixed points of) A and B, even when B is empty – as noted when discussing expression sequences – requiring enough slack to ignore a constraint which doesn't involve a, even indirectly, while evaluating the expression a in the sequence.

relation &unite; relation
relates x to y precisely if either relation does.

relation &intersect; relation
relates x to y precisely if both relations do.

This and the previous, &unite;, denotation correspond to mappings, intersect and unite respectively, which can be used to combine arbitrarily many relations rather than just the two combined here.

left &on; right
Composition (the &on; should be a bold (i.e. literal) &on; but I seem to lack the right fonts for that).

This relates x to z precisely if there is some value, y, for which left relates x to y and right relates y to z. Notice that y need not be unique.

When both left and right are mappings, this is the usual composition of mappings: formally, (f&on;g)(z) is f(g(z)); f relates this to g(z), which g relates to z. Note that I require the enclosure here used around f&on;g to distinguish this from f&on;g(z), which I intend to be read as synonymous with f&on;(g(z)), which relates f(g(z,y)) to y – i.e. maps y via g(z,y) to f(g(z,y)) – whereas (f&on;g)(z,y) is f(g(z),y).

Note that I am here using character entities which are not a standard part of the normal HTML repertoire: I shall not remember that &#8746; is the unicode symbol for union, nor would a reader viewing that token as such (if their browser fails to correctly display ∪) have any clue that it means unite; so I type &unite; and rely on a DTD hack to make this display as ∪ where supported. I have, thus far, only tested that Opera 8, and later, copes with the result (and it has trouble with bold &on; where used): it is possible other browsers will have problems with this. Please let me know if so …

End-relations

( | relation : )
Relates a to c precisely if {i: relation relates a to i} subsumes {i: relation relates c to i} and neither is empty. The final condition makes this a relation among the left values of the given relation; I call it the left-relation of the given relation.
( : relation | )
Relates a to c precisely if {i: relation relates i to a} subsumes {i: relation relates i to c} and neither is empty. The final condition makes this a relation among the right values of the given relation; I call it the right-relation of the given relation.

I'll extend these, below, to allow other things in place of the : or in addition to it: these constrain relation. Collectively, I describe each of these as an end-relation. Because subsume is transitive and reflexive, so are end-relations. Consequently, intersecting one with its reverse necessarily yields an equivalence; I'll refer to these as end-equivalences, variously the left-equivalence and right-equivalence. When e is an end-relation, I'll refer to values as e-equivalent if e relates each to the other. Since an end-relation is reflexive, its values are fixed points, hence in the end-relation; thus, for given relation r, {right values of r} = {x in (:r|)} and {left values of r} = {x in (|r:)}; I'll call those the end collections of r.

Prior to 2004/June, I defined these two denotational forms to denote the end-equivalences, rather than end-relations themselves (and a whole lot earlier than that, I used the same forms to denote the end-collections); and defined the conformance notion below in terms of those – there may yet be ghosts of that in texts here. I also transiently had the right-end relation defined reversed during July 2004 – hopefully I've fixed that, though.

Restrictions

( [ left ] : [ relation ] : [ right ] )

in which left, right and relation, if present, are relations. A text matching this template denotes a relation. Let P = relation if present, else P is an arbitrary relation. If left is present, let L be its right-relation; else let L be (|P:). If right is present, let R be its left-relation; else let R be (:P|). The whole denotation then stands for L&on;P&on;reverse(R).

In particular, this relation's left values are all right values of left and its right values are all left values of right; when these are collections, the result is simply to restrict relation by imposing these requirements on its left and right values. For any relation P, ((|P:):P:reverse(:P|)) is necessarily equal to P.

When relation is absent (so that P is arbitrary) the whole denotation stands for an arbitrary relation between the right values of left and the left values of right, respecting their respective end-relations and subject to any further constraints imposed by context. For example, {mapping (B::A)} means the same as {mapping f: f = (B:f:A)}.

I used to define this denotational form purely as the restriction to relevant collections of values, without composing the relevant end-relation; that led to (:i←i:r) and (r:i←i:) denoting the end-collections; some texts may still use this form, which no longer reliably means this.

( | [ relation ] : right )
= (| (: [relation] :right) :)
( left : [ relation ] | )
= (: (left:[relation]:) |)

These two merely incorporate a constraint, as above, into the end-relation denotations.

Restrictions and end-relations with assertions

I now introduce variations on the restriction denotations above in which a : between two relations may be replaced with a | to assert (without changing the relation denoted) a relationship between the end-relations facing one another across the |. The asserted relationship is encoded, for transitive reflexive relations e and c, as e conforms with c iff (e:c|) subsumes c and e subsumes (e:c:e). Note that neither e nor c necessarily subsumes the other, all the same. Crucially, any reflexive transitive c conforms with itself and with {x in c}; and any collection, e, conforms with c if (e:c|) subsumes c.

( [ left ] : [ relation ] | right )
( left | [ relation ] : [ right ] )
( left | [ relation ] | right )

All three denote the same relation as ([left]:[relation]:[right]), but each adds assertions wherever that uses a : in place of a | in this template.

In the first form, the assertion is that ([left]: [relation] |) conforms with (|right:); in the second form, the assertion is that (| [relation] :[right]) conforms with (:left|); the final form makes both of the given assertions. Likewise …

( left | relation | )

Denotes (left:relation|) and asserts that (|relation:) conforms with (:left|).

( | relation | right )

Denotes (|relation:right) and asserts that (:relation|) conforms with (|right:).

Note that no provision is made for denotations of form (|r|) with an unconstrained | at each end.

Examples:

Lists (and sequences)

With my apologies for any confusion between [ meta-denotation …] and [ literal … ] square brackets and ellipsis. (Note that the latter leaves a space between … and ], while the former does not.) The difference does matter – see above under meta-denotations and templates.

[ [ item [ , item …] ] ]
[ [ item , …] [ … , item , [ item , …] …] [ , item …] ]

in which each item must denote a value; the whole denotes a mapping (:h|N), for which N is either {naturals} or a natural, and the items are h's outputs. When N is 1+n for some natural n, (:h|1+n) is synonymous with [h(0), …, h(n)], just as 1+n is synonymous with {0,…,n} and, indeed, with [0,…,n].

A text matching either template is a sequence of sub-texts, separated by commas and enclosed in [ square brackets ], in which each sub-text either is an ellipsis, as is known, or is intelligible to context as a denotation for a value; if none of the sub-texts is the denotation is of the first form, otherwise the second. Where a sequence of value-denotations, i.e. of items, uninterrupted by appears in a denotation of either form, describe it for the present as a chunk; the first form, when it contains any items at all, has a single chunk; the second form may contain arbitrarily many chunks. Taking any chunk and enclosing it in [ square brackets ] yields a text matching the first template; so, first, I'll give the meanings for these, then I'll use these to express what the second form means.

Each chunk has a definite number of items in it, and no ellipsis; a list in the first form, having N items in its text, is that mapping (:h|N) for which the value of each item in the text is h's output when given, as input, the number of items to the left of the given one. Thus [a,b,c] is the mapping (:|3) which maps 0 to a, 1 to b and 2 to c; and [] is the mapping (:|0), there being only one such since 0 is empty = {} and a mapping (:|{}) has no right values, hence is empty, so indeed [] = {}.

Given this reading of the first form, any chunk is best described by the list one obtains by enclosing it in [ square brackets ]. In a use of the second template, denoting (:h|N), the presence of a chunk described by a list (:g|n) asserts that

Note that, aside from chunks which abut a [ square bracket ], nothing is asserted about the relative order of chunks – the lists [0, 1, 2, 3, 4, 5] and [1, 2, 3, 4] are both valid values for the denotation […, 2, 3, 4, … 1, 2, 3, …], for instance; as, indeed, is {naturals}.

A denotation of the second form may end in ellipsis, in which case the value it denotes may be an infinite sequence, (:h|{naturals}). One could probably do quite well extending the given notation to describing ordinal sequences; then n would be an integer while m might not (though it'll still be an ordinal); ending in ellipsis would then allow (but not constrain) N to be a limit ordinal.

Borrowing an idiom from ECMAScript, I could allow list-like denotations in which two commas appear with no value between them; this would naturally denote a mapping (:h:N) as above, but allowing some members of N to not be right values of h. However, for now (up to 2006/Summer), I chose not to do this.

Arithmetic: polymorphic binary operators

Context may introduce various kinds of operation which it may chose to describe as addition, subtraction, multiplication and division, along with assorted combinators related to these. Different contexts may give meaning to different combinators as addition; to some degree this will control what combinators may be construed in the other rôles, but (see below) as many as three combinators may be involved in multiplicative rôles. I leave it to context to make clear which combinators fill which rôles: in the following, I only set out what is generally true, with illustrations drawn from linear algebra (the principal form of arithmetic). In all contexts, I presume that addition is Abelian (a.k.a. commutative) – so a+b and b+a shall be equal – and that all additions and multiplications shall be associative – so a*(b*c) and (a*b)*c shall be equal whenever * is replaced with + or a multiplication.

For the most part, I shall shadow the orthodox denotations for arithmetic. In particular, enclosures bound the parsing of arithmetic expressions – i.e. no matter what text surrounds (a+b), that text merely sees this as (expression), with no possibility of combining a or b with something outside the (…) to obtain things to subsequently combine using the + seen here; likewise, a-(expression)×b makes sense of the expression as an atom to be combined with a and b in the manner indicated by the text outside the ().

I'll also (as described under + below) use the usual precedence rules, in which multiplicative operations (multiplication and division) are done first (after enclosure), then additive ones, before finally applying the other patterns above.

Aside from the unary form of the additive operators (see below), all the arithmetic operators are binary operators – they combine two values, known as the operands of the binary operator.

The Additive Operators

left + right

addition: denotes the result of adding left and right together. Both left and right must be expressions denoting values; context must have supplied a meaning for addition of such values as these expressions may take.

The type of the operands shall dictate what meaning add has. Since overlapping contexts may define different meanings for add, it is important to note what kind of values the expressions have. Usually, the two operands will be of the same kind (e.g. both members of some given vector space) but they may be of some closely related kind (e.g. a position in some Euclidean space and a displacment within that space; or a natural number and a scaling of some linear space).

left right

subtraction: denotes that which, if added to right, will yield left. Asserts that there is some value meeting this criterion. Notably, when left and right are positions in some Euclidean space (or, for that matter, addresses in the memory-space of a computer program), leftright is a displacement within the Euclidean space (or address space); crucially, it might not be of the same kind as left and right, but adding it to anything of the same kind as right will yield something of the same kind as left (though a finite computer might run into out-of-range problems dealing with the result).

left ± right

the plus-or-minus operator: provides for ambiguous denotations. Asserts that both left+right and leftright are valid denotations.

Generally, mathematical contexts use this to denote either leftright or left+right while scientific contexts (and some mathematical ones, notably statistics) use it for any value between leftright and left+right or for a value which has been determined only sufficiently accurately to allow assertion that the probability of it lying outside this last range is below some threshold (commonly between one in a hundred and one in ten).

Some contexts support unary forms of these additive operators – which are honorary multiplicative operators (for the sake of precedence rules). These take the form of an additive expression, as above, with left omitted; their meaning is equivalent to what would be obtained by (enclosing and) providing, as a default left, a suitable additive identity (i.e. zero). Consequently, −(a−b) will generally be synonymous with (b−a); and note that −a−b means (−a)−b, rather than −(a−b), because the first in −a−b is unary, hence denotes negation, so binds more tightly than the (additive) subtraction operator. Likewise, −a±b or −a+b means (−a)±b or (−a)+b.

Note that I deliberately don't define subtraction in terms of additive inverses; on the natural numbers, we have an addition which is cancellable, which means we can define subtraction as above, despite lacking inverses. In such a case, the unary form of subtraction, known as negation, is not available.

The Multiplication Operators

There's rather more multiplicative operators than one might at first realise. The characteristic property of multiplication is that it (is an associative binary operator which) distributes over addition (i.e. (a+b)×c = a×c + b×c); however, various kinds of kindred combinator meet this criterion with some variation on their details.

left . right

scaling: the simplest kinds of multiplication. Repeated addition provides a natural formalism for multiplication by positive integers which can, in many contexts, be extended (via division by positive integers) to more general scaling which interacts very cleanly with addition; where the things being added have direction as well as size, scaling only changes the latter. Scaling also interacts very cleanly with itself; notably, it is abelian (so swapping left and right does not change the value denoted). Since scaling is the least complex form of multiplication, it gets the most light-weight denotation: a mere full-stop (in en-GB: a.k.a. period in USAish or point in French). Some contexts may warrant the use of this simple form for other multiplication-like operators: but I shall only use it thus when the operator really is very simple and well-behaved.

Asserts that one of left and right is a scalar (i.e. a number) or a scaling (which is just the result of multiplying a scalar by an identity mapping) and the other is a value which is amenable to such scaling; denotes the result of applying the scaling. Note that scalars (and scalings) are always amenable to scaling, so both left and right may be scalings, in which case scaling left by right should always produce the same answer as scaling right by left – i.e. I shall [aim to] only use . for abelian multiplications.

left · right

multiplicative combinators properly construed as [analogous to] the application or composition of relations or functions; most notably, linear contraction. Where scaling, above, produces a value of the same type as the thing scaled, · produces something of a type no more complicated than its operands, albeit possibly of a different type than either operand. When discussing the abstract theory of binary operators, e.g. group theory, I'll use · for the combinator of the group: but my main use of · is in linear algebra.

In the presence of scalings, mappings which respect addition in a sense analogous to distributing over it – i.e. a mapping f for which f(a+b) = f(a) + f(b) – come to be particularly important; and applying such a mapping to its input, or composing two such mappings, behaves very much like multiplication. Formally, we also have to require that the mappings respect scaling – i.e. f(n.x) = n.f(x) for any scalar n – as well as addition; such mappings are called linear (and I'll allow that linearity's definition can be extended to relations in general, not just mappings).

In the case of linear contraction, use of this denotational form asserts that [at least] one of the following holds true, and gives it the meaning indicated:

Officially, the second of these can be construed as a variant on the first, via interpretation of any linear space V as {linear (V:|{scalars})}, using the isomorphism (: (V: v.s ←s :{scalars}) ←v :V); the third can likewise be construed as a variant on the second, via the double-dual interpretation of a linear space, using the isomorphism (: ({scalars}: w(v) ←w |{linear ({scalars}: |V)}) ←v |V); and the last can be construed as an appropriate one of the others via either the first isomorphism just given or interpretation of a scalar as a scaling. These and a few further structural isomorphisms lead to tensor algebra (see next combinator).

Note that I emphatically do not employ · to denote the usual inner product of vector algebra – this combines two vectors to produce a scalar (if the two vectors are equal, this scalar is construed as the square of their length). This is invariably mediated by a metric, which is an isomorphism between the space of vectors and a dual space of covectors: I always mention such metrics explicitly. If the metric is called g and it is used to combine two vectors, x and y, the result may be written as g(x,y), as y·g·x or, indeed, as g(x)·y; but I do not write it as x·y. [As for xTy: I spit on the stupidity of this misconstruction of transposition – just for the record.] In rare cases, where I really want to resemble orthodoxy, I might write x*y for such an inner product, but that's the closest it gets.

left × right

more complex multiplications, most notably the tensor product (as applied to members of linear spaces, not to the spaces themselves). Reduces to . when either operand is a scalar.

Orthodoxy commonly uses &tensor; both where I'm here using × and for the related combinator on linear spaces; I'll reserve it for only the latter, U&tensor;V = {u×v: u in U, v in V}.

Various other operators are begotten by the multiplicative operators of linear algebra: where mathematics uses ^ as a binary operator other than logical and, it generally uses it as a multiplicative operator (i.e. it will take precedence over additive ones, and will usually also distribute over addition); the two commonest are the 3-d vector product and the more general antisymmetric tensor product. In the latter case, I'll also use ^ to denote the associated combinator on linear spaces, U^V = {u^v: u in U, v in V}. Many computer programming languages use * as the multiplication operator; where I use it other than as a dummy operator for discussion of general binary operators, I'll respect this tendency.

The Division Operators

My greatest deviation (as to denoting arithmetic) is in the area of division, where I prefer denotations for ratios rather than multiplication by multiplicative inverses: i.e. I would sooner say a/b than a·(b−1). This is analogous to my specification of subtraction without reference to additive inverses. At the same time, the limitations of plain text militate against any attempt to draw a horizontal line with one expression centred on top of it and another centred beneath. Although I shall presume symmetry in addition (i.e. a+b = b+a for all a, b) I shall not presume the same for multiplication: thus a·(b−1) and (b−1)·a need not be equal, so that I need to distinguish between a/b (the former: a over b) and b\a (the latter: b under a). Officially,

left / mid \ right

multiplication via an inverse; denotes left&on;reverse(mid)&on;right but wants this to be thought of as left·(mid−1right. Pronounced: left over mid under right.

Relates x to y precisely if there exist u and v for which:

In linear algebra, the standard isomorphisms (see · above) enable us to extend this slightly:

numer / denom

synonym for numer/denom\(:v←v|denom). Pronounced: numer over denom.

denom \ numer

synonym for (denom|u←u:)/denom\numer. Pronounced: denom under numer.

I do not use the ÷ operator which I was taught to use for division – at least some cultures (e.g. Norwegian) use it for subtraction. Note that the above allows me to deal with a/b even when b is singular: the result is a relation rather than a mapping (supposing a and b to be mappings) unless a's kernel subsumes b's (i.e. b(x) = 0 implies a(x) = 0). For contrast, b\a is a relation whenever b is singular (left values are ambiguous by members of b's kernel); and its collection of right values (inputs) may be restricted to a sub-space of those of a, namely the subspace on which a's output is an output of b.

Pointwise Extension

Where some or all of the binary operators discussed here are defined for values of some kind, it is natural to induce meaning for those binary operators on mappings whose outputs are of those kinds; for example, if the left values of (:f|I) and (:g|I) are amenable to addition, it makes sense to define f+g to be (: f(i)+g(i) ←i |I). This is know as applying the binary operator pointwise (i.e. at each input). For the sake of generality, I'll actually work with relations and avoid requiring that (:f|) and (:g|) are equal – for additive operators, (:f+g|) will be the union of (:f|) and (:g|), while multiplicative operators will only get the intersection.

Formally, when * is an additive operator and context gives meaning to

I define f*g to relate

x*y to i
whenever f relates x to i and g relates y to i
x to i
whenever f relates x to i and i is not a right value of g
*y to i
whenever g relates x to i and i is not a right value of f

and nothing else to anything else, otherwise. This implicitly extends f and g to each map right values of only the other to an additive identity (i.e. zero). Note that when * is ±, f*g relates x*y to i means f±g relates x+y to i and relates x−y to i (as opposed to f±g relates at least one of x+y and x−y to i), in the discrete (mathematical, except for statistics) sense of ±.

When * is a multiplication or either / or \, and context gives meaning to x*y whenever there is an i for which f relates x to i and g relates y to i, I define f*g to relate each such x*y to i in exactly this case. If context gives meaning to x/u\z whenever f relates x to i, h relates u to i and g relates z to i, I define f/h\g to relate x/u\z to i in exactly this case.

In each case (both additive and multiplicative), if at least one operand is a relation, as above, any operand which is simply a value (of a kind which the operator combines suitably with the relation's left values) is promoted to the constant mapping which relates the given value to each right value of each relation involved.


Valid CSSValid XHTML 1.1 Written by Eddy.