Matrices, arrays and other table-like mathematical notation are marked
up using mtable,
mtr, mlabeledtr and
mtd elements. These elements are similar to the
table, tr and td elements of HTML, except that they provide
specialized attributes for the fine layout control
necessary for commutative diagrams, block matrices and so on.
While the two-dimensional layouts used for elementary math such as addition and multiplication
are somewhat similar to tables, they differ in important ways.
For layout and for accessibility reasons, the mstack and mlongdiv elements discussed
in Section 3.6 Elementary Math should be used for elementary math notations.
3.5.5 Alignment Markers
<maligngroup/>, <malignmark/>
3.5.5.1 Description
Alignment markers are space-like elements (see Section 3.2.7 Space <mspace/>) that can be used
to vertically align specified points within a column of MathML
expressions by the automatic insertion of the necessary amount of
horizontal space between specified sub-expressions.
The discussion that follows will use the example of a set of
simultaneous equations that should be rendered with vertical
alignment of the coefficients and variables of each term, by
inserting spacing somewhat like that shown here:
8.44x + 55 y = 0
3.1 x - 0.7y = -1.1
If the example expressions shown above were arranged in a column
but not aligned, they would appear as:
8.44x + 55y = 0
3.1x - 0.7y = -1.1
For audio renderers, it is suggested that the alignment elements
produce the analogous behavior of altering the rhythm of pronunciation
so that it is the same for several sub-expressions in a column, by the
insertion of the appropriate time delays in place of the extra
horizontal spacing described here.
The expressions whose parts are to be aligned (each equation, in the
example above) must be given as the table elements (i.e. as the mtd elements) of one column of an
mtable. To avoid confusion, the term "table
cell" rather than "table element" will be used in the
remainder of this section.
All interactions between alignment elements are limited to the
mtable column they arise in. That is, every
column of a table specified by an mtable element
acts as an "alignment scope" that contains within it all alignment
effects arising from its contents. It also excludes any interaction
between its own alignment elements and the alignment elements inside
any nested alignment scopes it might contain.
The reason mtable columns are used as
alignment scopes is that they are the only general way in MathML to
arrange expressions into vertical columns. Future versions of MathML
may provide an malignscope element that allows
an alignment scope to be created around any MathML element, but even
then, table columns would still sometimes need to act as alignment
scopes, and since they are not elements themselves, but rather are
made from corresponding parts of the content of several
mtr elements, they could not individually be the
content of an alignment scope element.
An mtable element can be given the attribute
alignmentscope="false" to cause
its columns not to act as alignment scopes. This is discussed further at
the end of this section. Otherwise, the discussion in this section assumes
that this attribute has its default value of "true".
3.5.5.2 Specifying alignment groups
To cause alignment, it is necessary to specify, within each
expression to be aligned, the points to be aligned with corresponding
points in other expressions, and the beginning of each alignment
group of sub-expressions that can be horizontally shifted as a
unit to effect the alignment. Each alignment group must contain one
alignment point. It is also necessary to specify which expressions in
the column have no alignment groups at all, but are affected only by
the ordinary column alignment for that column of the table, i.e. by
the columnalign attribute, described elsewhere.
The alignment groups start at the locations of invisible
maligngroup elements, which are rendered with
zero width when they occur outside of an alignment scope, but within
an alignment scope are rendered with just enough horizontal space to
cause the desired alignment of the alignment group that follows
them. A simple algorithm by which a MathML application can achieve this is given
later. In the example above, each equation would have one
maligngroup element before each coefficient,
variable, and operator on the left-hand side, one before the
= sign, and one before the constant on the right-hand
side.
In general, a table cell containing n
maligngroup elements contains n
alignment groups, with the ith group consisting of the
elements entirely after the ith
maligngroup element and before the
(i+1)-th; no element within the table cell's content
should occur entirely before its first
maligngroup element.
Note that the division into alignment groups does not
necessarily fit the nested expression structure of the MathML
expression containing the groups — that is, it is permissible for one
alignment group to consist of the end of one
mrow, all of another one, and the beginning of a
third one, for example. This can be seen in the MathML markup for the
present example, given at the end of this section.
The nested expression structure formed by mrows
and other layout schemata should reflect the mathematical structure of the
expression, not the alignment-group structure, to make possible optimal
renderings and better automatic interpretations; see the discussion of
proper grouping in section Section 3.3.1 Horizontally Group Sub-Expressions
<mrow>. Insertion of
alignment elements (or other space-like elements) should not alter the
correspondence between the structure of a MathML expression and the
structure of the mathematical expression it represents.
Although alignment groups need not
coincide with the nested expression structure of layout schemata,
there are nonetheless restrictions on where an maligngroup
element is allowed within a table cell. The maligngroup
element may only be contained within elements (directly or indirectly) of the following types
(which are themselves contained in the table cell):
-
an mrow element, including an inferred
mrow such as the one formed by a multi-child
mtd element, but excluding mrow which
contains a change of direction using the dir attribute;
-
an mstyle element
, but excluding those which change direction
using the dir attribute;
-
an mphantom element;
-
an mfenced element;
-
an maction element, though only its
selected sub-expression is checked;
-
a semantics element.
These restrictions are intended to ensure that alignment can be
unambiguously specified, while avoiding complexities involving things
like overscripts, radical signs and fraction bars. They also ensure
that a simple algorithm suffices to accomplish the desired
alignment.
Note that some positions for an maligngroup
element, although legal, are not useful, such as an
maligngroup element that is an argument of an
mfenced element. Similarly, when inserting an maligngroup
element in an element whose arguments have positional significance, it
is necessary to introduce a new mrow element
containing just the maligngroup element and the child element
it precedes in order to preserve the proper expression structure. For
example, to insert an maligngroup before the denominator
child of an mfrac element, it is necessary to enclose the
maligngroup and the denominator in an mrow to
avoid introducing an illegal third child in the
mfrac. In general, this will be necessary except
when the maligngroup element is inserted directly into an
mrow or into an element that can form an inferred
mrow from its contents. See the warning about the legal
grouping of "space-like elements" in Section 3.2.7 Space <mspace/> for an analogous example
involving malignmark.
For the table cells that are divided into alignment groups, every
element in their content must be part of exactly one alignment group,
except for the elements from the above list that contain
maligngroup elements inside them and the
maligngroup elements themselves. This means
that, within any table cell containing alignment groups, the first
complete element must be an maligngroup element,
though this may be preceded by the start tags of other elements.
This requirement removes a potential confusion about how to align
elements before the first maligngroup element,
and makes it easy to identify table cells that are left out of their
column's alignment process entirely.
Note that it is not required that the table cells in a column that
are divided into alignment groups each contain the same number of
groups. If they don't, zero-width alignment groups are effectively
added on the right side (or left side, in a RTL context) of each table cell that has fewer groups than
other table cells in the same column.
3.5.5.3 Table cells that are not divided into alignment groups
Expressions in a column that are to have no alignment groups
should contain no maligngroup
elements. Expressions with no alignment groups are aligned using only
the columnalign attribute that applies to the table
column as a whole, and are not affected by the groupalign
attribute described below. If such an expression is wider than the
column width needed for the table cells containing alignment groups,
all the table cells containing alignment groups will be shifted as a
unit within the column as described by the columnalign
attribute for that column. For example, a column heading with no
internal alignment could be added to the column of two equations given
above by preceding them with another table row containing an
mtext element for the heading, and using the
default columnalign="center" for the table, to
produce:
equations with aligned variables
8.44x + 55 y = 0
3.1 x - 0.7y = -1.1
or, with a shorter heading,
some equations
8.44x + 55 y = 0
3.1 x - 0.7y = -1.1
3.5.5.4 Specifying alignment points using <malignmark/>
Each alignment group's alignment point can either be specified by
an malignmark element anywhere within the
alignment group (except within another alignment scope wholly
contained inside it), or it is determined automatically from the
groupalign attribute. The groupalign
attribute can be specified on the group's preceding
maligngroup element or on its surrounding
mtd, mtr, or
mtable elements. In typical cases, using the
groupalign attribute is sufficient to describe the
desired alignment points, so no malignmark
elements need to be provided.
The malignmark element indicates that the
alignment point should occur on the right edge of the preceding
element, or the left edge of the following element or character,
depending on the edge attribute of
malignmark. Note that it may be necessary to
introduce an mrow to group an
malignmark element with a neighboring element,
in order not to alter the argument count of the containing
element. (See the warning about the legal grouping of "space-like
elements" in Section 3.2.7 Space <mspace/>).
When an malignmark element is provided within an
alignment group, it can occur in an arbitrarily deeply nested element
within the group, as long as it is not within a nested alignment scope. It
is not subject to the same restrictions on location as maligngroup elements. However, its immediate
surroundings need to be such that the element to its immediate right or
left (depending on its edge attribute) can be
unambiguously identified. If no such element is present, renderers should
behave as if a zero-width element had been inserted there.
For the purposes of alignment, an element X is considered to be to the
immediate left of an element Y, and Y to the immediate right of X, whenever
X and Y are successive arguments of one (possibly inferred) mrow element,
with X coming before Y (in a LTR context; with X coming after Y in a RTL context). In the case of
mfenced elements, MathML applications should evaluate this
relation as if the mfenced element had been
replaced by the equivalent expanded form involving mrow. Similarly, an maction
element should be treated as if it were replaced by its currently selected
sub-expression. In all other cases, no relation of "to the immediate
left or right" is defined for two elements X and Y. However, in the
case of content elements interspersed in presentation markup, MathML applications
should attempt to evaluate this relation in a sensible way. For example, if
a renderer maintains an internal presentation structure for rendering
content elements, the relation could be evaluated with respect to
that. (See Chapter 4 Content Markup and Chapter 5 Mixing Markup Languages for Mathematical Expressions for further
details about mixing presentation and content markup.)
malignmark elements are allowed to occur within
the content of token elements, such as mn,
mi, or mtext. When this
occurs, the character immediately before or after the
malignmark element will carry the alignment
point; in all other cases, the element to its immediate left or right
will carry the alignment point. The rationale for this is that it is
sometimes desirable to align on the edges of specific characters
within multi-character token elements.
If there is more than one malignmark element
in an alignment group, all but the first one will be ignored. MathML
applications may wish to provide a mode in which they will warn about
this situation, but it is not an error, and should trigger no warnings
by default. The rationale for this is that it would
be inconvenient to have to remove all
unnecessary malignmark elements from
automatically generated data, in certain cases, such as when they are
used to specify alignment on "decimal points" other than the '.'
character.
3.5.5.5 <malignmark/> Attributes
malignmark elements accept the attributes listed
below in addition to those specified in Section 3.1.10 Mathematics style attributes common to presentation elements
(however, neither mathcolor nor mathbackground have any effect).
| Name |
values |
default |
| edge |
"left" | "right" |
left |
|
see the discussion below.
|
The
edge attribute specifies whether the alignment point will be
found on the left or right edge of some element or character. The
precise location meant by "left edge" or "right edge" is discussed
below. If edge="right", the alignment point is the right
edge of the element or character to the immediate left of the
malignmark element. If edge="left",
the alignment point is the left edge of the element or character to
the immediate right of the malignmark
element. Note that the attribute refers to the choice of edge rather
than to the direction in which to look for the element whose edge will
be used.
For malignmark elements that occur within
the content of MathML token elements, the preceding or following
character in the token element's content is used; if there is no such
character, a zero-width character is effectively inserted for the
purpose of carrying the alignment point on its edge. For all other
malignmark elements, the preceding or following
element is used; if there is no such element, a zero-width element is
effectively inserted to carry the alignment point.
The precise definition of the "left edge" or "right edge" of a
character or glyph (e.g. whether it should coincide with an edge of
the character's bounding box) is not specified by MathML, but is at
the discretion of the renderer; the renderer is allowed to let the
edge position depend on the character's context as well as on the
character itself.
For proper alignment of columns of numbers (using groupalign values of "left", "right", or "decimalpoint"), it is
likely to be desirable for the effective width (i.e. the distance between
the left and right edges) of decimal digits to be constant, even if their
bounding box widths are not constant (e.g. if "1" is narrower
than other digits). For other characters, such as letters and operators, it
may be desirable for the aligned edges to coincide with the bounding
box.
The "left edge" of a MathML element or alignment group
refers to the left edge of the leftmost glyph drawn to render the element
or group, except that explicit space represented by mspace or mtext elements
should also count as "glyphs" in this context, as should
glyphs that would be drawn if not for mphantom
elements around them. The "right edge" of an element or
alignment group is defined similarly.
3.5.5.6 <maligngroup/> Attributes
maligngroup elements accept the attributes listed
below in addition to those specified in Section 3.1.10 Mathematics style attributes common to presentation elements
(however, neither mathcolor nor mathbackground have any effect).
| Name |
values |
default |
| groupalign |
"left" | "center" | "right" | "decimalpoint" |
inherited |
|
see the discussion below.
|
maligngroup has one attribute,
groupalign, which is used to determine the position of
its group's alignment point when no malignmark
element is present. The following discussion assumes that no
malignmark element is found within a group.
In the example given at the beginning of this section, there is one
column of 2 table cells, with 7 alignment groups in each table cell;
thus there are 7 columns of alignment groups, with 2 groups, one above
the other, in each column. These columns of alignment groups should be
given the 7 groupalign values "decimalpoint left left
decimalpoint left left decimalpoint", in that order. How to specify
this list of values for a table cell or table column as a whole, using
attributes on elements surrounding the
maligngroup element is described later.
If groupalign is "left",
"right", or "center", the alignment point is
defined to be at the group's left edge, at its right edge, or halfway
between these edges, respectively. The meanings of "left edge"
and "right edge" are as discussed above in relation to malignmark.
If groupalign is "decimalpoint",
the alignment point is the right edge of the character immediately before the
left-most 'decimal point', i.e. matching the character specified by
the decimalpoint attribute of mstyle (default ".", U+002E)
in the first mn element found along
the alignment group's baseline. More precisely, the alignment group is
scanned recursively, depth-first, for the first mn
element, descending into all arguments of each element of the types
mrow (including inferred
mrows), mstyle,
mpadded, mphantom, menclose,
mfenced, or msqrt,
descending into only the first argument of each "scripting" element
(msub, msup,
msubsup, munder,
mover, munderover,
mmultiscripts) or of each
mroot or semantics element,
descending into only the selected sub-expression of each
maction element, and skipping the content of all
other elements. The first mn so found always
contains the alignment point, which is the right edge of the last
character before the first decimal point in the content of the
mn element. If there is no decimal point in the
mn element, the alignment point is the right edge
of the last character in the content. If the decimal point is the
first character of the mn element's content, the
right edge of a zero-width character inserted before the decimal point
is used. If no mn element is found, the right
edge of the entire alignment group is used (as for
groupalign="right").
In order to permit alignment on decimal points in
cn elements, a MathML application can convert a
content expression into a presentation expression that renders the
same way before searching for decimal points as described above.
Characters other than "." can be used as
"decimal points" for alignment by using mstyle;
more arbitrary alignment points can chosen by embedding malignmark elements
within the mn token's content itself.
For any of the groupalign values, if an explicit
malignmark element is present anywhere within
the group, the position it specifies (described earlier) overrides the
automatic determination of alignment point from the
groupalign value.
3.5.5.7 Inheritance of groupalign values
It is not usually necessary to put a groupalign
attribute on every maligngroup element. Since
this attribute is usually the same for every group in a column of
alignment groups to be aligned, it can be inherited from an attribute
on the mtable that was used to set up the
alignment scope as a whole, or from the mtr or
mtd elements surrounding the alignment group. It
is inherited via an "inheritance path" that proceeds from
mtable through successively contained
mtr, mtd, and
maligngroup elements. There is exactly one
element of each of these kinds in this path from an
mtable to any alignment group inside it. In
general, the value of groupalign will be
inherited by any given alignment group from the innermost element
that surrounds the alignment group and provides an explicit
setting for this attribute. For example, if an
mtable element specifies values for groupalign and
a maligngroup element within the table also specifies an
explicit groupalign value, then then the value from the
maligngroup takes priority.
Note, however, that each mtd element needs, in
general, a list of groupalign values, one for each
maligngroup element inside it (from left to right, in an LTR context,
or from right to left in an RTL context), rather than just
a single value. Furthermore, an mtr or
mtable element needs, in general, a list of lists
of groupalign values, since it spans multiple
mtable columns, each potentially acting as an
alignment scope. Such lists of group-alignment values are specified
using the following syntax rules:
group-alignment = "left" | "right" | "center" | "decimalpoint"
group-alignment-list = group-alignment +
group-alignment-list-list = ( "{" group-alignment-list "}" ) +
As described in Section 2.1.5 MathML Attribute Values, | separates
alternatives; + represents optional repetition (i.e. 1 or
more copies of what precedes it), with extra values ignored and the
last value repeated if necessary to cover additional table columns or
alignment group columns; '{' and '}'
represent literal braces; and ( and ) are
used for grouping, but do not literally appear in the attribute
value.
The permissible values of the groupalign attribute of the
elements that have this attribute are specified using the above
syntax definitions as follows:
In the example near the beginning of this section, the group
alignment values could be specified on every mtd
element using groupalign = "decimalpoint left left
decimalpoint left left decimalpoint", or on every
mtr element using groupalign =
"{decimalpoint left left decimalpoint left left decimalpoint}", or
(most conveniently) on the mtable as a whole
using groupalign = "{decimalpoint left left decimalpoint
left left decimalpoint}", which provides a single braced list of
group-alignment values for the single column of expressions to be
aligned.
3.5.5.8 MathML representation of an alignment example
The above rules are sufficient to explain the MathML representation
of the example given near the start of this section.
To repeat the example, the desired rendering is:
8.44x + 55 y = 0
3.1 x - 0.7y = -1.1
One way to represent that in MathML is:
<mtable groupalign=
"{decimalpoint left left decimalpoint left left decimalpoint}">
<mtr>
<mtd>
<mrow>
<mrow>
<mrow>
<maligngroup/>
<mn> 8.44 </mn>
<mo> ⁢<!--INVISIBLE TIMES--> </mo>
<maligngroup/>
<mi> x </mi>
</mrow>
<maligngroup/>
<mo> + </mo>
<mrow>
<maligngroup/>
<mn> 55 </mn>
<mo> ⁢<!--INVISIBLE TIMES--> </mo>
<maligngroup/>
<mi> y </mi>
</mrow>
</mrow>
<maligngroup/>
<mo> = </mo>
<maligngroup/>
<mn> 0 </mn>
</mrow>
</mtd>
</mtr>
<mtr>
<mtd>
<mrow>
<mrow>
<mrow>
<maligngroup/>
<mn> 3.1 </mn>
<mo> ⁢<!--INVISIBLE TIMES--> </mo>
<maligngroup/>
<mi> x </mi>
</mrow>
<maligngroup/>
<mo> - </mo>
<mrow>
<maligngroup/>
<mn> 0.7 </mn>
<mo> ⁢<!--INVISIBLE TIMES--> </mo>
<maligngroup/>
<mi> y </mi>
</mrow>
</mrow>
<maligngroup/>
<mo> = </mo>
<maligngroup/>
<mrow>
<mo> - </mo>
<mn> 1.1 </mn>
</mrow>
</mrow>
</mtd>
</mtr>
</mtable>
|
|
3.5.5.9 Further details of alignment elements
The alignment elements maligngroup and
malignmark can occur outside of alignment
scopes, where they are ignored. The rationale behind this is that in
situations in which MathML is generated, or copied from another
document, without knowing whether it will be placed inside an
alignment scope, it would be inconvenient for this to be an error.
An mtable element can be given the attribute alignmentscope="false" to cause its
columns not to act as alignment scopes. In general, this attribute has the
syntax ("true" | "false") +; if its value is a list of Boolean
values, each Boolean value applies to one column, with the last value
repeated if necessary to cover additional columns, or with extra values
ignored. Columns that are not alignment scopes are part of the alignment
scope surrounding the mtable element, if there is
one. Use of alignmentscope="false" allows nested tables to contain malignmark elements for aligning the inner table in the
surrounding alignment scope.
As discussed above, processing of alignment for content elements is
not well-defined, since MathML does not specify how content elements
should be rendered. However, many MathML applications are likely to find it
convenient to internally convert content elements to presentation
elements that render the same way. Thus, as a general rule, even if a
renderer does not perform such conversions internally, it is
recommended that the alignment elements should be processed as if it
did perform them.
A particularly important case for renderers to handle gracefully is the
interaction of alignment elements with the matrix
content element, since this element may or may not be internally converted
to an expression containing an mtable element for
rendering. To partially resolve this ambiguity, it is suggested, but not
required, that if the matrix element is converted
to an expression involving an mtable element, that
the mtable element be given the attribute alignmentscope="false", which will
make the interaction of the matrix element with the
alignment elements no different than that of a generic presentation element
(in particular, it will allow it to contain malignmark elements that operate within the alignment
scopes created by the columns of an mtable that
contains the matrix element in one of its table
cells).
The effect of alignment elements within table cells that have
non-default values of the columnspan or rowspan attributes is not specified, except that such
use of alignment elements is not an error. Future versions of MathML may
specify the behavior of alignment elements in such table cells.
The effect of possible linebreaking of an mtable
element on the alignment elements is not specified.
3.5.5.10 A simple alignment algorithm
A simple algorithm by which a MathML renderer can perform the
alignment specified in this section is given here. Since the alignment
specification is deterministic (except for the definition of the left
and right edges of a character), any correct MathML alignment
algorithm will have the same behavior as this one. Each
mtable column (alignment scope) can be treated
independently; the algorithm given here applies to one
mtable column, and takes into account the
alignment elements, the groupalign attribute described in
this section, and the columnalign attribute described
under mtable (Section 3.5.1 Table or Matrix
<mtable>).
First, a rendering is computed for the contents of each table cell
in the column, using zero width for all
maligngroup and malignmark
elements. The final rendering will be identical except for horizontal
shifts applied to each alignment group and/or table cell. The
positions of alignment points specified by any
malignmark elements are noted, and the remaining
alignment points are determined using groupalign
values.
For each alignment group, the horizontal positions of the left
edge, alignment point, and right edge are noted, allowing the width of
the group on each side of the alignment point (left and right) to be
determined. The sum of these two "side-widths", i.e. the sum of the
widths to the left and right of the alignment point, will equal the
width of the alignment group.
Second, each column of alignment groups is
scanned. The ith scan covers the ith
alignment group in each table cell containing any alignment
groups. Table cells with no alignment groups, or with fewer than
i alignment groups, are ignored. Each scan computes two
maximums over the alignment groups scanned: the maximum width to the
left of the alignment point, and the maximum width to the right of the
alignment point, of any alignment group scanned.
The sum of all the maximum widths computed (two for each column of
alignment groups) gives one total width, which will be the width of
each table cell containing alignment groups. Call the maximum number
of alignment groups in one cell n; each such cell
is divided into 2n horizontally adjacent sections, called
L(i) and R(i) for i from 1 to
n, using the 2n maximum side-widths computed
above; for each i, the width of all sections called
L(i) is the maximum width of any cell's ith
alignment group to the left of its alignment point, and the width of
all sections called R(i) is the maximum width of any
cell's ith alignment group to the right of its alignment
point.
Each alignment group is then shifted horizontally as a block
to a unique position that places: in the section called L(i) that part
of the ith group to the left of its alignment point;
in the section called R(i) that part of the ith group
to the right of its alignment point. This results in the
alignment point of each ith group being on the boundary
between adjacent sections L(i) and R(i), so
that all alignment points of ith groups have the same
horizontal position.
The widths of the table cells that contain no alignment groups
were computed as part of the initial rendering, and may be different
for each cell, and different from the single width used for cells
containing alignment groups. The maximum of all the cell widths (for
both kinds of cells) gives the width of the table column as a
whole.
The position of each cell in the column is determined by the
applicable part of the value of the columnalign attribute
of the innermost surrounding mtable,
mtr, or mtd element that
has an explicit value for it, as described in the sections on those
elements. This may mean that the cells containing alignment groups
will be shifted within their column, in addition to their alignment
groups having been shifted within the cells as described above, but
since each such cell has the same width, it will be shifted the same
amount within the column, thus maintaining the vertical alignment of
the alignment points of the corresponding alignment groups in each
cell.
as opposed to the default rendering
.
.
such that f(x) <1' is equivalent to
and could be represented as:
![[Image of a circle and box around x plus y]](image/circlebox.png)
![[image of actuarial notation for a angle n at i]](image/actuarial.png)
![[image of phasorangle notation for the angle negative pi over 2]](image/phasorangle.png)
![[Image of 12 factorial in Arabic style]](image/madruwb12.png)
versus the staggered positioning of nested scripts as shown here
;
the latter can be achieved by nesting an 
versus
.
The MathML representation for this example is shown below.
versus
.
These differences also apply to "mathematical accents" such as
bars or braces over expressions:
versus
.
The MathML representation for each of these examples is shown below.
versus
.
The MathML representation for this example is shown below.
(where k and l are different indices)
![[binomial(5,12) in english style]](image/binom5-12.png)
![[binomial(5,12) in Arabic style]](image/arbinom5-12.png)
He 
.
However, the procedure of building an expression tree by replacing
which has two sub-terms of the form
,
one with 
.
However, in this form, it is no longer possible to share the expression
