]> Plaintext Denotations

This has necessitated a complete break from the historical line of development, but the break is an advantage through enabling the approach to the new ideas to be made as direct as possible.
P.A.M. Dirac, 1930/May/29.

Plaintext Denotations

An author who uses jargon or specialized notation has a far better chance of being understood when supplying some key to the meaning of these esoterica. Even in the case of an author using orthodox mathematical notation, providing a summary of that notation and a glossary of special terms would be prudent: not only does it ensure that a student unfamiliar with some details of the notation can pick it up in the course of reading; it also reduces the scope for confusion if read by some practitioner more familiar with some other variant of the notation. The need for exposition is all the more urgent in my own case, as I have elected to invent notation from scratch.

The reasons for that choice, I discuss elsewhere. Here, I explain how to extract meaning from the texts by which I aim to express mathematical truths. The design of this notation is deliberately spartan, primarily so that I can type it with ease: however, this should also ensure that you need only remember a few rules to get the gist of the text's meaning, and you should only need to remember a moderate amount more to be able to extract all the details. The notions encoded by denotations are sufficiently powerful, general and primitive that there should be no need to invent ad hoc notational oddities; and that, when such quirks prove desirable all the same, they can be specified entirely in terms of the core notation. At the same time, I have taken care to ensure that the notation has very definite meanings: the only ambiguities should be those deliberately intended by the author – and, indeed, this notation provides for the careful expression of certain kinds of ambiguity, generally modulo equivalence relations, so as to obviate the need for certain encumbrances of orthodox expressions of mathematics (albeit the underlying meaning is essentially unchanged).

I intend, in the design and specification of this notation, to make its meaning plain enough that I (or the interested reader) may, in due course, transpose the specification into a body of software capable of parsing the notation (indeed, I even made some preliminary sketches of how to approach that, though I haven't played with them since 2007).

The general plan is to have a base notation that suffices to describe everything while providing for extensions that allow terser expression of things that (can be expressed, but) would be unduly verbose in the base notation.

… with illustrations of the most prominent denotations introduced:

Templates and meta-denotations

thing is [{ a; an }] mode
thing [ isa mode …]: Styled words and punctuators, types and isa.
(…), {…}, […]: Enclosures, scopes, parsing and quantifying.

Developing Notation

The newer pages of my site use this newer notation; older pages use similar notation, which evolved over time from an earlier specification. In this newer notation, 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.

A note on the use of XHTML

Some readers of this page may see &unite;, &intersect;, &on; above where I hope others see ∪, ∩, ∘ – and there are similar differences throughout my pages using XHTML. Hopefully, the former can learn to make sense of these as standing for the operators they see named – alternatively, most of them should be able to upgrade to a better web browser, such as [Get Chromium] Chromium, FireFox, [Get Vivaldi] Vivaldi or [Get Opera!] Opera, any of which you can download for free. Those who see the symbols, for contrast, may gain hereby a clue that looking at the source of my pages shall generally show you, where a whacky symbol appears, a word that tells you what that symbol means. The reasons for the diversity of presentation, however, are somewhat involved.

HTML (and XHTML, in which this page is written) can be written in any character encoding (including UTF-8, which can cope with the whole of Unicode); I chose to type in ASCII because it's the easiest for me to do from my key-board. HTML provides for encoding, in plain ASCII, the vast plethora of non-ASCII characters supported by Unicode. If your user agent (e.g. web browser) does not know how to present those characters to you, it is of little use to you that I have succeeded in encoding them in my documents (whether by using a character encoding that supports them or by exploiting HTML's way of writing them in ASCII). However, it is possible for me to express them in terms which give you at least some chance of being able to work out what I meant, even when your user agent fails you.

The mechanism HTML provides for expressing characters outside the repertoire of a document's primary encoding is to give special meanings to sequences beginning with an & (ampersand) and ending in a ; (semicolon). Such sequences are known as character entities. The piece in between may either specify a number – the Unicode code-point for the desired character – or a word (for a rather specialized meaning of word). The numeric form intrinsically covers the whole range of possible Unicode characters – however, it is significantly less intelligible to someone reading the raw HTML; and requires the author to remember the correct numbers for all needed characters. The word form is generally more intelligible in its source form, but HTML only defines such forms for a limited sub-set of the possible repertoire – and HTML provides no practical means of extending the set of supported words.

XHTML, on the other hand, does provide a mechanism (for the details, view source and study the tail of the DOCTYPE element at the start of this page) by which I can define word-like character entities beyond the standard repertoire: I can arrange for &hbar; to be handled as ℏ and thus displayed as ℏ, even though HTML 4 did not provide for this symbol (much used in modern theoretical physics). Furthermore, where I use a symbol with a meaning other than the one expressed by the word by which HTML provides for me to encode it, I can arrange that what I type expresses the meaning I actually intend: I can arrange for &implies; to be handled as ⇒ and thus displayed as ⇒. (The HTML 5 repertoire is greatly expanded, I'm pleased to see, and does include &hbar;, but this second reason remains; I prefer to write &on; as &on; rather than &compfn;, if only because I do use it for relations as well as functions.) Thus the raw source of my documents says what I mean, and gets displayed using the symbols orthodoxly used to express what I mean, without my needing to type anything but plain ASCII or remember code-point numbers (given that I have a template with most of the ones I want in its DOCTYPE).

This delightful state of affairs has persuaded me to use XHTML for my pages wherever I have a use for unusual characters, despite my general conservatism as to document formats – every user agent understands HTML, but some are not so hot when it comes to XHTML. In particular, users of Microsoft's Internet Explorer, up to version 8, may see my XHTML pages displayed (if at all) as HTML – so my mnemonic character entities aren't supported; but, at least, they should be displayed as suitable words (wrapped in odd punctuation) so that the meaning should be clear enough. If that's what you're seeing, and you'd sooner see the right glyphs displayed, please try out a modern standards-compliant browser – see above for suggestions, or just upgrade (if you can) to one of Microsoft's more recent browsers.

Sadly, there is still a way for it to fail: if your browser does understand the character entity correctly but the fonts available to it lack the symbol represented, it is apt to display something less than helpful – my tablet and 'phone browsers display blank spaces, not even an uh-oh – I don't know how to show this glyph (or, at least, a visible one). As a milder version of the same problem, a browser that has some glyph might lack a bold version of the glyph, so fail to distinguish, by my styling, that it's a a literal in a template. In principle I can fix both forms of this with a suitable web-font; but I have yet to do the research on how to implement that.

Written by Eddy.

Plaintext Denotations

Contents

See also

Developing Notation

A note on the use of XHTML