\documentclass{article}

\begin{document}

\def\subI{${}_I$}
\def\subF{${}_F$}
\def\subD{${}_D$}
\def\ifso{\mathbin{?}}

\section{Rounding}

Converting a rational number $x \in {\cal Q}$ to a nearby
integer $n \in {\cal Z}$ can be done in surprisingly many
ways.  We shall take the floor operation
\[ \lfloor x \rfloor = \max \{n \in {\cal Z} | n \le x\} \]
as the basic operation.  We also need $\bot$ (undefined),
even$(n)$ testing whether $n$ is a multiple of 2,
$p \ifso t : f$ (if $p$ then $t$ else $f$), and $\sigma(x)$ =
$x\ge 0 \ifso 1 : -1$.

\begin{tabular}{lll}
exact & $x=\lfloor x\rfloor \ifso \lfloor x \rfloor : \bot$ &
        exception if not integral\\
down  & $\lfloor x \rfloor$             & floor\\
up    & $\lceil x \rceil = -\lfloor -x \rfloor$ & ceiling\\
in    & $\sigma(x)\times\lfloor|x|\rfloor$ & truncate\\
out   & $\sigma(x)\times\lfloor|x|+\frac12\rfloor$ & away from zero\\
even  & $\mbox{even}(\lfloor x\rfloor) \ifso \lfloor x \rfloor
        : \lceil x \rceil$ & round to even\\
odd   & $\mbox{even}(\lfloor x\rfloor) \ifso \lceil x \rceil
        : \lfloor x \rfloor$ & round to odd (not used in practice)
\end{tabular}

None of these is rounding.  For that we need
\[\mbox{nearest} f x = d > \frac12 \ifso \lceil x \rceil :
 d < \frac12 \ifso \lfloor x \rfloor : f(x) \]
\noindent where
$ d = x - \lfloor x \rfloor $

This higher-order function can be combined with the seven conversions
above to make seven ``round to nearest'' modes such as nearest out
(banker's rounding) or nearest even (IEEE rounding).

The claim of this paper is that executable specifications are important
to find and correct mistakes.  Did you notice the mistake(s) above?
Neither did two pre-publication readers.  The problem is that rounding
$x$ to an even (odd) integer is not well defined when $x$ is an odd (even)
integer.  This issue was discovered by testing.  The solution for even
is simple: if $x$ is exactly equal to an odd integer, round it to the
nearest multiple of 4.  There is no sensible way to round 0 to an odd
integer, so we strike odd rounding from the list.

\section{Existing standards}

\subsection{ISO 10967 Language-independent arithmetic}

Roughly speaking, the three parts of LIA cover everything
in Fortran 95 and C99 and a little bit more.

We have to discuss ISO 10967 for two reasons: it is the
standard that is meant to serve as a reference for arithmetic
in programming languages, and it does define fixed point
numbers (but no operations on them).  Any definition of
fixed point arithmetic should be practically compatible with it.

Further, the 1998 edition provided axioms (though no evidence
that the system described was consistent with them) which could
serve as models for checking a fixed-point specification.

The Language-independent arithmetic standard has three parts.

\subsubsection{Part: 1 Integer and floating point arithmetic}
An integer data type $I$ has parameters {\it bounded}\subI{}
true if the set is finite, {\it minint}\subI{} being the
smallest value or $-\infty$, and {\it maxint}\subI{} being the
largest value or $\infty$.  If {\it bounded}\subI{} is true,
then {\it minint}\subI{} can be 0, -{\it maxint}\subI{}, or
-({\it maxint}\subI{}+1).  Curiously, while both signed and
unsigned bounded integers are allowed, unbounded integers
must be signed; ``unbounded natural numbers are not covered
by this document.''  The usual 6 comparison operations are
defined.

The arithmetic operations are {\it neg}\subI{} (unary negation),
{\it add}\subI{}, {\it sub}\subI{}, {\it mul}\subI{},
flooring division {\it quot}\subI{} and the corresponding
remainder {\it mod}\subI{}, {\it abs}\subI{},
and {\it signum}\subI{} taking values 1 and -1.  The 1998 edition
included {\it sign}\subI{} with values 1, 0, and -1, but that was
dropped.  The 1998 edition included
truncating division {\it div}${}^t_I$ and the corresponding
remainder {\it rem}${}^t_I$ and two additional remainder functions
{\it mod}${}^a_I$ and {\it mod}${}^p_I$, all of which were deleted
in the 2012 edition.

LIA-1 integer arithmetic must handle overflow by causing
an overflow indication.  This includes conversion to a
smaller integer type.  Wrapping arithmetic is covered in
part 2.

A floating point data type $F$ has parameters {\it r}\subF{}
(radix), {\it p}\subF{} (precision), {\it emax}\subF{} (largest
exponent), {\it emin}\subF{} (smallest exponent),
{\it denorm}\subF{} (whether IEEE-style subnormals are supported),
and {\it ice\_60559}\subF{} (whether $F$ conforms to the IEEE
standard).  The usual 6 comparison operations are defined,
taking care to dodge around infinities and NaNs.

Additional tests {\it isnegzero}\subF{}, {\it istiny}\subF{},
{\it isnan}\subF{}, and {\it issignan}\subF{} express tests that
cannot be done using ordinary comparison against zero.

Three sets of basic operations (rounding to nearest even, down,
or up) are defined if {\it denorm}\subF{} is true, just the
rounded to nearest set if {\it denorm}\subF{} is false.
The basic operations are {\it add}, {\it sub}, {\it mul},
{\it div}, and {\it sqrt}.

Some arithmetic operations are not sensitive to rounding
mode: {\it abs}\subF{}, two-valued {\it signum}\subF{},
the IEEE remainder {\it residue}\subF{}, {\it intpart}\subF{},
{\it fractpart}\subF{}, {\it succ}\subF{} (next higher),
{\it pred}\subF{} (next lower), and {\it ulp}\subF{}.

There are three conversions from floating point to integer:
{\it ceiling}${}_{F\rightarrow I}$,
{\it floor}${}_{F\rightarrow I}$, and
{\it rounding}${}_{F\rightarrow I}$.

Section 5.3.5 defines floating point to fixed point conversion
(for the sake of format conversions like C's {\tt \%.$n$f}) and in
passing defines unbounded fixed point types, with parameters
{\it r}\subD{} (radix), {\it d}\subD{} (``density'' = scale),
and {\it dmax}\subD{} (a positive element of $\cal R$ or
undefined).  Two sets are defined:
\begin{eqnarray*}
D^* &=& \{n/(r_D^{d_D}) | n \in {\cal Z}\}\\
D &=& D^* \mbox{if unbounded}\\
D &=& D^* \cap [-dmax_D,dmax_D] \mbox{if bounded}
\end{eqnarray*}
Three rounding functions {\it nearest}\subD{} (our nearest even),
{\it up}\subD{} (ceiling), and
{\it down}\subD{} (floor), all ${\cal R} \rightarrow D^*$, are
defined.  Conversion from floating point to fixed point and
from fixed point to floating point uses one of these rounding
modes just like the basic arithmetic operations.

However, fixed point exists in LIA {\it only} for I/O conversion;
there are no comparison or arithmetic operations on $D$.

Floating point arithmetic with truncation is conspiciously
absent from the 2012 edition of LIA-1.  What it describes is
accurately rounded arithmetic and the building blocks for
interval arithmetic.

\subsubsection{Part: 2 Elementary numerical functions}

This part was issued in 2001.  There are some slight ``continuity
errors'' due to the revision of LIA-1: {\it iec\_559}\subF{} is
now {\it iec\_60559}\subF{}, for example.  This is another example
of why standards need to be machine-checked.

The additional integer operations include maximum, minimum,
greatest common divisor, and least common multiple
of a pair or sequence, if $x\ge y$ then $x-y$ else 0 (diminish),
integer power (but broken for $0^0$ so of very little use),
floored shifting by a power of 2 or 10, floored square root,
divisibility, evenness, oddness, floored ({\it quot}\subI{},
{\it mod}\subI{}), rounded ({\it ratio}\subI{}, {\it residue}\subI{}),
and ceilinged ({\it group}\subI{}, {\it pad}) quotient and remainder.
(The {\it pad} operation is actually $\lceil x/y \rceil\times y - x$.)

There are also wrapping versions of {\it add}, {\it sub}, and
{\it mul}, plus ``overflow'' versions giving you the high bits
lost by wrapping so that multiprecision arithmetic can be written.

The additional floating point operations include maximum and
minimum of a pair or sequence, diminish,  conversion to integral
in floating form ({\it floor}\subF{}, {\it rounding}\subF{}, and
{\it ceiling}\subF{}) together with {\it *\_rest}\subF{} operations
providing the lost fraction parts exactly, square root (already
in part 1) and reciprocal square root.  There is an operation
for multiplying two floats giving a result in a wider format with
a single rounding, just right for dot product.

The elementary transcendental operations include raising a
floating point number to an integer or floating point power,
plus the usual exponential, logarithmic, trigonometric, and
hyperbolic functions in several forms.

\subsubsection{Part 3: Complex integer and floating point
arithmetic and complex elementary numerical functions}

This part was issued in 2006.  It defines imaginary and
complex integer and imaginary and complex floating point
data types, basic operations on them, and elementary
transcendental operations.  Maximum and minimum are extended
to imaginary but not to complex types.

Part 3 ends with recommended changes to some of the operations
defined in Part 2 ``so that the returned angle is for the
proper quadrant''.  Again this suggests that a standard on which
great care was taken might have benefited from testing.

\section{ISO/IEC/IEEE 60559:2011}

This is the standard for floating point arithmetic.
It is the ISO/IEC edition of IEEE 754:2008, which in
turn was an update of classic IEEE 754 arithmetic to
include decimal floating point.  It specifies
32-, 64-, and 128-bit binary formats that can hold about 7,
16, and 34 decimal digits respectively
and 64- and 128-bit decimal formats that can hold
16 and 34 decimal digits respectively (table 3.2).

It is common belief that IEEE 754 arithmetic is all but
universal.  However, few systems support 128-bit binary floats
(the popular ARM, x86, and x86-64 architectures do not; SPARC
does), and even fewer support decimal floating-point natively
(recent IBM z/Series and POWER machines do).

IEEE 754 originally defined four rounding modes, up, down, in,
and nearest even in our terminology.  The current standard
adds nearest out (banker's rounding).

\subsection{COBOL}

COBOL is one of the oldest programming languages still in use.
It was designed to support accounting applications on small
machines.  For example, the Siemens 3003, regarded as ``a large-scale
\dots computer'', had 8000 words of
storage; the COBOL 61 compiler for that machine needed 10 passes.
Brinch Hansen and House [ref] report that ``The major problem of
implementation turned out to be the numerous definition problems
created by the vagueness of the official Cobol report.''

One of the major features of COBOL from the beginning was its
use of decimal fixed point arithmetic rather than floating point.
Accounting applications required answers that were exact or
computed according to known rounding rules.  Binary integers
and floats were eventually adopted in 2002, but had been common
extensions for many years.

A number is characterised by (a) whether it is signed or not,
(b) its precision, and (c) its scale.  A declaration like\\
77 SOME-NUMBER PICTURE S9$(b)$V$9(a)$\\
declares a signed variable (S) with a precision of $b+a$
decimal digits and a scale of $a$.  The letter V designates
a virtual (not actually stored) decimal point.  In terms of
LIA-1, this corresponds to $r_D = 10$, $d_D = a$,
{\it dmax}${}_D = (10^{a+b}-1)/10^b$.

In LIA-1, arithmetic is only defined between values of the
same type.  In COBOL, it is extremely common for the
operands and result of an operation to be of different types.
A typical instruction is
\begin{tabbing}
www\=\kill
MULTIPLY X BY Y GIVING Z ROUNDED\\
\> ON SIZE ERROR {\it statements}\\
\>  NOT SIZE ERROR {\it statements}\\
END MULTIPLY
\end{tabbing}
\noindent where the product $X\times Y$ is computed
according to exact rational arithmetic, rounded to the
scale of $Z$, and if the result is too large to fit,
the ON SIZE ERROR statements are executed, otherwise
the result is stored in Z and the NOT SIZE ERROR
statements are executed.

\subsubsection{Four semantics for arithmetic}

The previous paragraph is a lie.  The current COBOL standard does not
offer a semantics for arithmetic.  It offers {\it four} semantics for
arithmetic.  A COBOL program may contain an OPTIONS paragraph near
the beginning:
\begin{tabbing}
www\=wwwwwwwwwwwwwwww\=\kill
OPTIONS.\\
\> [ARITHMETIC IS \{NATIVE $|$ STANDARD $|$\\
\> \> STANDARD-BINARY $|$ STANDARD-DECIMAL \}]\\
\> [DEFAULT ROUNDED MODE IS one of eight]\\
\> \dots\\
\> [INTERMEDIATE ROUNDING IS one of four]\\
\end{tabbing}

In our terminology, the rounding modes are out, nearest out,
nearest even, nearest in, exact, up, down, and in.

There is a subtle difference between these statements:
\begin{tabbing}
MULTIPLY X BY Y GIVING Z.\\
COMPUTE Z = X * Y.
\end{tabbing}
The latter involves an arithmetic expression which has an
intermediate result that is then assigned to the destination.
The former does not.  It appears that the MULTIPLY statement
involves a single rounding whereas the COMPUTE statement may
involve a double rounding.

{\it Native} arithmetic is whatever the implementor says it is.

{\it Standard} arithmetic is what used to be standard arithmetic in
COBOL-85.  It does not cover binary or floating-point operations,
which are treated as native.  Standard arithmetic is declared to
be obsolete.  ``A standard intermediate data item is \dots the
unique value zero or an abstract, signed, normalized decimal
floating-point temporary data item \dots with a precision of
32 decimal digits'' and a scale of -999 to 999 (roughly speaking).
Intermediate values are rounded in certain circumstances.

In expressions,
addition, subtraction, multiplication, and
division are are ``the exact [result] truncated
to 32 significant digits, normalized, and stored in a standard
intermediate data item''.

{\it Standard-binary} arithmetic requires arithmetic operations
to be done according to IEEE binary floating-point
arithmetic (128-bit format).

{\it Standard-decimal} arithmetic requires arithmetic operations
to be done according to IEEE decimal floating-point arithmetic
(128-bit format).

The result is that the meaning of an arithmetic statement or
expressions can be changed by a line thousands of lines away.

The standard tries very hard to avoid using
mathematical notation.  Let us take Format 5 of the
DIVIDE statement as an example:
\begin{quote}
\begin{tabbing}
www\=\kill
DIVIDE \{identifier-2$|$literal-2\} BY \{identifier-1$|$literal-1\}\\
\> GIVINE identifier-3 [rounded-prhase]\\
\> REMAINDER identifier-4\\
\> [ON SIZE ERROR imperative-statement-1]\\
\> [NOT SIZE ERROR imperative-statement-2]\\
\> [END-DIVIDE]
\end{tabbing}

1) When native arithmetic is in effect, the quotient is the result
of dividing the dividend by the divisor.  When standard arithmetic,
standard-decimal arithmetic, or standard-binary arithmetic is in
effect, the quotient is the result of the arithmetic expression
$$(\mbox{dividend} / \mbox{divisor})$$
where the values of dividend and divisor are ...

6b) The quotient is then formed as specified in general rule 1
and stored in identifier-3 \dots

6c) If the size error condition is not raised, a subsidiary
quotient is developed that is signed and derived from the
quotient by truncation of digits at the least significant end
and that has the same number of digits and the same decimal point
location as the data item references by identifier-3.  The
remainder is calculated as indicated in general rules 7 and is
stored in the data item referenced by identifier-4 unless
storing the value would cause a size error condition \dots

