# 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)
$**

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Sponsored by Red Hat

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Sponsored by ActiveState

Image Manipulation with ImageMagick | Apr 17, 2014 |

Non-Linux FOSS: Angry IP | Apr 16, 2014 |

Encrypting Your Cat Photos | Apr 15, 2014 |

Numerical Python | Apr 11, 2014 |

Speed Test for Nerds | Apr 10, 2014 |

DNSSEC Part II: the Implementation | Apr 08, 2014 |

- You have to be careful there

7 weeks 3 days ago - Wonder when LJ is going to

7 weeks 4 days ago - Puerto Rico Free Software

7 weeks 5 days ago - Wepaa!!

7 weeks 6 days ago - I hate voice commands

7 weeks 6 days ago - usabilty --- AGAIN with this nonsense

8 weeks 58 min ago - Don't make excuses

8 weeks 4 hours ago - Sorry to let you know, but

8 weeks 5 hours ago - Ridiculous statement. Not a

8 weeks 1 day ago - Dragon

8 weeks 1 day ago

## Win a Tegra Note 7!

We're giving away one of these super cool NVIDIA Tegra Note 7 tablets in April, courtesy of Microway.

Come back every day and enter to increase your chances of winning.

## Poll

## Featured Jobs

Linux Systems Administrator | Houston and Austin, Texas | Host Gator |

Senior Perl Developer | Austin, Texas | Host Gator |

Technical Support Rep | Houston and Austin, Texas | Host Gator |

UX Designer | Austin, Texas | Host Gator |

Web & UI Developer (JavaScript & j Query) | Austin, Texas | Host Gator |

## Comments

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

The author seemingly does not have worked extensively with calc. calc-2.02f does not work too well with Emacs-21. There are a lot of problems with symbolic simplifications, and some quirks with regard to input, scrolling and display.

For that reason, Emacs-21 users should, if at all, get calc directly from the Emacs CVS archive at Savannah.gnu.org where it is maintained as part of the next new-feature release of Emacs (probably 21.4). That version works quite better.

It is a pity that calc's author Dave Gillespie has stopped working on calc while still having a significantly faster (calc-2 does not even use Emacs' floating point variables!) and more extensive version of calc up his sleeves and already in use privately. If anybody manages to wheedle out those floppy disks or whatever else he has been storing this work on...

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

You're correct, in that at the time I wrote the article I was quite inexperienced with Calc. Yes, I had noticed some problems on the symbolic side when using 2.02f with Emacs-21 (my setup). I thought it might be me, but you have confirmed the existence of a general problem. Thanks! And I also thank you for the pointer to the CVS version--and for the intelligence about Dave Gillespie's newer version. I, too, hope he takes steps to release it to the public.

But my article's emphasis was mostly on straight-ahead numerical evaluation, as that accounts for 95% or more of my typical usage. My setup works quite well for that, and I would advise anybody whose patterns of usage resembles mine not to be put off too much by the issues you quite correctly raise in your letter.

Thanks for the comments.

Charles Hethcoat, author.

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

The auther writes:

"The only problem I had with it as a publication tool is that your input file requires #-style comment lines for documentation,

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

Hi, everyone. I didn't realize until today that my article was already on-line! I appreciate the nice feedback.

Concerning the syntax of Calc: I repeat, I'm still fairly new to it, but my reading of the manual leads me to believe that it's probably configurable within elisp, but I haven't tried to figure out how. For my purposes, the `=>' is fine. In any event, you certainly can post-process these marks to taste within or without Emacs.

The only thing to keep in mind is whether you may need to re-process the file with Calc later on. (Remember my discussion of design changes?) You don't want to leave your master file damaged with respect to Calc's ability to read and process the formulas.

So if you create a filter to fix up the syntax, try to create the corresponding "unfilter" as well. Better still, create a processing pipeline to first /copy/ your file to another name and work on that one. Now your original remains untouched. When the need arises to update your original, just rerun your pipeline.

Charles Hethcoat

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

You're right, Emacs certainly can auto-convert those comments. One would need to use something like:

M-x replace-regexp ^# RET RET

to remove all #s at the starts of words, and then

M-x replace-regexp ^[^$] RET # SPACE RET

to put them back again. (This assumes all lines start either with a Calc $ or a comment #, which may be incorrect - I haven't used Calc myself.)

But the author was referring to Octave, not to Emacs+Calc. He wrote:

"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."

So the fact that it needs processing that could be easily done in Emacs may be precisely his point...

## calc math syntax constraint

Thanks a lot. Very interesting article.

One question. Is there a way to get free of the calc package syntax constraint? I mean that in my report, i want to use the '=' caracter for assignments as well as for 'evaluates to' operations. For example, I want to see things like:

c = sqrt( a^2 + b^2 ) = 5.14003891036

and NOT:

c := sqrt(a^2 + b^2) => 5.14003891036

Is it possible, or are we stuck with one and only one syntax?

## Re: calc math syntax constraint

Ok, done a bit of reading and the following should work

M-x replace-regexp RET:=|=>RET=RET

Do what you need to do to print the file then Ctrl-_ will set things back to how they were .

Hope that's of help

Euan

## Re: calc math syntax constraint

BAH! Bloody stripped the backslash!

M-x replace-regexp RET :=BACKSLASH|=>RET=RET

## Re: calc math syntax constraint

One possible solution is to run a regex-replace on the document prior to printing. I'm fairly new to Emacs so not too sure of the syntax for regex. In Vi it would look something like this:

1,$ s/=>|:=/=/g

Which tranlates to search the whole file for => or := and replace with =.

Once you've published it you can then hit Ctrl_ to undo the regex.

If anyone's read this and knows how to do it in Emacs regex then please post :-)

## Re: calc math syntax constraint

oops, regex missing a backslash. Should read:

1,$ s/=>|:=/=/g

Sorry,

Euan

## Re: calc math syntax constraint

OK, for reasons unknown the backlsash gets stripped when I post. Here we go once more:

1,$ s/=>BACKSLASH|:=/=/g

>sigh<

## Re: calc math syntax constraint

Not that i know of... This syntax is used as a programming language one, rather than a symbolic one. And, as such, it has been elaborated since the early days of Pascal...