Errata in documentation

spec/MATL_spec.tex

@@ -390,7 +390,7 @@ \subsection{Numerical arrays}
 \label{parte: array checking}
 It's important to define carefully what is permitted within arrays. For example: should these be allowed? \matl{[sqrt(1:3)]}, \matl{[cos(1) sin(1)]}, \matl{[path]}. Allowing arbitrary MATLAB code within literals that will be evaluated brings flexibility, but it's dangerous. For example, the literal \matl{[rmpath('C:\textbackslash path\textbackslash to\textbackslash files')]} would remove a folder from the path in MATLAB.
 
-One possibility to prevent that unwanted behaviour is to check the array contents strictly: a numerical array is \matl{[...]} with contents separated by commas/spaces and semicolons. Each content must be a number, a numerical array, or a character array (which will be interpreted as numbers); and content sizes must much to form a 2D array. That involves hard work when parsing the array. It's much easier to let MATLAB do that work (via the compiled code), which it does very well.
+One possibility to prevent that unwanted behaviour is to check the array contents strictly: a numerical array is \matl{[...]} with contents separated by commas/spaces and semicolons. Each content must be a number, a numerical array, or a character array (which will be interpreted as numbers); and content sizes must match to form a 2D array. That involves hard work when parsing the array. It's much easier to let MATLAB do that work (via the compiled code), which it does very well.
 
 In fact, this problem already exists with MATLAB's \matlab+input+ and \matlab+str2num+  functions: they \emph{evaluate} what the user types, which is a dangerous thing to do. If the user types \matlab+[cos(1) sin(2]+ as input, evaluating that is probably fine. But what if they type \matlab+addpath('c:\path\to\folder')+?
 
@@ -491,7 +491,7 @@ \subsection{Meta-functions}
 
 Again, logical arrays are interpreted in \emph{column major order} when passed to \matl{\#}. However, in this case
 % trailing (or leading)
-\matl{F} values are \emph{not ignored}. This is consistent with MATLAB's behaviour: \matlab+[ii,~] = find([0 4 7 0])+ and \matlab+ii = find([0 4 7 0])+ produce \emph{different} results. In general, functions behave differently depending on the number of outputs with which they are called, regardless of whether some of those outputs will be ignored; and this is true even for ignored \emph{trailing} outputs. Another example es the \matlab+size+ function: \matlab+s = size(eye(3))+ produces \matlab+[3 3]+, whereas \matlab+[s,~] = size(eye(3))+ produces \matlab+3+. These would be done in MATL as \matl{3XyZy} and \matl{3XyTF\#Zy} (\matl{Xy} is \matlab+eye+, and \matl{Zy} is \matlab+size+, which is called with one output argument by default).
+\matl{F} values are \emph{not ignored}. This is consistent with MATLAB's behaviour: \matlab+[ii,~] = find([0 4 7 0])+ and \matlab+ii = find([0 4 7 0])+ produce \emph{different} results. In general, functions behave differently depending on the number of outputs with which they are called, regardless of whether some of those outputs will be ignored; and this is true even for ignored \emph{trailing} outputs. Another example is the \matlab+size+ function: \matlab+s = size(eye(3))+ produces \matlab+[3 3]+, whereas \matlab+[s,~] = size(eye(3))+ produces \matlab+3+. These would be done in MATL as \matl{3XyZy} and \matl{3XyTF\#Zy} (\matl{Xy} is \matlab+eye+, and \matl{Zy} is \matlab+size+, which is called with one output argument by default).
 
 \begin{pending}
 This may be a little surprising. One tends to think that adding outputs to a function call won't affect the preceding outputs. But in some cases it does. So saying ``Use the first output of \matlab+find+ to obtain the result'' is not strictly correct, because it's ambiguous: ``Which first output? The one I get when calling the function with two outputs? With one output? \ldots?''.