7) When native arithmetic is in effect, the remainder is the
result of multiplying the subsidiary quotient and the divisor
and subtracting the product from the dividend.  When standard
standard arithmetic, standard-decimal arithmetic, or
standard-binary arithmetic is in effect, the remainder is the
result of the arithmetic expression
$$(\mbox{divided} - (\mbox{subsidiary-quotient} * \mbox{divisor}))$$
where \dots
\end{quote}

The reason the standard {\it does} use some expressions here is
so that the rules for intermediate rounding apply to them.  With
4 arithmetics, 8 intermediate roundings, and 4 default roundings,
a simple DIVIDE statement could mean 128 different things.

\subsection{PL/I}

PL/I was introduced in the mid-1960s as a blend of Algol,
Fortran, and COBOL.  The ECMA-50 (1976), ANSI X3.53-1976, BS 7148:1990,
NF Z 65-500, and ISO 6160:1979 standards for PL/I are all basically the
same.  They have expired.  BS ISO/IEC 6522:1992 (Information technology,
Programming languages, PL/I general purpose subset) is still current.

PL/I fixed point types are characterised by a {\it base} (2 or 10),
a {\it precision} (total number of digits), and a {\it scale} (number
of digits after the radix point).  There are actually two sets of
rules for determining the precision and scale of a result (ANSI and
IBM).  For FIXED DECIMAL they coincide:
\begin{itemize}
\item
$(p_1,s_1) \pm (p_2,s_2) \Rightarrow (p,s)$ where\\
$s = s_1 \vee s_2$\\
$p = 1+s+(p_1-s_1 \vee p_2-s_2)$
\item
$(p_1,s_1) \times (p_2,s_2) \Rightarrow (p,s)$ where\\
$s = s_1 + s_2$\\
$p = 1+p_1+p_2$
\item
$(p_1,s_1) / (p_2,s_2) \Rightarrow (p,s)$ where\\
$s = N-p_1+s_1-s+2$\\
$p = N$ and $N$ is the implementation-defined maximum precision.
\item
MOD$((p_1,s_1), (p_2,s_2)) \Rightarrow (p,s)$ where\\
$s - s_1 \vee s_2$\\
$p = N \wedge (p_2 - s_2 + s)$.
\item
$(p_1,s_1) ** k \Rightarrow (p,s)$ where\\
$s = s_1\times k$\\
$p = (p_1 + 1) \times k - 1$, if $k$ is a literal integer.
\item
ROUND$((p_1,s_1), s) \Rightarrow (p,s)$ where\\
$s$ is given as the second argument\\
$p = 1 \vee (p_1-s_1+1-s \wedge N)$
\end{itemize}
The rule for division can lead to some nasty surprises.
For example, 25+01/3 yields 25.3333333333333 but
25+1/3 results in an overflow.  So there are special functions
ADD(x, y, p[, s]), SUBTRACT(x, y, p[, s]),  MULTIPLY(x, y, p[, s]),
DIVIDE(x, y, p[, s]),
computing a result to a specified precision and scale (default s = 0)
in a single rounding.  There is no version of MOD with precision and
scale parameters.  In assignment
statements, ``padding or truncation can occur on the left or the right.
If nonzero \dots digits on the left are lost, the SIZE condition is
raised.''  This means that a statement like\\
X = X * Y;\\
uses the ``in'' rounding mode.  Unlike COBOL, PL/I does not offer
control over rounding, not even using the special functions, so there is
no way to change this.

\subsection{SQL}

The ISO/IEC 9075-1:2003 standard, SQL 2003, part 1,
says in section 4.4.3.1 that ``There are two classes of numeric
type: {\it exact numeric}, which includes integer types and types
with specified precision and scale; and {\it approximate numeric},
which is essentially floating point, and for which a precision may
optionally be specified.''  The result of an arithmetic operation
``is of a numeric type that depends only on the numeric type of the
operands.  If the result cannot be represented exactly in the result
type, then whether it is rounded or truncated is implementation-defined.
An exception condition is raised if the result is outside the range of
numeric values of the result type, or if the arithmetic operation is not
defined for the operands.''

