Clarification of Renderer Syntax

This is a more or less technical discussion of how the renderer parses equations. If you are looking for basic help, try the basic renderer help page.

Background

The renderer's syntax is derived from what is generally considered 'conventional' mathematical notation. This notation is full of anomalies and inconsistencies which are less readily apparent from a human standpoint than when attempting to create a syntax that a machine can readily parse. To illustrate this point, consider that any human can easily distinguish and identify many variations of images depicting diverse versions of what we call a "coffee-cup." Whereas a machine could possibly do so only with great effort.

This may seem like an abstract philosophical point until enter an equation which you think that the machine is rendering incorrectly, only to subsequently realize that it is in fact following a consistent set of rules which don't conform to human 'logic.'

The below set of rules is our best attempt at combining the two as elegantly as possible.

Precedence

Precedence should work pretty much how you would expect. Addition and subtraction have lower precedence than multiplication and division. Exponentiation has higher precedence than all of them.

The subtlety here is that generally in algebra, putting two things next to each other implies multiplication. so:

x^2y+3y^2x
sin^2x

Overriding precedence -- grabbers

To override precedence, the renderer uses parentheses () as typesetting delineators. There can be a confusing duplicity in meaning, since parentheses can also appear as simple text.

Perhaps the easiest way to think of renderer syntax is in terms of 'grabbers.' operators grab segments of the formula to the right or left, according to 3 basic strategies:

grab a segment to the right, according to precedence
grab a segment to the left, according to precedence
grab a segment to the right, as function

Operators such as exponentiation and subscript ('^' and '_' ) grab to the right, according to precedence. Fractions ( '/' ) grab both to the left and the right, according to precedence.

Other typesetting macros such as sqrt and Sigma grab to the right, as functions. Functions, unlike operators, grab everything to their right up to either the end of the equation or an unmatched right parenthesis, ')'.

So some examples of complete notation would be as follows:

x^(y)
x_(n)
(a)/(b)
sqrt (x)

If the renderer does not find parentheses as expected, it makes its best attempt to put them in. (sometimes these will show up unexpectedly in the viewing window). For example, the above may be simply be represented as:

x^y
x_n
a/b
sqrt x

and the renderer will add parentheses so that they look like the example block above.

So if you want the renderer to grab more or less than the default setting, use parentheses adjacent to the operator or function in the manner shown below:

sin^(2x)
a/(b+c)

In these cases, the parentheses will disappear. If you want parentheses, you can double them:

a/((b+c))

And one final trick: the special character backslash ( '\' ) will not appear, but it will end a grab. So for example, the following two equations are equivalent:

x_(3)gamma
x_3\gamma

both wind up with:

This can also be useful when attempting to represent character sequences which would otherwise be interpreted as a macro. For example:

pi
p\i