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.

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 have some preliminary sketches of how to approach that, though I haven't played with them since 2007).

… 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 parsing and quantifying. - this * that
- Binary operators, combining values to make values.
- 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 (including mappings and collections, i.e. functions and sets), fixed points, sub-… and some combiners.
- (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
- Rie
_{[0 1] [2}^{σ}m_{3] σ}in G^G&tensor;G^G. - Tensor algebra, including a modified form of Einstein's notation.

That's all elsewhere: follow links to see it. The rest of this page is related discussion.

There are many web-sites covering mathematics, taking varying smounts of care over explaining their notation. Here are some samples:

- The MMT language and system
- This is (IIUC) an attempt to enable enable interoperability between the diverse theorem-proving languages out there. It provides a general notation for expressing mathematical ideas formally, with a specific focus on it being possible for dumb software to make sense of it. It is linked to the OMDoc project.
- Wikipedia's page on mathematical notation
- Part of the WikiMaths project. Talks about notation rather than specifying it.

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.

Some readers of this page may
see

above where I hope others see `&unite;`, `&intersect;`, `&on;`∪, ∩, ∘

– 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
Chromium,
FireFox, Vivaldi
or 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 `ℏ` 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 `ℏ`, but this second reason
remains; I prefer to write &on; as `&on;` rather
than `∘`, 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 a newer version of IE, or even to Edge.

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.