# Math-Intensive Reports with GNU Emacs and Calc, Part 2

In part 1 of this article, I explained some of the evolving and complicated requirements of math calculations in certain types of reporting. As part 1 outlined, Emacs and the Calc application offer many types of utility for the requirements of math-intensive report generation. Part 2 of this two-part series will delve a bit deeper into the mathematical operations you can do with Emacs, further demonstrating why this editor is so valuable.

Let's look at some vector calculations. Suppose we want to calculate the bending moment induced at a point in space by a force vector acting through another point. If, at the location given by the radius vector

**$ R := [3, -11, -29] $**

in a given coordinate system, a force

**$ F := [50, 60, -30] $**

is acting, then the moment M induced at the origin by F acting through R is

**$ M := cross(R, F) => [2070, -1360, 730]
$**

The dot product is denoted by

**$ R F => 360 $**

The unit vector triad typically is denoted in vector mechanics by (i, j, k), where i = [1, 0, 0] and so on. However, in Calc, i is predefined as the imaginary unit

**$ i => (0, 1) $**

such that

**$ i^2 => -1 $**

Therefore, to avoid any possible confusion, we will use I, J and K as the unit vectors. These variables are not predefined in Calc, but they are absurdly easy to define:

**$ I := [1, 0, 0] $**

**$ J := [0, 1, 0] $**

**$ K := [0, 0, 1] $**

We could then, for example, resolve the moment vector M, calculated in the preceding section, into components parallel to the I, J and K vectors. (When both arguments are three-vectors, multiplication produces the dot product.)

**$ M I => 2070 $**

**$ M J => -1360 $**

**$ M K => 730 $**

Check for yourself that the resultant of these three components equals the given value of M.

Matrix Operations

Calc also is good at matrix operations. Suppose A is a 4-by-4 matrix. Before starting, I am going to set some Calc modes explicitly:

% [calc-mode: matrix: scalar] % [calc-mode: matrix-brackets: (O C)]

In Calc, some minor annoyances exist when using matrices. To define A, I entered it in like this:

A := [1, 2, 3, 4; 6, 5, 4, 3; 7, 12, 3, 4; 5, 6, 3, 2]

This is a simple input format used by other software (Matlab and Octave, for instance). However, when I use the command M-# u to invoke the assignment operation, Calc reformats it like this:

$ [ 1, 2, 3, 4; A := 6, 5, 4, 3; 7, 12, 3, 4; 5, 6, 3, 2 ] $

Note that the A := part has been moved down a line. I wouldn't mind it doing this, except it seems that later re-evaluation of this assignment can hit a stumbling block when Calc re-reads what it rewrote (the second form). I suspect it's probably my own inexperience using Calc that causes this, but I digress. We have made the assignment; we can print it out like this:

$ [ 1, 2, 3, 4; A => 6, 5, 4, 3; 7, 12, 3, 4; 5, 6, 3, 2 ] $

Now, let B be a 4-by-1 vector. To enter it conveniently, we
can type it as a 1-by-4 but transpose it by giving it as an
argument to the **trn** (transpose)
command, like this:

$ [ 4 ; B := trn([4, 6, 9, -2]) => 6 ; 9 ; -2 ] $

Now, let C be the product A*B, a 4-by-1 vector:

$ [ 35 ; C := A B => 84 ; 119; 79 ] $

Thus, we can calculate the inverse of A. First, however, I will set the display precision to four digits so it will fit on the page better. Not to worry, the full internal precision always is carried in calculations.

**% [calc-mode: float-format: (float
4)]**

The function **inv** actually
calculates the inverse:

$ [ -0.2857, 0.7143, 0.1667, -0.8333; Ainv := inv(A) => 0.07143, -0.4286, 1.135e-14, 0.5 ; 0.2857, -0.7143, -0.5, 1.5 ; 0.07143, 0.5714, 0.3333, -1.167 ] $

We can verify that Ainv is indeed the inverse of A, for their product will equal the unit matrix:

$ [ 1.0000, 0., 0., -1e-11; A Ainv => 6e-12, 1.000, -1e-12, -1e-11; -4e-12, 1e-11, 1., -1e-11; 1e-12, 0., 1e-12, 1.0000 ] $

Well, it's pretty closely. The difference between this result and a perfect unit matrix is due to the roundoff error intrinsic to floating point machine arithmetic.

Complex Operations

Complex numbers can arise as the result of operations on real or integer numbers. For example, the imaginary unit is, in a simple way, defined as the square root of -1:

**$ sqrt(-1) => (0, 1) $**

Note, this is one way Calc can display i. It is in rectangular vector format, denoted as (realpart, imaginarypart). However, as I already mentioned, i also is a predefined variable in Calc, and it behaves as we might expect:

$ i => (0, 1) $ $ i i => -1 $

We may use preexisting real numbers to construct complex values, as in this example:

$ rp := 2.7 $ $ ip := -3.2 $

Both of these values are real, but we can construct a complex number out of them easily:

**$ c := rp + ip i => (2.7, -3.2)
$**

If we have complex values to work with, we can perform general complex mathematical evaluations. For example, let z be a complex number:

**$ z := (2, 3) $**

Let me push up a notch Calc's precision for displaying the result:

**% [calc-mode: float-format: (float
6)]**

Now, we may map the complex point z to the complex point w using a functional mapping:

**$ w := 1 / (1 - z^2) => (0.0333333, 0.0666667)
$**

Calc has the burden of recognizing the formulas you type into the editing buffer. It can recognize formulas in several formats. The simplest style is to put a formula by itself, preceded and followed by empty lines. This is the easiest to type but has the disadvantage that the layout may not be maintained. That is, if you choose to indent the formulas a bit (which makes them much easier to read, in my opinion), you will lose that indentation when you recalculate the report.

