Issues framing lstlisting with Matlab Code

Question

I cannot for the life of me figure out how to get a frame working around this listing. I'm still very new to Latex. From my understanding, the mcode package is what formats the listing into code from matlab. Everytime I trye to frame it with \framebox{\parbox{\dimexpr\linewidth-2\fboxsep-2\fboxrule}{ ..CODE..}}

I get the error..

("C:\Program Files (x86)\MiKTeX 2.9\tex\latex\psnfss\t1pcr.fd")
Runaway argument?
! Paragraph ended before \lst@next was complete.
<to be read again> 
                   \par 
l.77 }}

This is the entire part that I need to frame (including packages).

\usepackage{amssymb,amsfonts,amsmath}
\usepackage[letterpaper,margin=1in]{geometry}
\usepackage{graphicx}
\usepackage[numbered]{matlab-prettifier}
\usepackage[]{mcode}
\usepackage{adjustbox}
\usepackage[T1]{fontenc}
\usepackage{mathtools}
\usepackage{color}
\usepackage{float}

\framebox{\parbox{\dimexpr\linewidth-2\fboxsep-2\fboxrule}{
\begin{parts}
\part \textbf{Solution:} Conversion of gausselim to gaussdet
\begin{lstlisting}
function d = gaussdet(a)
[n,m] = size(a);
for j = 1:n
    den = a(j,j);
    for i = j+1:n
        mult = a(i,j)/den;
        a(i,j+1:n) = a(i,j+1:n)-mult*a(j,j+1:n);
    end
end
d = zeros(1,n);
for j = 1:n
    d(j) = a(j,j);      %Diagonal elements of a
end
d = prod(d);            %Product of the diagonal elements extracted  
end
\end{lstlisting}


\part  Matrix size vs. Computation time of gaussdet and cofactor functions \\ 
On last page\\
\part Have a look at the documentation for the built-in Matlab function \verb$det$. What method is Matlab using to compute the determinant?\\

Matlab's built-in $det( )$ function uses an $\mathbf{LU}$ factorization. Once the matrix is factored, it computes the products of the diagonals. \\

 What are some of the potential limitations of this approach? \\
Obvious limitations are the fact that floating point numbers in a computer are limited. When the matrix is built and computed, each iteration is subject to round-off errors, resulting in an inaccurate computation. Other limitations arise from this fact such as a matrix with elements comprised of very small numbers. As the $ \lim_{i \to n}\rightarrow  0$ , you're computer is subject to increasing round off errors and will eventuall return a value of$ 0$. This doesn't actually convey wether or not the matrix is actually singular.\\
How is it recommended to compute the determinant of the inverse of a matrix? Why?\\
By using the fact that $det(A^{-1}) = \frac{1}{det(A)}$ \\
The other option is $AI \xrightarrow[Operations]{Row} IA^{-1} $ where this calculation is subject to rounding error. Then you have to use a function, such as Gaussian Elimination on $A^{-1}$, where you're subject to another set of rounding errors. This can lead to very inaccurate computations.\\

Why? What might lead Matlab to compute a determinant very far from zero for a singular matrix?\\
As mentioned before, the real limitation is the way your computer stores and computes values of floating point integers. If there is sufficient roundoff error when computing a matrix, the returned value can be very wrong.\\
\end{parts}
}}

Answer 1

It is unclear what the parts environment and \parts are doing, so the following solution is provided without that.

Two things from your code snippet you cannot do:

1. Add an lstlisting as part of an argument to a function (like \fbox or \framebox or \parbox).

2. Add a \verb as part of an argument to a function.

Roughly both of the above things are mentioned/covered in verbatim inside a command.

We overcome (1) by storing the entire code snippet in a box (say, \codebox) via the lrbox environment. (2) is easily overcome using \texttt instead of \verb:

\documentclass{article}

\usepackage{amssymb,amsfonts,amsmath}
\usepackage[letterpaper,margin=1in]{geometry}
\usepackage[numbered]{matlab-prettifier}
\usepackage{mcode}

\newsavebox{\codebox}

\begin{document}

% Store the listing/code in a box
\begin{lrbox}{\codebox}
\begin{lstlisting}
function d = gaussdet(a)
[n,m] = size(a);
for j = 1:n
    den = a(j,j);
    for i = j+1:n
        mult = a(i,j)/den;
        a(i,j+1:n) = a(i,j+1:n)-mult*a(j,j+1:n);
    end
end
d = zeros(1,n);
for j = 1:n
    d(j) = a(j,j);      %Diagonal elements of a
end
d = prod(d);            %Product of the diagonal elements extracted  
end
\end{lstlisting}
\end{lrbox}

\noindent
\framebox{\parbox{\dimexpr\linewidth-2\fboxsep-2\fboxrule}{%
\textbf{Solution:} Conversion of gausselim to gaussdet

\usebox{\codebox}

Matrix size vs. Computation time of gaussdet and cofactor functions
On last page, Have a look at the documentation for the built-in Matlab function \texttt{det}. What method is Matlab using to compute the determinant?

Matlab's built-in \texttt{det( )} function uses an~$\mathbf{LU}$ factorization. Once the matrix is factored, it computes the products of the diagonals.

What are some of the potential limitations of this approach?
Obvious limitations are the fact that floating point numbers in a computer are limited. When the matrix is built and computed, each iteration is subject to round-off errors, resulting in an inaccurate computation. Other limitations arise from this fact such as a matrix with elements comprised of very small numbers. As the $ \lim_{i \to n}\rightarrow  0$, you're computer is subject to increasing round off errors and will eventuall return a value of~$0$. This doesn't actually convey wether or not the matrix is actually singular.

How is it recommended to compute the determinant of the inverse of a matrix? Why?
By using the fact that $\text{det}(A^{-1}) = \frac{1}{\text{det}(A)}$

The other option is $AI \xrightarrow[\text{Operations}]{\text{Row}} IA^{-1}$ where this calculation is subject to rounding error. Then you have to use a function, such as Gaussian Elimination on $A^{-1}$, where you're subject to another set of rounding errors. This can lead to very inaccurate computations.

Why? What might lead Matlab to compute a determinant very far from zero for a singular matrix?

As mentioned before, the real limitation is the way your computer stores and computes values of floating point integers. If there is sufficient roundoff error when computing a matrix, the returned value can be very wrong.
}}
\end{document}

Answer 2

lstlisting is a verbatim environment an cannot be put in a box like that. The easiest solution is to use the frame key provided by the listings package:

\documentclass{article}

\usepackage{listings} % use mcode instead
\usepackage{lipsum}

\begin{document}

\lipsum[1]

\begin{lstlisting}[frame=single, breaklines]
function d = gaussdet(a)
[n,m] = size(a);
for j = 1:n
    den = a(j,j);
    for i = j+1:n
        mult = a(i,j)/den;
        a(i,j+1:n) = a(i,j+1:n)-mult*a(j,j+1:n);
    end
end
d = zeros(1,n);
for j = 1:n
    d(j) = a(j,j);      %Diagonal elements of a
end
d = prod(d);            %Product of the diagonal elements extracted  
end
\end{lstlisting}

\end{document}

Output: