Short answer: the argument must be -1. (But one should take my answer with a grain of salt, since “user’s” docs are completely missing, the “developer’s” docs do not match the code, and the code is incomprehensible.)
Long answer: First, there is a variant of align with a micro-fool-proofing:
- the environment
xalignat takes a required argument;
- when it is
-1, this environment is equivalent to align;
- when it is positive, there is a check for a number of equation-groups — with a warning when one puts too many
&’s on a row.
Note 1: I cannot imagine a situation when this is useful — unless the argument is 1 (the most common case of using align, I presume: with 1 equation group with 2 horizontal parts: 1st flushed right, 2nd left).
Note 2: in the code, I can see that argument -1 may have some other side effects (pre-setting alignsep@ — but is not it overwritten later?) which I do not completely grok.
Second, return to alignat. It is a minor variant of xalignat; it is differs only when the number of equation-groups is larger than 1 (so the check above is purposeless), but it has no shortcut with the argument set to -1. Now, this leads to the “short answer” above.
A very long answer: one should first think what is the intended purpose of this environment. My conjecture is that it achieves a very important function, one that many want to do, and which is not achievable by any other mean; however, being undocumented, this function is fully forgotten.
Example: make an analogue of align, but with aligned +’s and =’s in
a + b = ccc + ddd + y (23.11)
x + aaa + bbb = c + d (23.12)
↑ ⇑
In short, one should
- align +’s (marked with arrows) and =’s, while
- flushing right what is to the left of a marked plus, and
- flushing left what is to the right of a marked plus.
Note: for best result, one should better also allow for the “signs above one arrow” to be different (e.g., × vs ·); then one would need to center signs above arrows. However, AFAIK, this is not achievable (only flushing left/right is supported).
And, at least if I read developer’s docs in amsmath.dtx correct, this is exactly what aligneat{-1} allows one to do! Unfortunately, I cannot see how the docs match the code, so cannot be absolutely sure.
As an experiment shows, this works:
\begin{alignat}{-1}
a & + {}&& b && = {}& ccc & + ddd + y \\
x + aaa & + {}&& bbb && = {}& c & + d
\end{alignat}
Below, I appended 1 + to some +’s and =’s to show that this “column” is flushed left:
\begin{alignat}{-1}
a & + {}&& b && = 1 + {}& ccc & + ddd + y \\
x + aaa & + 1 + {}&& bbb && = {}& c & + d
\end{alignat}
It flushes the odd columns (delimited with &) right, and even ones left; so we need to insert empty columns to convert the wanted format
R c L c R c L
1 + 2 = 2 + 1
(with + and = signs centered) to a possible one
R Ł r L r Ł R L
1 + 2 = 2 +1
Here Ł is where we flush left what is better be centered, and r stands for an empty column (one between a pair &&). (Note that one needs to insert {} at right end after a binary operator. Such {} is inserted automatically at the left end of flushed-left columns, which gives an asymmetry of the code above.)
Note: IMO, the align-like group of environments tries to address too many task without a proper orthogonality. For example, a clone of alignat could be a killer environment, if it allowed some “columns” to be centered, and some columns to be expandable (as a gap after even “columns” of align).
For example, if alignRCL would align columns in a pattern RCLRCLRCL…, then one could have gather by putting content in the second column, one could have alignat by putting content in columns 1,3,4,6,7,9,…. Additionally, one could have an extra macro \nogap to allow having expandable gaps after L-columns (as in align), which are suppressed by this macro. This way, one could combine all effects of align, alignat and gather into one flexible environment… — And, I suspect, there is a chance that this is an edit of a handful of LoC!
What for? Imagine a group of equalities, with several equalities per line, arranged in a grid (as in align); but some of the columns need to be gathered, some require multi-spot alignment (as my example above), and some are just a simple align-able stuff.
Want yet more cockroaches? What I discuss above is about a flavor of align; but the initial question was about a flavor of aligned — and my answer is WRONG for alignedat! In alignedat{-1} (as opposed to alignat{-1}) the argument -1 has side-effect mentioned above — so it behaves similar to aligned.
Conclusion: with alignedat, one should use some meaninglessly large argument (like 999) instead of -1. However, note that alignedat has very few advantages over matrix with format rlrlrlrlrlrlrl: it typesets every cell in displaystyle with zero mathsurround and a strut, and this is probably 99% of what it does…
\strut@
\setboxz@h{\@lign$\m@th\displaystyle{##}$}%
Extra question: does anybody knows what split inside align (or gather) is supposed to achieve?
\maxfields@and is used avoid using more than the specified number of alignment points. So, of course, using a large number would have no impact. – Werner Jan 31 '13 at 04:41\start@aligned. It is shared betweenalignedandalignedat; the mandatory argument distinguishes a specific use of the base function. – Werner Jan 31 '13 at 05:21align. In any case, keep in mind thatamsmathdescends from AMS-TeX, where the argument to\alignedatwas necessary. – egreg Jan 31 '13 at 08:04