For general-purpose use, the style I prefer is to bracket each formula with a pair of dollar signs. Calc will find and (re)calculate such formulas but won't mess with your indentation. (This is the style I have used in this article.)

Calc also can recognize and generate markup with the TeX typesetting language. I use LaTeX, but I haven't used it extensively with Calc (yet), so my examples will be simple ones.

Calc can reformat its equations into a TeX markup style when you select a TeX display mode. For example, the Calc assignment

**x := 3.2**

is rendered in TeX mode as

**x \gets 3.2**

The TeX command \gets doesn't exist in native TeX. The intent is for you to define your own \gets command using a macro definition in your TeX document. It would look something like this:

**\def\gets\text-that-typesets-an-assignment-operator**

More complex math formulas will be rewritten in TeX mode using all the considerable number of TeX math operators. The math will come out gorgeous, as only TeX can make it.

Apparently, however, "some assembly is required" to work in this mode. I cannot say much more than this because I simply haven't much explored this aspect of Calc.

Of more interest to me, however, is that LaTeX environments are maintained within Calc. Consider the following markup for a simple LaTeX document. It repeats our first example:

\documentclass{article} \begin{document} Let's do a simple calculation of a right triangle. If the two short legs are denoted a and b, where (say) \begin{verbatim} a := 3.1 \end{verbatim} and \begin{verbatim} b := 4.1 \end{verbatim} then the length of the hypotenuse is \begin{verbatim} c := sqrt(a^2 + b^2) => 5.14003891036 \end{verbatim} I didn't have to get my calculator out to do this. I did it right inside Emacs. Furthermore, this file is live. \end{document}

In LaTeX, a verbatim environment is enclosed between the \begin{verbatim} and \end{verbatim} tags. When typeset, the text between the tags will be set in a constant-width Courier typeface---not too pretty, but serviceable. The important thing to understand is that LaTeX environments are recognized as math delimiters by Calc. This means that I can recalculate my LaTeX document as often as I need to and never (well, hardly ever) have to do any manual editing of the numerical results. It always is up to date and it always looks great.

Although this is not the place to explain it, Emacs also has a language mode for TeX and LaTeX editing. It's another elisp package called AucTeX. Try it, you'll love it; it also works with Calc.

Emacs benefits greatly from Calc, and your calculation reports will be executed faster and more accurately than you ever imagined they could be. The interaction between Calc and Emacs is almost as seamless (if I may be forgiven for using that awfully overused computer word) as it gets. Using Emacs with Calc is one of the most friction-free ways I have ever found to write engineering analysis reports and keep them current in the face of constantly ongoing design changes.

I know of no other free general-purpose text editor that can perform mathematical evaluation. Commercial packages are available, sure, but you have to pay plenty for them. Moreover, many products in the lower price ranges, such as Mathcad, are only available for Windows. The more expensive packages (Mathematica, Matlab) generally are available on both Windows and UNIX platforms but cost upwards of a thousand dollars. In contrast, Emacs and Calc are entirely free for the downloading.

What about other free software for doing calculations? I've had some experience with Octave, and I must say that I like it very much. Although it can be used interactively, it is not an editor like Emacs is, and in my opinion it is best for batch computation. After Emacs+Calc, it is the tool I would choose for computations that require an algorithmic approach (with lots of loops and logical testing of results). The only problem I had with it as a publication tool is that your input file requires #-style comment lines for documentation, á là C. To get its output in a form that is suitable for a report with interspersed commentary, you need to perform some downstream editing with tools like sed or awk. Not at all difficult on UNIX but not easy on Windows, and the additional processing requires more steps than the combination of Emacs+Calc. I prefer the latter, because I find it handles about eighty or ninety percent of my routine calculations.

A related category of free software is the literate programming approach ascribed to Professor Don Knuth. This originated as a way to embed sections of functioning code within a running commentary on its design. This procedure allows the code to be extracted from the report and rearranged as needed for compilation. I'm not expert in this area, but I am convinced that Octave, for one, would benefit a lot from being used in a literate manner from within the body of a report. Where the literate programming approach fails, for my purposes at least, is that it seems not to have been considered as a way to compute mathematical expressions and numbers for immediate insertions into the report itself.

One aspect of Calc that is difficult to simulate properly for
publication is its interactive behavior. In order to explain how to
use Calc interactively in the static medium of the printed page, I
had to resort in a couple of places to the trick of showing a line
twice. The first is what I typed in the editing buffer before
invoking Calc. The second is what I got back *on the same
line* after invoking Calc. Therefore, if I run Calc a
second time on the article file, it won't come out identical. This
isn't generally a problem when preparing a report, because one is
normally using Calc instead of trying to demonstrate it.

Emacs

General description: www.gnu.org/software/software.html

FTP mirror list & instructions for downloading: www.gnu.org/order/ftp.html

Emacs Wiki: www.emacswiki.org/cgi-bin/wiki.pl

NTEmacs

Download: ftp.gnu.org/gnu/windows/emacs

FAQ: www.cs.washington.edu/~voelker/ntemacs.html

Calc

Download: ftp.gnu.org/gnu/calc

Manual: www.cl.cam.ac.uk/texinfodoc/calc_toc.html

Cygwin Tools

Download: sources.redhat.com/cygwin

User's Guide: sources.redhat.com/cygwin/cygwin-ug-net/cygwin-ug-net.html

Emacs Lisp

The Emacs Lisp Archive: archive.cis.ohio-state.edu/pub/emacs-lisp

The Emacs Lisp List: thalamus.wustl.edu/wonglab/stephen/ell/ell.html

AucTeX

Download code and documentation: mirrors.sunsite.dk/auctex/www/auctex

Octave

Download code and documentation: www.octave.org

email: clhiii@attglobal.net