Numbers and arithmetic are defined in
section 4.4 of part 2.
\begin{quote}
`An exact numeric type has a precision
$P$ and a scale $S$.  $P$ is a positive integer that determines
the number of significant digits in a particular radix $R$,
where $R$ is either 2 or 10.  $S$ is a non-negative integer.
Every value of an exact numeric type of scale $S$ is of the
form $n\times 10^{-S}$,\footnote{It is possible that 10 should
have been $R$, but only INTEGER types with $S=0$ may have $R=2$.}
where $n$ is an integer such that $-R^P \le n < R^P$.
[Note 13 --- Not every value in that range is necessarily a
value of the type in question.]''
\end{quote}
The intent of note 13 may be to allow both sign-and-magnitude
representation for NUMERIC types and $R$'s-complement representation
for INTEGER types; it's not obvious why any other value would be
excluded.

Conversion may be done by rounding or truncation; it is not the
programmer who chooses.
\begin{quote}
``If an assignment of some number would result in a loss of its most
significant digit, an exception condition is raised.  If least
significant digits are lost, implementation-defined rounding or
truncating occurs, with no exception condition being raised.''

``An approximation obtained by truncation of a numeric value $N$ for an
$\langle$exact numeric type$\rangle$ $T$ is a value $V$ in $T$
such that $N$ is not closer to
zero than is $V$ and there is no value in $T$ between $V$ and $N$.

An approximation obtained by rounding of a numeric value $N$ for an
$\langle$exact numeric type$\rangle$ $T$ is a value $V$ in $T$
such that the absolute value of the difference between $N$
and the numeric value of $V$ is not greater than half
the absolute value of the difference between two successive numeric
values in $T$. If there is more than one such value $V$, then it is
implementation-defined which one is taken.''
\end{quote}

Aside from the non-portable nature of rounding,
arithmetic is supposed to be unsurprising:
\begin{quote}
``Operations on numbers are performed according to the normal
rules of arithmetic, within implementation-defined limits \dots''

``Numbers are compared with respect to their algebraic value.'' (8.2)
\end{quote}

Paraphrasing sections 4.4.3 and 6.26,
\begin{itemize}
\item The POWER function never returns an exact answer (unlike PL/I).
\item The floor and ceiling functions return exact integers $S=0$.
\item Unary plus, unary minus, and the absolute value function return a result
of the same type as their argument.
\item  The MOD function only accepts integer arguments.
\item WIDTH\_BUCKET$(x, l, u, n)$ appears to mean
\begin{tabbing}
www\=www\=\kill
if $l < u$ then\\
\> if $x<l$ then 0\\
\> else if $x \ge u$ then $n+1$\\
\> else $\lfloor n\times((x-l)/(u-l)) \rfloor$\\
else if $l > u$ then\\
\> if $x > l$ then 0\\
\> else if $x < u$ then $n+1$\\
\> else $\lfloor n\times((x-u)/(l-u)) \rfloor$\\
\end{tabbing}
and the result has the same type as $n$, which must be integral.
A system that can implement this function ought to be able to
implement MOD on non-integral exact numbers.
\item If $x$ has radix $R$, precision $P_x$, and scale $S_x$,
and $y$ has radix $R$, precision $P_y$, and scale $S_y$,
then $x+y$ and $x-y$ have scale max$(S_x,S_y)$ and
implementation-defined precision;
\item $x*y$ has scale $S_x+S_y$ and implementation-defined precision;
\item and $x/y$ has implementation-defined precision and
implementation-defined scale.
\item ``If the operator is not division and the mathematical result of
the operation is not exactly representable with the precision and scale
of the result data type, then an exception condition is raised.''
\item ``If the operator is division and the approximate mathematical
result of the operation represented with the precision and scale of the
result data type loses one or more leading significant digits after
rounding or truncating if necessary, then an exception condition is
raised \dots The choice of whether to round or truncate is
implementation-defined.''
\end{itemize}

COBOL and PL/I have fixed-point decimal types in order to support
accounting.
SQL was given fixed-point NUMERIC types in order to inter-operate
with COBOL and PL/I, and is very much used for accounting data.
The problem is that SQL arithmetic is {\it not} guaranteed
to be consistent with COBOL or PL/I or accounting rules:
\begin{itemize}
\item there is no programmer control over rounding;
\item there are no precisions that have to be supported,
not even older COBOL's 18 digits;
\item there is no fixed-point remainder; and
\item if you want to calculate the price of one
apple at \$2.72 per dozen, $2.72/12$ could give
you the answer 0 if an implementation defined the
scale for division to always be $S=0$.
\end{itemize}

\subsection{Smalltalk}

Smalltalk-80 is the programming language that brought Object-Oriented
programming and Integrated Development ENvironments to the world.
It got an ANSI standard in 1989.  The standard includes unbounded
integers, three sizes of floating point, rational numbers, and
a ScaledDecimal class.

For the semantics of operations on ScaledDecimal numbers,
the Smalltalk standard defers to ISO 10967 (LIA).  Unfortunately, LIA has,
by intent and quite explicitly, nothing to say about fixed point
arithmetic.

The result is that implementations use one of four interpretations
of ScaledDecimal:
\begin{itemize}
\item An arbitrary precision integer scaled by a power of 10.
This agrees well with the standard, which says that
``Scaled decimal objects provide a precise representation of decimal
fractions with an explicitly specified number of fractional digits.''.
\item An integer scaled by a power of 10, represented as a 16-byte
packed decimal value.  This also agrees well with the standard.
\item An arbitrary precision rational number that is not in general
a whole multiple of a power of 10, rounded to a specified number of
digits when and only when printing.
\item The same, but with truncation instead of rounding.
\end{itemize}
For example,
\begin{tabbing}
(2/3) asScaledDecimal: 2 $\Longrightarrow$ 0.66s2\\
``and'' 0.66s2 * 3 $\Longrightarrow$ 1.98s2\\
``but'' ((2/3) asScaledDecimal: 2) * 3 $\Longrightarrow$ 2.00s2
\end{tabbing}
in several Smalltalks (several others yield 0.67s2), while
\begin{tabbing}
(2/3) asScaledDecimal: 2 $\Longrightarrow$ 0.67s2\\
0.67s2 * 3 $\Longrightarrow$ 2.01s2\\
((2/3) asScaledDecimal: 2) * 3 $\Longrightarrow$ 2.01s2
\end{tabbing}
in Smalltalks using a scaled-integer interpretation.

% Standard: #+ #- #* #/ result scale is at least receiver scale.
% Majority rule: result scale is max(receiver scale, operand scale).
% astc: #+ #- => max(r,o); #* => r+o #/ ->
% astc: x \\ y = x - ((x // y) * y) => #- rule
%       x rem: y = x - ((x quo: y) * y) => #- rule.

\subsection{C$\sharp$}

Summary: decimal arithmetic is standard in C$\sharp$.
Such numbers are value types, as in COBOL and PL/I.
C$\sharp$ does not support sufficient precision or sufficient scale
to allow unproblematic conversion of COBOL 2002 code or
data, though it is adequate for COBOL 85.  There is no
programmer control over rounding.  Scale is part of the
value, not part of the type, and the rule for division
makes it hard to track scale at compile time.  Above all,
decimal arithmetic in C$\sharp$ is exact {\it except when
it isn't}.  The compiler will not tell you when unexpected
rounding {\it might} happen, nor does the runtime system
tell you when it {\it has} happened.

ISO/IEC 23270:2006 defines C$\sharp$ as it was in 2005.
ISO/IEC 23231:2012 defines the Common Language Infrastructure
The CLI standard omits the ``Extended numerics library'' (section
IV.5.7), including System.Decimal, but the language standard
has much to say.

Section 8.2.1 says
\begin{quote}
The {\tt decimal} type is appropriate for calculations in which
rounding errors caused by floating-point representations are
unacceptable.
\end{quote}

Except for rounding errors introduced silently by C$\sharp$ itself.

Section 11.1.7 defines the {\tt decimal} type.
\begin{quote}
The {\tt decimal} type is a 128-bit data type suitable for
financial and monetary calcuations.  The {\tt decimal} type
can represent values including those in the range $1\times 10^{-28}$
through $1\times 10^{28}$ with at least 28 significant digits.
The finite set of values of of type {\tt decimal} are of the
form $(-1)^s\times c\times 10^{-e}$, where the sign $s$ is 0 or 1,
the coefficient $c$ is given by $0\le c<Cmax$ and the scale $e$
is such that $Emin\le e\le Emax$, where $Cmax$ is at least
$1\times 10^{28}$, $Emin\le 0$, and $Emax\ge 28$.  The decimal
type does not necessarily support signed zeros, infinities, or
NaN's.

A {\tt decimal} is represented as an integer scaled by a power of
ten.  For {\it decimal}s with an absolute value less than {\tt 1.0m},
the value is exact to at least the 28${}^{th}$ decimal place.
For {\tt decimal}s with an absolute value greater than or equal to
{\tt 1.0m}, the value is exact to at least 28 digits.  Contrary
to the {\tt float} and {\tt double} data types, decimal fractional
values such as {\tt 0.1} can be represented exactly in the
{\tt decimal} representation.  In the {\tt float} and {\tt double}
representations, such numbers often have non-terminating binary
expansions, making those representations more prone to round-off errors.

The result of an operation on values of type {\it decimal} is that
which would result from calculating an exact result (preserving
scale, as defined for each operator) and then rounding to fit the
representation.  Results are rounded to the nearest representable
value, and, when a result is equally close to two representable
values, to the value that has an even number in the least significant
digit position (this is known as ``banker's rounding'').  That is,
results are exact to at least the 28${}^{th}$ decimal place.
Note that rounding may produce a zero value from a non-zero value.

If a {\tt decimal} arithmetic operation produces a result whose magnitude
is too large for the {\tt decimal format}, a
{\tt System.OverflowException} is thrown.

The {\tt decimal} type has greater precision but may have a smaller
range than the floating-point types.  Thus, conversions from the
floating-point types to {\it decimal} might produce overflow
exceptions, and conversions from {\tt decimal} to the floating-point
types might cause loss of precision or overflow exceptions.  For
these reasons, no implicit conversions exist between the floating-point
types and {\tt decimal}, and without explicit casts, a compile-time
error occurs when floating-point and {\tt decimal} operands are
directly mixed in the same expression.
\end{quote}

Section 14.7, ``arithmetic operators'', says
\begin{quote}
The scale of the result [of a decimal multiplication],
before any rounding, is the sum of the scales of the two operands.

The scale of the result [of a decimal division],
before any rounding, is the closest scale to the preferred scale which
will preserve a result equal to the exact result.  The preferred scale
is the scale of x less the scale of y.

The scale of the result [of a decimal remainder],
before any rounding, is the larger of the scales of the two operands,
and the sign of the result, if non-zero, is the same as that of [the
first operand].

The scale of the result [of a decimal addition or subtraction],
before any rounding, is the larger of the scales of the two operands.
\end{quote}

With the exception of division, the scale rules are familiar and
sensible. There is no division method that
takes a desired scale argument, unlike PL/I.

The scale rule for division appears to be intended to
ensure that scale($(x*y)/y$) = scale($x$), but if we take
{\tt 1.0m/3.0m} there is {\bf no} scale which ``will preserve a
result equal to the exact result'', and this is the case for almost
every possible division.  What you get is the highest supported scale
that doesn't result in an overflow.

There is no direct way to ask a {\tt decimal} for its scale,
but two numerically equivalent values can be operationally
distinguished:
\begin{tabbing}
1.0m.ToString() $\Longrightarrow$ "1.0"\\
1.00m.ToString() $\Longrightarrow$ "1.00"\\
4.0m/2.0m $\Longrightarrow$ 2\\
4.00m/2.0m $\Longrightarrow$ 2.0
\end{tabbing}

The remainder operator is the counterpart of the operation that
divides two decimal numbers giving an exact integer result.
There is no such operation.

The {\tt System.Decimal} class has methods {\tt Ceiling},
{\tt Round}, {\tt Floor}, and {\tt Truncate} which return exact
integer answers in {\tt decimal} form, no integer
type is certain to be large enough.  The Round method has
optional desired-scale and how-to-round-0.5 arguments,
supporting nearest out and nearest even.

% C$\sharp$ changes faster than ISO processes can keep up with.
% The current specification is C$\sharp$ version 6.0.

\subsection{Java}

Summary: decimal numbers in Java are a reference type,
{\tt java.math.BigDecimal}, not a primitive type.
There are no literals for this type nor
are the usual arithmetic operators available.
It is not described in the Java Language Specification.
However, full control over rounding is possible, and
Java gives exact results unless you ask for rounding.
It {\it is} possible to convert COBOL 2002 and data to
Java.  Any finite {\tt float} or {\tt double} value can
be represented exactly as a {\tt BigDecimal}.

There is no international standard for Java, but there is the
much-revised Java Language Specification
[https://docs.oracle.com/javase/specs/jls/se8/html/index.html]
and the Java Community Process for maintaining Java, which is not
entirely unlike a standards process.

The version of Java current at the time of writing was 1.8,
and that edition of the Java Language Specification has nothing to say
about {\tt BigDecimal}.

The Java API Online Reference
[https://docs.oracle.com/javase/8/docs/api/overview-summary.html]
says that
\begin{quote}
[{\tt BigDecimal}s are i]mmutable, arbitrary-precision
signed decimal numbers.  A {\tt BigDecimal} consists of an
arbitrary precision integer {\it unscaled value} and a 32-bit
integer {\it scale} [which may be positive, negative, or zero].
The value represented by [a] {\tt bigDecimal} is therefore
$(\mbox{unscaledValue} \times 10^{-\mbox{scale}})$.

The {\tt BigDecimal} class gives its user complete control over
rounding behavior.  If no rounding mode is specified and the exact
result cannot be represented, an exception is thrown; otherwise,
calculations can be carried out to a chosen precision and rounding mode
by supplying an appropriate {\tt MathContext} object to the operation.  In
either case, eight rounding modes are provided for the control of
rounding.

When a {\tt MathContext} object is supplied with a precision setting
0f 0 \dots, arithmetic operations are exact.  \dots In the case of
divide, the exact quotient could have an infinitely long decimal
expansion; for example, 1 divided by 3.  If the quotient has a
nonterminating decimal expansion and the operation is specified to
return an exact result, an ArithmeticException is thrown.  Otherwise,
the exact result of the division is returned, as done for other
operations.

Since the same numerical value can have different representations (with
different scales), the rules of arithmetic and rounding must specify
both the numerical result and the scale used in the result's
representation.

For all arithmetic operators, the operation is carried out as though an
exact intermediate result were first calculated and then rounded to the
number of digits specified by the precision setting (if necessary),
using the selected rounding mode.

Besides a logical exact result, each arithmetic operation has a
preferred scale for representing a result.

\begin{tabular}{|l|l|}
\hline
Operation | Preferred Scale of Result\\
\hline
Add | max(addend.scale(), augend.scale())\\
\hline
Subtract | max(minuend.scale(), subtrahend.scale())\\
\hline
Multiply | multiplier.scale() + multiplicand.scale()\\
\hline
Divide | dividend.scale() - divisor.scale()\\
\hline
\end{tabular}

\dots an exact divide may have to use a larger scale [when]
the exact result has more digits.

{\tt BigDecimal}'s {\it natural ordering} is
{\it inconsistent with equals}.
\end{quote}

The issue here is that {\tt compareTo} compares the algebraic
values of two {\tt BigDecimal}s, but {\tt equals} compares
their representations.

Quotient returning an integer in {\tt BigDecimal} form and
corresponding remainder are supported.

\subsection{Swift}

Summary: Swift supports decimal numbers with up to 38 digits
and a scale of -128 to 127.

Swift is a fast-changing language pushed by Apple.
At the time of writing the current version was Swift 3.

Swift 2 supported ``toll-free bridging'' to the Objective-C
type {\tt NSDecimalNumber}, ``[a]n instance [of which]
can represent any number that can be expressed as
mantissa
$\times$
$10^{exponent}$
where mantissa
is a decimal integer up to 38 digits long, and exponent is an
integer from -128 through 127.''

Swift 3 has a native {\tt Decimal} ``value type which offers
the same functionality as the {\tt NSDecimalNumber} reference
type, and the two can be used interchangeably in Swift code
that interacts with Objective-C APIs.''  Literals in integer
or floating-point form can be used where Decimal literals
are wanted, but they are first stored as Int or Float and
then converted to Decimal.

Swift {\tt Decimal}s include a NaN value but not infinities
or negative zero.

The {\tt NSDecimal} methods {\tt adding}, {\tt subtracting}, {\tt multiplying},
{\tt dividing}, and {\tt raising} have an optional
{\tt NSDecimalNumberBehavior} argument, like the corresponding
Java methods, which specifies a desired scale and rounding
mode, which can be up, down, in, or nearest out.
There is also {\tt NSDecimalNumberHandler} which can specify
what to do if an answer is inexact or overflows.
In Swift, there are methods {\tt add, +}, {\tt subtract, -},
{\tt multiply, *}, and {\tt divide, /} without control arguments
and NSDecimalAdd, NSDecimalSubtract, NSDecimalMultiply,
and NSDecimalDivide methods with RoundingMode parameter.

[The current state of the documentation for Swift 3 is
{\bf horrible}.  I'm having serious trouble finding
{\it anything} about how this all works.]

\end{document}


\chapter{Advanced Simplifying Methods}\label{ch07}
\section{Quine-McCluskey Simplification Method}
\subsection{Introduction}

\marginpar{This method was developed by W.V. Quine and Edward J. McCluskey and is sometimes called the method of prime implicants.} When a Boolean equation involves five or more variables it becomes very difficult to solve using standard algebra techniques or Karnaugh maps; however, the Quine-McCluskey algorithm can be used to solve these types of Boolean equations.

The Quine-McCluskey method is based upon a simple Boolean algebra principle: if two expressions differ by only a single variable and its complement then those two expressions can be combined:

\begin{align}
	\label{ASM:eq:quine-mccluskey_combining_complements}
	ABC+ABC' &= AB
\end{align}

The Quine-McCluskey method looks for expressions that differ by only a single variable and combines them. Then it looks at the combined expressions to find those that differ by a single variable and combines them. The process continues until there are no expressions remaining to be combined.

\subsection{Example One}
\label{ASM:subsec:quine-mccluskey_ex_1}

\subsubsection{Step 1: Create the Implicants}
\label{ASM:subsubsec:quine-mccluskey_ex_1_step_1}

Equation \ref{ASM:eq:qm_ex_1} is the Sigma representation of a Boolean equation.

\begin{align}
	\label{ASM:eq:qm_ex_1}
	\int(A,B,C,D)=\sum(0,1,2,5,6,7,9,10,11,14)
\end{align}

Truth Table \ref{ASM:tab:qm_ex_1_minterm_table} shows the input variables for the \emph{True} minterm values.

\begin{table}[H]
	\sffamily
	\newcommand{\head}[1]{\textcolor{white}{\textbf{#1}}}
	\begin{center}
		\rowcolors{2}{gray!10}{white} % Color every other line a light gray
		\begin{tabular}{ccccc}
			\rowcolor{black!75}
			\head{Minterm} & \head{A} & \head{B} & \head{C} & \head{D} \\
			0 & 0 & 0 & 0 & 0 \\
			1 & 0 & 0 & 0 & 1 \\
			2 & 0 & 0 & 1 & 0 \\
			5 & 0 & 1 & 0 & 1 \\
			6 & 0 & 1 & 1 & 0 \\
			7 & 0 & 1 & 1 & 1 \\
			9 & 1 & 0 & 0 & 1 \\
			10 & 1 & 0 & 1 & 0 \\
			11 & 1 & 0 & 1 & 1 \\
			14 & 1 & 1 & 1 & 0
		\end{tabular}
	\end{center}
	\caption{Quine-McCluskey Ex 1: Minterm Table}
  \label{ASM:tab:qm_ex_1_minterm_table}
\end{table}

To simplify this equation, the minterms that evaluate to \emph{True} (as listed above) are first placed in a minterm table so that they form sections that are easy to combine. Each section contains only the minterms that have the same number of ones. Thus, the first section contains all minterms with zero ones, the second section contains the minterms with one one, and so forth. Truth Table \ref{ASM:tab:qm_ex_1_rearranged_table} shows the minterms rearranged appropriately.

\begin{table}[H]
	\sffamily
	\newcommand{\head}[1]{\textcolor{white}{\textbf{#1}}}
	\begin{center}
		% \rowcolors{2}{gray!10}{white} % Color every other line a light gray
		\begin{tabular}{ccc}
			\rowcolor{black!75}
			\head{Number of 1's} & \head{Minterm} & \head{Binary} \\
			0 & 0 & 0000 \\
			\hline
			\multirow{2}{*}{1} & 1 & 0001 \\
							   & 2 & 0010 \\
			\hline
			\multirow{4}{*}{2} & 5  & 0101 \\
							   & 6  & 0110 \\
							   & 9  & 1001 \\
							   & 10 & 1010 \\
			\hline
			\multirow{3}{*}{3} & 7  & 0111 \\
							   & 11 & 1011 \\
							   & 14 & 1110 \\
			\hline
		\end{tabular}
	\end{center}
	\caption{Quine-McCluskey Ex 1: Rearranged Table}
  \label{ASM:tab:qm_ex_1_rearranged_table}
\end{table}

Start combining minterms with other minterms to create Size Two Implicants (called that since each implicant combines two minterms), but only those terms that vary by a single binary digit can be combined. When two minterms are combined, the binary digit that is different between the minterms is replaced by a dash, indicating that the digit does not matter. For example, $ 0000 $ and $ 0001 $ can be combined to form $ 000- $. The table is modified to add a Size Two Implicant column that indicates all of the combined terms. Note that every minterm must be compared to every other minterm so all possible implicants are formed. This is easier than it sounds, though, since terms in section one must be compared only with section two, then those in section two are compared with section three, and so forth, since each section differs from the next by a single binary digit. The Size Two Implicant column contains the combined binary form along with the numbers of the minterms used to create that implicant. It is also important to mark all minterms that are used to create the Size Two Implicants since allowance must be made for any not combined. Therefore, in the following table, as a minterm is used it is also struck through. Table \ref{ASM:tab:quine-mccluskey_ex_1_size_2_implicants} shows the Size Two Implicants that were found.

\begin{table}[H]
	\sffamily
	\newcommand{\head}[1]{\textcolor{white}{\textbf{#1}}}
	\begin{center}
		% \rowcolors{2}{gray!10}{white} % Color every other line a light gray
		\begin{tabular}{ccc|l}
			\rowcolor{black!75}
			\head{1's} & \head{Mntrm}
				& \head{Bin} & \head{Size 2} \\
			                 0 & \sout{0} & 0000 & 000- (0,1) \\
			\cline{1-3}
			\multirow{2}{*}{1} & \sout{1}  & 0001 & 00-0 (0,2) \\
			                   & \sout{2}  & 0010 & 0-01 (1,5) \\
			\cline{1-3}
			\multirow{4}{*}{2} & \sout{5}  & 0101 & -001 (1,9) \\
			                   & \sout{6}  & 0110 & 0-10 (2,6) \\
			                   & \sout{9}  & 1001 & -010 (2,10) \\
			                   & \sout{10} & 1010 & 01-1 (5,7) \\
			\cline{1-3}
			\multirow{3}{*}{3} & \sout{7}  & 0111 & 011- (6,7) \\
			                   & \sout{11} & 1011 & -110 (6,14) \\
			                   & \sout{14} & 1110 & 10-1 (9,11) \\
			\cline{1-3}
			                   &    &      & 101- (10,11) \\
			                   &    &      & 1-10 (10,14) \\
			\hline
		\end{tabular}
	\end{center}
	\caption{Quine-McCluskey Ex 1: Size 2 Implicants}
  \label{ASM:tab:quine-mccluskey_ex_1_size_2_implicants}
\end{table}

All of the Size Two Implicants can now be combined to form Size Four Implicants (those that combine a total of four minterms). Again, it is essential to only combine those with only a single binary digit difference. For this step, the dash can be considered the same as a single binary digit, as long as it is in the same place for both implicants. Thus, $ -010 $ and $ -110 $ can be combined to $ --10 $, but $ -010 $ and $ 0-00 $ cannot be combined since the dash is in different places in those numbers. It helps to match up the dashes first and then look at the binary digits. Again, as the various size-two implicants are used they are marked; but notice that a single size-four implicant actually combines four size-two implicants. Table \ref{ASM:tab:quine-mccluskey_ex_1_size_4_implicants} shows the Size Four Implicants.

\begin{table}[H]
	\sffamily
	\newcommand{\head}[1]{\textcolor{white}{\textbf{#1}}}
	\begin{center}
		% \rowcolors{2}{gray!10}{white} % Color every other line a light gray
		\begin{tabular}{ccc|l|l}
			\rowcolor{black!75}
			\head{1's} & \head{Mntrm}
			& \head{Bin} & \head{Size 2} & \head{Size 4} \\
			                 0 & \sout{0}  & 0000 & 000- (0,1)  & --10 (2,10,6,14) \\
			\cline{1-3}
			\multirow{2}{*}{1} & \sout{1}  & 0001 & 00-0 (0,2)  & \\
			                   & \sout{2}  & 0010 & 0-01 (1,5)  & \\
			\cline{1-3}
			\multirow{4}{*}{2} & \sout{5}  & 0101 & -001 (1,9)  & \\
                               & \sout{6}  & 0110 & \sout{0-10 (2,6)}  & \\
			                   & \sout{9}  & 1001 & \sout{-010 (2,10)} & \\
			                   & \sout{10} & 1010 & 01-1 (5,7)  & \\
			\cline{1-3}
			\multirow{3}{*}{3} & \sout{7}  & 0111 & 011- (6,7)  & \\
			                   & \sout{11} & 1011 & \sout{-110 (6,14)} & \\
			                   & \sout{14} & 1110 & 10-1 (9,11) & \\
			\cline{1-3}
			                   &           &      & 101- (10,11) & \\
			                   &           &      & \sout{1-10 (10,14)} & \\
			\hline
		\end{tabular}
	\end{center}
	\caption{Quine-McCluskey Ex 1: Size 4 Implicants}
  \label{ASM:tab:quine-mccluskey_ex_1_size_4_implicants}
\end{table}

None of the terms can be combined any further. All of the minterms or implicants that are not marked are \emph{Prime Implicants}. In the table above, for example, the Size Two Implicant $ 000- $ is a Prime Implicant. The Prime Implicants will be placed in a chart and further processed in the next step.

\subsubsection{Step 2: The Prime Implicant Table}
\label{ASM:subsubsec:quine-mccluskey_ex_1_step_2}

A \emph{Prime Implicant Table} can now be constructed, as in Table \ref{ASM:tab:qm_ex_1_prime_implicants}. The prime implicants are listed down the left side of the table, the decimal equivalent of the minterms goes across the top, and the Boolean representation of the prime implicants is listed down the right side of the table.

\begin{table}[H]
	\sffamily
	\newcommand{\head}[1]{\textcolor{white}{\textbf{#1}}}
	\begin{center}
		\rowcolors{2}{gray!10}{white} % Color every other line a light gray
		\begin{adjustbox}{max width=\textwidth}
		\begin{tabular}{lccccccccccc}
			\rowcolor{black!75}
			& \head{0} & \head{1} & \head{2} & \head{5}
			& \head{6} & \head{7} & \head{9} & \head{10}
			& \head{11} & \head{14} & \\
							%      0   1   2   5   6   7   9  10  11  14
			$ 000-\;(0,1) $       & X & X &   &   &   &   &   &   &   &   & $ A'B'C' $ \\
			$ 00-0\;(0,2) $       & X &   & X &   &   &   &   &   &   &   & $ A'B'D' $ \\
			$ 0-01\;(1,5) $       &   & X &   & X &   &   &   &   &   &   & $ A'C'D $ \\
			$ -001\;(1,9) $       &   & X &   &   &   &   & X &   &   &   & $ B'C'D $ \\
			$ 01-1\;(5,7) $       &   &   &   & X &   & X &   &   &   &   & $ A'BD $ \\
			$ 011-\;(6,7) $       &   &   &   &   & X & X &   &   &   &   & $ A'BC $ \\
			$ 10-1\;(9,11) $      &   &   &   &   &   &   & X &   & X &   & $ AB'D $ \\
			$ 101-\;(10,11) $     &   &   &   &   &   &   &   & X & X &   & $ AB'C $ \\
			$ --10\;(2,10,6,14) $ &   &   & X &   & X &   &   & X &   & X & $ CD' $ \\
			\hline
		\end{tabular}
		\end{adjustbox}
	\end{center}
	\caption{Quine-McCluskey Ex 1: Prime Implicants}
  \label{ASM:tab:qm_ex_1_prime_implicants}
\end{table}

An \emph{X} marks the intersection where each minterm (on the top row) is used to form one of the prime implicants (in the left column). Thus, minterm $ 0 $ (or $ 0000 $) is used to form the prime implicant $ 000- (0,1) $ in row one and $ 00-0 (0,2) $ in row two.

The Essential Prime Implicants can be found by looking for columns that contain only one \emph{X}. The column for minterm $ 14 $ has only one \emph{X}, in the last row, $ --10 (2,10,6,14) $; thus, it is an Essential Prime Implicant. That means that the term in the right column for the last row, $ CD' $, must appear in the final simplified equation. However, that term also covers the columns for $ 2 $, $ 6 $, and $ 10 $; so they can be removed from the table. The Prime Implicant table is then simplified to \ref{ASM:tab:qm_ex_1_1st_iteration}.

\begin{table}[H]
	\sffamily
	\newcommand{\head}[1]{\textcolor{white}{\textbf{#1}}}
	\begin{center}
		\rowcolors{2}{gray!10}{white} % Color every other line a light gray
		\begin{adjustbox}{max width=\textwidth}
			\begin{tabular}{lccccccc}
				\rowcolor{black!75}
				& \head{0} & \head{1} & \head{5}
				& \head{7} & \head{9} & \head{11} & \\
				%                      0   1   5   7   9  11
				$ 000-\;(0,1) $       & X & X &   &   &   &   & $ A'B'C' $ \\
				$ 00-0\;(0,2) $       & X &   &   &   &   &   & $ A'B'D' $ \\
				$ 0-01\;(1,5) $       &   & X & X &   &   &   & $ A'C'D $ \\
				$ -001\;(1,9) $       &   & X &   &   & X &   & $ B'C'D $ \\
				$ 01-1\;(5,7) $       &   &   & X & X &   &   & $ A'BD $ \\
				$ 011-\;(6,7) $       &   &   &   & X &   &   & $ A'BC $ \\
				$ 10-1\;(9,11) $      &   &   &   &   & X & X & $ AB'D $ \\
				$ 101-\;(10,11) $     &   &   &   &   &   & X & $ AB'C $ \\
				\hline
			\end{tabular}
		\end{adjustbox}
	\end{center}
	\caption{Quine-McCluskey Ex 1: 1st Iteration}
  \label{ASM:tab:qm_ex_1_1st_iteration}
\end{table}

The various rows can now be combined in any order the designer desires. For example, if row $ 10-1 (9,11) $, is selected as a required implicant in the solution, then minterms $ 9 $ and $ 11 $ are accounted for in the final equation, which means that all \emph{X} marked in those columns can be removed. When that is done, then, rows $ 101- (10,11) $ and $ 10-1 (9,11) $ no longer have any marks in the table, and they can be removed. Table \ref{ASM:tab:qm_ex_1_2nd_iteration} shows the last iteration of this solution.

\begin{table}[H]
	\sffamily
	\newcommand{\head}[1]{\textcolor{white}{\textbf{#1}}}
	\begin{center}
		\rowcolors{2}{gray!10}{white} % Color every other line a light gray
		\begin{adjustbox}{max width=\textwidth}
			\begin{tabular}{lccccccc}
				\rowcolor{black!75}
				& \head{0} & \head{1} & \head{5}
				& \head{7} & \\
				%                      0   1   5   7
				$ 000-\;(0,1) $       & X & X &   &   & $ A'B'C' $ \\
				$ 00-0\;(0,2) $       & X &   &   &   & $ A'B'D' $ \\
				$ 0-01\;(1,5) $       &   & X & X &   & $ A'C'D $ \\
				$ -001\;(1,9) $       &   & X &   &   & $ B'C'D $ \\
				$ 01-1\;(5,7) $       &   &   & X & X & $ A'BD $ \\
				$ 011-\;(6,7) $       &   &   &   & X & $ A'BC $ \\
				\hline
			\end{tabular}
		\end{adjustbox}
	\end{center}
	\caption{Quine-McCluskey Ex 1: 2nd Iteration}
  \label{ASM:tab:qm_ex_1_2nd_iteration}
\end{table}

The designer next decided to select $ 01-1 (5,7) $, $ A'BD $, as a required implicant. That will include minterms $ 5 $ and $ 7 $, and those columns may be removed along with rows $ 01-1 (5,7) $, $ A'BD $, and $ 011- (6,7) $, $ A'BC $, as shown in Table \ref{ASM:tab:qm_ex_1_3rd_iteration}.

\begin{table}[H]
	\sffamily
	\newcommand{\head}[1]{\textcolor{white}{\textbf{#1}}}
	\begin{center}
		\rowcolors{2}{gray!10}{white} % Color every other line a light gray
		\begin{adjustbox}{max width=\textwidth}
			\begin{tabular}{lccccccc}
				\rowcolor{black!75}
				& \head{0} & \head{1} & \\
				%                       0   1
				$ 000-\;(0,1) $       & X & X & $ A'B'C' $ \\
				$ 00-0\;(0,2) $       & X &   & $ A'B'D' $ \\
				$ 0-01\;(1,5) $       &   & X & $ A'C'D $ \\
				$ -001\;(1,9) $       &   & X & $ B'C'D $ \\
				\hline
			\end{tabular}
		\end{adjustbox}
	\end{center}
	\caption{Quine-McCluskey Ex 1: 3rd Iteration}
  \label{ASM:tab:qm_ex_1_3rd_iteration}
\end{table}

The last two minterms ($ 0 $ and $ 1 $) can be covered by the implicant $ 000- (0,1) $, and that also eliminates the last three rows in the chart.

The original Boolean expression, then, has been simplified from ten minterms to Equation \ref{ASM:eq:qm_ex_1_solution}.

\begin{align}
	\label{ASM:eq:qm_ex_1_solution}
	A'B'C'+A'BD+AB'D+CD' = Y
\end{align}

\subsection{Example Two}
\label{ASM:subsec:quine-mccluskey_ex_2}

\subsubsection{Step 1: Create the Implicants}
\label{ASM:subsubsec:quine-mccluskey_ex_2_step_1}

Given Equation \ref{ASM:eq:qm_ex_2}, which is a Sigma representation of a Boolean equation.

\begin{align}
\label{ASM:eq:qm_ex_2}
\int(A,B,C,D,E,F)=\sum(0,1,8,9,12,13,14,15,32,33,37,39,48,56)
\end{align}

Truth Table \ref{ASM:tab:qm_ex_2_minterm_table} shows the \emph{True} minterm values.

\begin{table}[H]
	\sffamily
	\newcommand{\head}[1]{\textcolor{white}{\textbf{#1}}}
	\begin{center}
		\rowcolors{2}{gray!10}{white} % Color every other line a light gray
		\begin{tabular}{ccccccc}
			\rowcolor{black!75}
			\head{Minterm} & \head{A} & \head{B} & \head{C}
				& \head{D} & \head{E} & \head{F} \\
			0  & 0 & 0 & 0 & 0 & 0 & 0 \\
			1  & 0 & 0 & 0 & 0 & 0 & 1 \\
			8  & 0 & 0 & 1 & 0 & 0 & 0 \\
			9  & 0 & 0 & 1 & 0 & 0 & 1 \\
			12 & 0 & 0 & 1 & 1 & 0 & 0 \\
			13 & 0 & 0 & 1 & 1 & 0 & 1 \\
			14 & 0 & 0 & 1 & 1 & 1 & 0 \\
			15 & 0 & 0 & 1 & 1 & 1 & 1 \\
			32 & 1 & 0 & 0 & 0 & 0 & 0 \\
			33 & 1 & 0 & 0 & 0 & 0 & 1 \\
			37 & 1 & 0 & 0 & 1 & 0 & 1 \\
			39 & 1 & 0 & 0 & 1 & 1 & 1 \\
			48 & 1 & 1 & 0 & 0 & 0 & 0 \\
			56 & 1 & 1 & 1 & 0 & 0 & 0 \\
		\end{tabular}
	\end{center}
	\caption{Quine-McCluskey Ex 2: Minterm Table}
  \label{ASM:tab:qm_ex_2_minterm_table}
\end{table}

To simplify this equation, the minterms that evaluate to \emph{True} are placed in a minterm table so that they form sections that are easy to combine. Each section contains only the minterms that have the same number of ones. Thus, the first section contains all minterms with zero ones, the second section contains the minterms with one one, and so forth. Table \ref{ASM:tab:qm_ex_2_rearranged_table} shows the rearranged truth table.

\begin{table}[H]
	\sffamily
	\newcommand{\head}[1]{\textcolor{white}{\textbf{#1}}}
	\begin{center}
		% \rowcolors{2}{gray!10}{white} % Color every other line a light gray
		\begin{tabular}{ccc}
			\rowcolor{black!75}
			\head{Number of 1's} & \head{Minterm} & \head{Binary} \\
							 0 & 0  & 000000 \\
			\hline
			\multirow{3}{*}{1} & 1  & 000001 \\
                               & 8  & 001000 \\
                               & 32 & 100000 \\
 			\hline
			\multirow{4}{*}{2} & 9  & 001001 \\
                               & 12 & 001100 \\
							   & 33 & 100001 \\
							   & 48 & 110000 \\
			\hline
			\multirow{3}{*}{3} & 13 & 001101 \\
							   & 14 & 001110 \\
							   & 37 & 100101 \\
							   & 56 & 111000 \\
			\hline
			\multirow{2}{*}{4} & 15 & 001111 \\
							   & 39 & 100111 \\
			\hline
		\end{tabular}
	\end{center}
	\caption{Quine-McCluskey Ex 2: Rearranged Table}
  \label{ASM:tab:qm_ex_2_rearranged_table}
\end{table}

Start combining minterms with other minterms to create Size Two Implicants, as in Table \ref{ASM:tab:qm_ex_2_size_2_implicants}.

\begin{table}[H]
	\sffamily
	\newcommand{\head}[1]{\textcolor{white}{\textbf{#1}}}
	\begin{center}
		% \rowcolors{2}{gray!10}{white} % Color every other line a light gray
		\begin{tabular}{ccc|c}
			\rowcolor{black!75}
			\head{1's} & \head{Mntrm} & \head{Bin} & \head{Size 2} \\
							 0 & \sout{0} & 000000 & 00000- (0,1) \\
			\cline{1-3}
			\multirow{3}{*}{1} & \sout{1}  & 000001 & -000000 (0,32) \\
							   & \sout{8}  & 001000 & 00-000 (0,8) \\
							   & \sout{32} & 100000 & -00001 (1,33) \\
			\cline{1-3}
			\multirow{4}{*}{2} & \sout{9}  & 001001 & 00-001 (1,9) \\
							   & \sout{12} & 001100 & 10000- (32,33) \\
				  			   & \sout{33} & 100001 & 1-0000 (32,48) \\
							   & \sout{48} & 110000 & 00100- (8,9) \\
			\cline{1-3}
			\multirow{3}{*}{3} & \sout{13} & 001101 & 001-00 (8,12) \\
							   & \sout{14} & 001110 & 100-01 (33,37) \\
							   & \sout{37} & 100101 & 001-01 (9,13) \\
						       & \sout{56} & 111000 & 00110- (12,13) \\
			\cline{1-3}
			\multirow{2}{*}{4} & \sout{15} & 001111 & 0011-0 (12,14) \\
							   & \sout{39} & 100111 & 11-000 (48,56) \\
							   &    &        & 1001-1 (37,39) \\
							   &    &        & 0011-1 (13,15) \\
							   &    &        & 00111- (14,15) \\
			\hline
		\end{tabular}
	\end{center}
	\caption{Quine-McCluskey Ex 2: Size Two Implicants}
  \label{ASM:tab:qm_ex_2_size_2_implicants}
\end{table}

All of the Size Two Implicants can now be combined to form Size Four Implicants, as in Table \ref{ASM:tab:qm_ex_2_size_4_implicants}.

\begin{table}[H]
	\sffamily
	\newcommand{\head}[1]{\textcolor{white}{\textbf{#1}}}
	\begin{center}
		% \rowcolors{2}{gray!10}{white} % Color every other line a light gray
		\begin{tabular}{ccc|c|c}
			\rowcolor{black!75}
			\head{1's} & \head{Mntrm} & \head{Bin}
				& \head{Size 2} & \head{Size 4} \\
							  0 & \sout{0} & 000000 & \sout{00000- (0,1)}   & -0000- (0,1,32,33) \\
			\cline{1-3}
			\multirow{3}{*}{1} & \sout{1}  & 000001 & \sout{-000000 (0,32)} & 00-00- (0,1,8,9)\\
							   & \sout{8}  & 001000 & \sout{00-000 (0,8)}   & 001-0- (8,9,12,13)\\
						       & \sout{32} & 100000 & \sout{-00001 (1,33)}  & 0011-- (12,13,14,15)\\
			\cline{1-3}
			\multirow{4}{*}{2} & \sout{9}  & 001001 & \sout{00-001 (1,9)}   & \\
							   & \sout{12} & 001100 & \sout{10000- (32,33)} & \\
							   & \sout{33} & 100001 & 1-0000 (32,48)        & \\
							   & \sout{48} & 110000 & \sout{00100- (8,9)}   & \\
			\cline{1-3}
			\multirow{3}{*}{3} & \sout{13} & 001101 & \sout{001-00 (8,12)}  & \\
							   & \sout{14} & 001110 & 100-01 (33,37)        & \\
							   & \sout{37} & 100101 & \sout{001-01 (9,13)}  & \\
							   & \sout{56} & 111000 & \sout{00110- (12,13)} & \\
			\cline{1-3}
			\multirow{2}{*}{4} & \sout{15} & 001111 & \sout{0011-0 (12,14)} & \\
							   & \sout{39} & 100111 & 11-000 (48,56)        & \\
							   &    &        & 1001-1 (37,39) 		        & \\
							   &    &        & \sout{0011-1 (13,15)}	    & \\
							   &    &        & \sout{00111- (14,15)} 	    & \\
			\hline
		\end{tabular}
	\end{center}
	\caption{Quine-McCluskey Ex 2: Size 4 Implicants}
  \label{ASM:tab:qm_ex_2_size_4_implicants}
\end{table}

None of the terms can be combined any further. All of the minterms or implicants that are not struck through are \emph{Prime Implicants}. In the table above, for example, $ 1-0000 $ is a Prime Implicant. The Prime Implicants are next placed in a table and further processed.

\subsubsection{Step 2: The Prime Implicant Table}
\label{ASM:subsubsec:quine-mccluskey_ex_2_step_2}

A \emph{Prime Implicant Table} can now be constructed, as in Table \ref{ASM:tab:qm_ex_2_prime_implicants}. The prime implicants are listed down the left side of the table, the decimal equivalent of the minterms goes across the top, and the Boolean representation of the prime implicants is listed down the right side of the table.

\begin{table}[H]
	\sffamily
	\newcommand{\head}[1]{\textcolor{white}{\textbf{#1}}}
	\begin{center}
		\rowcolors{2}{gray!10}{white} % Color every other line a light gray
		\begin{adjustbox}{max width=\textwidth}
			\begin{tabular}{lccccccccccccccc}
				\rowcolor{black!75}
				& \head{0} & \head{1} & \head{8} & \head{9}
				& \head{12} & \head{13} & \head{14} & \head{15}
				& \head{32} & \head{33} & \head{37} & \head{39}
				& \head{48} & \head{56} & \\
				%      			            0   1   8   9  12  13  14  15  32  33  37  39  48  56
				$ 11-000\;(48,56) $       &   &   &   &   &   &   &   &   &   &   &   &   & X & X & $ ABD'D'F' $ \\
				$ 00-00-\;(0,1,8,9) $     & X & X & X & X &   &   &   &   &   &   &   &   &   &   & $ A'B'D'E' $ \\
				$ 1001-1\;(37,39) $       &   &   &   &   &   &   &   &   &   &   & X & X &   &   & $ AB'C'DF $ \\
				$ 1-0000\;(32,48) $       &   &   &   &   &   &   &   &   & X &   &   &   & X &   & $ AC'D'E'F' $ \\
				$ 0011--\;(12,13,14,15) $ &   &   &   &   & X & X & X & X &   &   &   &   &   &   & $ A'B'CD $ \\
				$ -0000-\;(0,1,32,33) $   & X & X &   &   &   &   &   &   & X & X &   &   &   &   & $ B'C'D'E' $ \\
				$ 001-0-\;(8,9,12,13) $   &   &   & X & X & X & X &   &   &   &   &   &   &   &   & $ A'B'CE' $ \\
				$ 100-01\;(33,37) $       &   &   &   &   &   &   &   &   &   & X & X &   &   &   & $ AB'C'E'F $ \\
				\hline
			\end{tabular}
		\end{adjustbox}
	\end{center}
	\caption{Quine-McCluskey Ex 2: Prime Implicants}
  \label{ASM:tab:qm_ex_2_prime_implicants}
\end{table}

In the above table, there are four columns that contain only one \emph{X}: $ 14 $, $ 15 $, $ 39 $, and $ 56 $. The rows that intersect the columns at that mark are \emph{Essential Prime Inplicants}, and their Boolean Expressions must appear in the final equation. Therefore, the final equation will contain, at a minimum: $ A'B'CD $ (row $ 5 $, covers minterms $ 14 $ and $ 15 $), $ AB'C'DF $ (row $ 3 $, covers minterm $ 39 $), and $ ABD'E'F' $ (row $ 1 $, covers minterm $ 56 $). Since those expressions are in the final equation, the rows that contain those expressions can be removed from the chart in order to make further analysis less confusing.

Also, because the rows with Essential Prime Implicants are contained in the final equation, other minterms marked by those rows are covered and need no further consideration. For example, minterm $ 48 $ is covered by row one (used for minterm $ 56 $), so column $ 48 $ can be removed from the table. In a similar fashion, columns $ 12 $, $ 13 $, and $ 37 $ are covered by other minterms, so they can be removed from the table. Table \ref{ASM:tab:qm_ex_2_1st_iteration} shows the next iteration of this process.

\begin{table}[H]
	\sffamily
	\newcommand{\head}[1]{\textcolor{white}{\textbf{#1}}}
	\begin{center}
		\rowcolors{2}{gray!10}{white} % Color every other line a light gray
		\begin{adjustbox}{max width=\textwidth}
			\begin{tabular}{lccccccc}
				\rowcolor{black!75}
				& \head{0} & \head{1} & \head{8} & \head{9}
				& \head{32} & \head{33} & \\
				%      			            0   1   8   9  32  33
				$ 00-00-\;(0,1,8,9) $     & X & X & X & X &   &   & $ A'B'D'E' $ \\
				$ 1-0000\;(32,48) $       &   &   &   &   & X &   & $ AC'D'E'F' $ \\
				$ -0000-\;(0,1,32,33) $   & X & X &   &   & X & X & $ B'C'D'E' $ \\
				$ 001-0-\;(8,9,12,13) $   &   &   & X & X &   &   & $ A'B'CE' $ \\
				$ 100-01\;(33,37) $       &   &   &   &   &   & X & $ AB'C'E'F $ \\
				\hline
			\end{tabular}
		\end{adjustbox}
	\end{center}
	\caption{Quine-McCluskey Ex 2: 1st Iteration}
  \label{ASM:tab:qm_ex_2_1st_iteration}
\end{table}

The circuit designer can select the next term to include in the final equation from any of the five rows still remaining in the chart; however, the first term ($ 00-00- $, or $ A'B'D'E' $) would eliminate four columns, so that would be a logical next choice. When that term is selected for the final equation, then row one, $ 00-00- $, can be removed from the chart; and columns $ 0 $, $ 1 $, $ 8 $, and $ 9 $ can be removed since those minterms are covered.

The minterms marked for row $ 001-0- (8,9,12,13) $ are also covered, so this row can be removed. Table \ref{ASM:tab:qm_ex_2_2nd_iteration} shows the next iteration.

\begin{table}[H]
	\sffamily
	\newcommand{\head}[1]{\textcolor{white}{\textbf{#1}}}
	\begin{center}
		\rowcolors{2}{gray!10}{white} % Color every other line a light gray
		\begin{adjustbox}{max width=\textwidth}
			\begin{tabular}{lccc}
				\rowcolor{black!75}
				& \head{32} & \head{33} & \\
				%      			           32  33
				$ 1-0000\;(32,48) $       & X &   & $ AC'D'E'F' $ \\
				$ -0000-\;(0,1,32,33) $   & X & X & $ B'C'D'E' $ \\
				$ 100-01\;(33,37) $       &   & X & $ AB'C'E'F $ \\
				\hline
			\end{tabular}
		\end{adjustbox}
	\end{center}
	\caption{Quine-McCluskey Ex 2: 2nd Iteration}
  \label{ASM:tab:qm_ex_2_2nd_iteration}
\end{table}

For the next simplification, row $ -0000- $ is selected since that would also cover the minterms that are marked for all remaining rows. Thus, the expression $ B'C'D'E' $ will become part of the final equation.

When the analysis is completed, the original equation (\ref{ASM:eq:qm_ex_2}), which contained $ 14 $ minterms, is simplified into Equation \ref{ASM:eq:qm_ex_2_solution}, which contains only five terms.

\begin{align}
	\label{ASM:eq:qm_ex_2_solution}
	ABD'E'F'+A'B'D'E'+AB'C'DF+A'B'CD+B'C'D'E' = Y
\end{align}

\subsection{Summary}
\label{ASM:subsec:quine-mccluskey_summary}

While the Quine–McCluskey method is useful for large Boolean expressions containing multiple inputs, it is also tedious and prone to error when done by hand. Also, there are some Boolean expressions (called ``Cyclic'' and ``Semi-Cyclic'' Primes) that do not reduce using this method. Finally, both Karnaugh maps and Quine-McCluskey methods become very complex when more than one output is required of a circuit. Fortunately, many automated tools are available to simplify Boolean expressions using advanced mathematical techniques.

\subsection{Practice Problems}
\label{ASM:subsec:quine-mccluskey_practice_problems}

The following problems are presented as practice for using the Quine-McClusky method to simplify a Boolean expression. Note: designers can select different Prime Implicants so the simplified expression could vary from what is presented below.

\subsection{Practice Problems}
\label{ASM:subsec:practice_problems_karnaugh_maps}

\begin{table}[H]
	\sffamily
	\begin{center}
		\begin{tabular}{c c p{6cm} }
			\multirow{2}{*}{\textbf{1}}
			& Expression & $ \int(A,B,C,D) = \sum(0,1,2,5,6,7,9,10,11,14) $ \\
			& \cellcolor{gray!10} Simplified
			& \cellcolor{gray!10} $ A'B'C'+A'BD+AB'D+CD' $ \\
			\hline
			\multirow{2}{*}{\textbf{2}}
			& Exression & $ \int(A,B,C,D) = \sum(0,1,2,3,6,7,8,9,14,15) $ \\
			& \cellcolor{gray!10} Simplified
			& \cellcolor{gray!10} $ A'C+BC+B'C' $ \\
			\hline
			\multirow{2}{*}{\textbf{3}}
			& Exression & $ \int(A,B,C,D) = \sum(1,5,7,8,9,10,11,13,15) $ \\
			& \cellcolor{gray!10} Simplified
			& \cellcolor{gray!10} $ C'D+AB'+BD $ \\
			\hline
			\multirow{2}{*}{\textbf{3}}
			& Exression & $ \int(A,B,C,D,E) = \sum(0,4,8,9,10,11,12,13,14,15,16,20,24,28) $ \\
			& \cellcolor{gray!10} Simplified
			& \cellcolor{gray!10} $ A'B+D'E' $ \\
		\end{tabular}
	\end{center}
	\caption{Quine-McCluskey Practice Problems}
  \label{ASM:tab:quine-mccluskey_practice_problems}
\end{table}

%***************************************************************************
% Section: Automated Tools
%***************************************************************************
\clearpage\section{Automated Tools}
\label{ASM:sec:automated_tools}

\subsection{Introduction}
\label{ASM:subsec:introduction_to_automated_tools}

There are numerous automated tools available to aid in simplifying complex Boolean equations. Many of the tools are quite expensive and intended for professionals working full time in large companies; but others are inexpensive, or even free of charge, and are more than adequate for student use. This topic introduces one such free tool: \ac{KARMA}.

\subsection{KARMA}
\label{ASM:subsec:karma}

\subsubsection{Introduction}
\label{ASM:subsubsec:introduction_to_karma}

\ac{KARMA} is a free Java-based tool designed to help simplify Boolean expressions. Both an online and downloaded version of \ac{KARMA} is available. The application can be found at: \url{http://goo.gl/8Lmx5v}. Note: The version of \ac{KARMA} used for this text is 3.62. A newer version may be available but the instructions presented here use only the base functions and will likely be applicable even in an updated version of the software.

\begin{figure}[H]
	\centering
	\includegraphics[width=\maxwidth{.95\linewidth}]{gfx/07_01}
	\caption{Karma Initial Screen}
	\label{fig:07_01}
\end{figure}

The right side of the screen contains a row of tools available in \ac{KARMA} and the main part of the screen is a canvas where most of the work is done. The following tools are available:

\begin{itemize}
	\item Logic2Logic. Converts between two different logical representations of data; for example, a Truth Table can be converted to Boolean expressions.
	\item Logic Equivalence. Compares two functions and determines if they are equivalent; for example, a truth table can be compared to a SOP expression to see if they are the same.
	\item Logic Probability. Calculates the probability of any one outcome for a given Boolean expression.
	\item Karnaugh Map. Analyzes a Karnaugh map and returns the Minimized Expression.
	\item KM Teaching Mode. Provides drill and practice with Karnaugh maps; for example, finding adjacent minterms on a 6-variable map.
	\item SOP and POS. Finds the SOP and POS expressions for a given function.
	\item Exclusive-OR. Uses XOR gates to simplify an expression.
	\item Multiplexer-Based. Realizes a function using multiplexers.
	\item Factorization. Factors Boolean expressions.
	\item About. Information about \ac{KARMA}.
\end{itemize}

For this lesson, only the Karnaugh Map analyzer will be used, and the initial screen for that function is below.

\begin{figure}[H]
	\centering
	\includegraphics[width=\maxwidth{.95\linewidth}]{gfx/07_02}
	\caption{Karma K-Map Analyzer}
	\label{fig:07_02}
\end{figure}

\subsubsection{Data Entry}
\label{ASM:subsubsec:karma_data_entry}

When using \ac{KARMA}, the first step is to input some sort of information about the circuit to be analyzed. That information can be entered in several different formats, but a truth table or a Boolean expression would best match this book.

To enter the initial data, click the \emph{Load Function} button at the top of the canvas.

By default, the Load Function screen opens with a blank screen. In the lower left corner of the Load Function window, the Source Format for the input data can be selected. There is a template available for each of the different source formats; and that template can be used to help with data entry. The best way to work with \ac{KARMA} is to click the ``Templates'' button and then select the data format of interest. Figure \ref{ASM:fig:karma_expression_one_loaded} shows the ``Expression 1'' template.

\begin{figure}[H]
	\centering
	\includegraphics[width=\maxwidth{.95\linewidth}]{gfx/07_03}
	\caption{Karma Expression One Loaded}
	\label{fig:07_03}
\end{figure}

The designer would replace the ``inputs'' and ``onset'' lines with information for the circuit being simplified. Once the source data are entered into this window, click the \emph{Load} button at the bottom of the window to load the data into \ac{KARMA}.

\subsubsection{Data Source Formats}
\label{ASM:subsubsec:karma_data_source_formats}

\ac{KARMA} works with input data in any of six different formats: Boolean Expression, Truth Table, Integer, Minterms, \ac{BLIF}, and \ac{BDD}. \ac{BLIF} and \ac{BDD} are programming tools that are beyond the scope of this book and will not be covered.

%TODO: maybe expand the book to include BLIF and BDD.

\paragraph{Expression}
\label{ASM:para:karma_expression}

Boolean expressions can be defined in \ac{KARMA} using the following format.

{\small
	\begin{verbatim}
   #Sample Expression
   (!x1*!x2*!x4)+(!x1*x2*!x3)+(x1*!x4*!x5)+(x1*x3*x4)
	\end{verbatim}
}

Notes:

\begin{itemize}
	\item Any line that starts with a hash mark (``\#'') is a comment and will be ignored by \ac{KARMA}.
	\item ``Not'' is indicated by a leading exclamation mark. Thus $ !x1 $ is the same as $ X1' $.
	\item All operations are explicit. In real-number algebra the phrase ``AB'' is understood to be ``A*B.'' However, in \ac{KARMA}, since variable names can be more than one character long, all operations must be explicitly stated. \textsf{AND} is indicated by an asterisk and \textsf{OR} is indicated by a plus sign.
	\item No space is left between operations.
\end{itemize}

\paragraph{Truth Table}
\label{ASM:para:karma_truth_table}

A truth table can be defined in \ac{KARMA} using the following format.

\begin{verbatim}
     #Sample Truth Table
     inputs -> X, Y, Z
     000: 1
     001: 1
     010: 0
     011: 0
     100: 0
     101: 1
     110: 0
     111: 1
\end{verbatim}

Notes:

\begin{itemize}
	\item Any line that starts with a hash mark (``\#'') is a comment and will be ignored by \ac{KARMA}.
	\item The various inputs are named before they are used. In the example, there are three inputs: $ X $, $ Y $, and $ Z $.
	\item Each row in the truth table is shown, along with the output expected. So, in the example above, an input of $ 000 $ should yield an output of $ 1 $.
	\item An output of ``-'' is permitted and means ``don't care.''
\end{itemize}

\paragraph{Integer}
\label{ASM:para:karma_integer}

In \ac{KARMA}, an integer can be used to define the outputs of the truth table, so it is ``shorthand'' for an entire truth table input. Here is the example of the ``integer'' type input.

\begin{verbatim}
     #Sample Integer Input
     inputs -> A, B, C, D
     onset -> E81A base 16
\end{verbatim}

Notes:

\begin{itemize}
	\item Any line that starts with a hash mark (``\#'') is a comment and will be ignored by \ac{KARMA}.
	\item Input variables are defined first. In this example, there are four inputs: $ A $, $ B $, $ C $, and $ D $.
	\item The ``onset'' line indicates what combinations of inputs should yield a \emph{True} on a truth table. In the example, the number $ E81A $ is a hexadecimal number that is written like this in binary:
\end{itemize}

\begin{verbatim}
     1110 1000 0001 1010
      E    8    1    A
\end{verbatim}

The least significant bit of the binary number, $ 0 $ in this example, corresponds to the output of the first row in the truth table; thus, it is false. Each bit to the left of the least significant bit corresponds to the next row, counting from $ 0000 $ to $ 1111 $. Here is the truth table generated by the hexadecimal integer $ E81A $:

\begin{table}[H]
	\sffamily
	\newcommand{\head}[1]{\textcolor{white}{\textbf{#1}}}
	\begin{center}
		\rowcolors{2}{gray!10}{white} % Color every other line a light gray
		\begin{tabular}{ccccc}
			\rowcolor{black!75}
			\multicolumn{4}{c}{\head{Inputs}} & \head{Output} \\
			A & B & C & D & Y \\
			\hline
			0 & 0 & 0 & 0 & 0 \\
			0 & 0 & 0 & 1 & 1 \\
			0 & 0 & 1 & 0 & 0 \\
			0 & 0 & 1 & 1 & 1 \\
			0 & 1 & 0 & 0 & 1 \\
			0 & 1 & 0 & 1 & 0 \\
			0 & 1 & 1 & 0 & 0 \\
			0 & 1 & 1 & 1 & 0 \\
			1 & 0 & 0 & 0 & 0 \\
			1 & 0 & 0 & 1 & 0 \\
			1 & 0 & 1 & 0 & 0 \\
			1 & 0 & 1 & 1 & 1 \\
			1 & 1 & 0 & 0 & 0 \\
			1 & 1 & 0 & 1 & 1 \\
			1 & 1 & 1 & 0 & 1 \\
			1 & 1 & 1 & 1 & 1 \\
		\end{tabular}
	\end{center}
	\caption{Truth Table for KARMA}
  \label{03:tab:truth_table_for_karma}
\end{table}

The ``Output'' column contains the binary integer $ 1110\;1000\;0001\;1010 $ (or $ E81A_{16} $) from bottom to top.

\paragraph{Terms}
\label{ASM:para:karma_terms}

Data input can be defined by using the minterms for the Boolean expression. Following is an example minterm input.

\begin{verbatim}
     #Sample Minterms
     inputs -> A, B, C, D
     onset -> 0, 1, 2, 3, 5, 10
\end{verbatim}

\begin{itemize}
	\item Any line that starts with a hash mark (``\#'') is a comment and will be ignored by \ac{KARMA}.
	\item The inputs, $ A $, $ B $, $ C $, and $ D $, are defined first.
	\item The ``onset'' line indicates the minterm numbers that yield a \emph{True} output.
	\item This is similar to a \ac{SOP} expression, and the digits in that expression could be directly entered on the onset line. For example, the onset line above would have been generated from the Sigma expression in Equation \ref{ASM:eq:KARMA Input}.
\end{itemize}

\begin{align}
	\label{ASM:eq:KARMA Input}
	\int(A,B,C,D) &= \sum(0,1,2,3,5,10)
\end{align}

\subsubsection{Truth Table and K-Map Input}
\label{ASM:subsubsec:karma_truth_table_and_kmap_input}

While \ac{KARMA} will accept a number of different input methods, as described above, one of the easiest to use is the Truth Table, and the related Karnaugh Map, and these are displayed by default when the Karnaugh Map function is selected. The value of any of the cells in the \emph{Out} column in the Truth Table, or cells in the Karnaugh Map, can be cycled through $ 0 $, $ 1 $, and ``don't care'' (indicated by a dash) on each click of the mouse in the cell. The Truth Table and Karnaugh Map are synchronized as cells are clicked. The number of input variables can be adjusted by changing the \emph{Var} setting at the top of the screen. Also, the placement of those variables on the Karnaugh Map can be adjusted as desired.

\subsubsection{Solution}
\label{ASM:subsubsec:karma_truth_table_and_kmap_input}

\begin{figure}[H]
	\centering
	\includegraphics[width=\maxwidth{.95\linewidth}]{gfx/07_04}
	\caption{Karma Solution}
	\label{fig:07_04}
\end{figure}

To simplify the Karnaugh Map, click the \emph{Minimize} button. A number of windows will pop up (illustrated in Figure \ref{ASM:fig:karma_solution}), each showing the circuit simplification in a slightly different way. Note: the following Boolean expression was entered to generate the illustrated simplification: $ A'C + A'B + AB'C' + B'C'D' $.

\begin{figure}[H]
	\centering
	\includegraphics[width=\maxwidth{.95\linewidth}]{gfx/07_05}
	\caption{Karma Minimized Solution}
	\label{fig:07_05}
\end{figure}

\marginpar{KARMA includes parenthesis for clarity, but the groups are obvious when the expression is written in normal Boolean form.}

In this solution, a \emph{NOT} term is identified by a leading exclamation point; thus, the minimized expression is: $ A'D' + A'B + AB'C' + A'C $.

\paragraph{BDDeiro}
\label{ASM:para:karma_bddeiro}

The BDDeiro window is a visualization of a \ac{BDD}, which graphically represents the solution to a logic network.

\begin{figure}[H]
	\centering
	\includegraphics[width=\maxwidth{.95\linewidth}]{gfx/07_06}
	\caption{Karma BDDeiro Map}
	\label{fig:07_06}
\end{figure}

In a \ac{BDD}, each circle represents an input and the squares at the bottom of the diagram represent the two possible outputs: \emph{False} and \emph{True}. The lines are paths from the inputs to either a \emph{False} or \emph{True} output; thus, a truth table can be viewed graphically. A \ac{BDD} is useful because it provides a compact, visual representation of a Boolean expression, and for any given Boolean expression there is one, and only one, \ac{BDD} representing it. One disadvantage to using a \ac{BDD} is its size, there are potentially two nodes for each input (except the first), and that can lead to a very large diagram.

Figure \ref{ASM:fig:karma_bddeiro_map} is actually a ``Reduced Order'' \ac{BDD} and a number of nodes and paths have been consolidated to make the diagram as simple as possible. The top node represents the start of the decision diagram: input $ a $. If that input is \emph{False}, then follow the dotted line down to node $ d $. (Note: the lines are color-coded to aid in their use; \emph{False} lines are blue and \emph{True} lines are red.) If node $ d $ is false, then that leads directly to output \emph{True}. Thus $ A'D' $ gives a \emph{True} output, and that is one of the minimized solutions. To follow one other path, if $ a $ is \emph{True} (follow the solid line down and right), $ b $ is \emph{False}, $ c $ is \emph{False}, the output is \emph{True}. Thus, $ AB'C' $ is \emph{True}. In a similar way, all four \emph{True} outputs, and three false outputs, can be traced from the top to bottom of the diagram.

\paragraph{Quine-McCluskey}
\label{ASM:para:quine-mccluskey}

\ac{KARMA} includes the complete Quine-McCluskey solution data. Several tables display the various Implicants and show how they are derived.

\begin{figure}[H]
	\centering
	\includegraphics[width=\maxwidth{.95\linewidth}]{gfx/07_07}
	\caption{Karma Quine-McCluskey Solution}
	\label{fig:07_07}
\end{figure}

\ac{KARMA} also displays the Covering Table for a Quine-McCluskey solution.

\begin{figure}[H]
	\centering
	\includegraphics[width=\maxwidth{.95\linewidth}]{gfx/07_08}
	\caption{Karma Quine-McCluskey Covering Table}
	\label{fig:07_08}
\end{figure}

Each of the minterms (down the left column) can be turned on or off by clicking on it. The smaller blue dots in the table indicate prime implicants and the larger red dots (if any) indicate essential prime implicants. Because this table is interactive, various different solutions can be attempted by clicking some of the colored dots to achieve the best possible simplification.

\subsubsection{Practice Problems}
\label{ASM:subsubsec:karma_practice_problems}

The following problems are presented as practice for using \ac{KARMA} to simplify a Boolean expression. Note: designers can select different Prime Implicants so the simplified expression could vary from what is presented below.

\begin{table}[H]
	\sffamily
	\begin{center}
		\begin{tabular}{c c p{6cm} }
			\multirow{2}{*}{\textbf{1}}
			& Expression & $ \int(A,B,C,D) = \sum(5,6,7,9,10,11,13,14) $ \\
			& \cellcolor{gray!10} Simplified
			& \cellcolor{gray!10} $ BC'D+A'BC+ACD'+AB'D $ \\
			\hline
			\multirow{2}{*}{\textbf{2}}
			& Exression & $ A'BC'D+A'BCD'+A'BCD+AB'C'D+AB'CD'+AB'CD+ABC'D+ABCD' $ \\
			& \cellcolor{gray!10} Simplified
			& \cellcolor{gray!10} $ BC'D+A'BC+ACD'+AB'D $ \\
			\hline
			\multirow{2}{*}{\textbf{3}}
			& Exression & A 4-variable Karnaugh Map where cells 5, 6, 7, 9, and 10 are True and 13, 14 are ``Don't Care'' \\
			& \cellcolor{gray!10} Simplified
			& \cellcolor{gray!10} $ BC'D+AC'D+A'BC+ACD' $ \\
			\hline
			\multirow{2}{*}{\textbf{3}}
			& Exression & $ \int(A,B,C,D,E) = \sum(0, 3, 4, 12, 13, 14, 15, 24, 25, 28, 29, 30) $ \\
			& \cellcolor{gray!10} Simplified
			& \cellcolor{gray!10} $ ABD'+A'B'C'DE+BCD'+A'BC+A'B'D'E' $ \\
		\end{tabular}
	\end{center}
	\caption{KARMA Practice Problems}
  \label{ASM:tab:karma_practice_problems}
\end{table}