Index: doc/aaron_comp_II/comp_II.tex
===================================================================
--- doc/aaron_comp_II/comp_II.tex	(revision e93bc139d5875e01ecedf2bff11dab79ab0f02af)
+++ doc/aaron_comp_II/comp_II.tex	(revision a2f920fd2c573edb4b70470fe5d94960bd140fed)
@@ -156,13 +156,19 @@
 
 forall(otype M | has_magnitude(M))
-int sgn( M m ) {
+M abs( M m ) {
     M zero = 0;  // uses zero_t constructor from trait
-    if ( m < zero ) return -1;
-    if ( zero < m ) return 1;
-    return 0; 
-}
-
-// TODO write another function
-\end{lstlisting} 
+    return m < zero ? -m : m;
+}
+
+forall(otype M | has_magnitude(M))
+M max_magnitude( M a, M b ) {
+    M aa = abs(a), ab = abs(b);
+    return aa < ab ? b : a; 
+}
+\end{lstlisting}
+
+Semantically, a trait is merely a named list of type assertions, but they can be used in many of the same situations where an interface in Java or an abstract base class in \CC would be used.
+Unlike Java interfaces or \CC base classes, \CFA types do not explicitly state any inheritance relationship to traits they satisfy; this can be considered a form of structural inheritance, similar to interface implementation in Go, as opposed to the nominal inheritance model of Java and \CC. 
+% TODO talk about modelling of nominal inheritance with structural inheritance, possibility of investigating some resolver algorithms that require nominal
 
 \subsection{Name Overloading}