Date: Jun 3, 2013 3:26 AM
Author: Joseph Gwinn
Subject: Re: Applying Mathematica to practical problems
In article <email@example.com>, Mark McClure
> On Sat, Jun 1, 2013 at 6:27 AM, Richard Fateman <firstname.lastname@example.org>
> > On 5/31/2013 12:16 AM, Andrzej Kozlowski wrote:
> >> Naive users of Mathematica practically never use arbitrary
> >> precision arithmetic.
> > Practically never, but occasionally? Like slightly pregnant?
> While I'd prefer to steer clear of the majority of this morass, I do
> have one data point that might be useful. In fact, I wrote the
> following on sci.math.symbolic back in 2008:
> >>>> I've been teaching undergraduate students to solve numerical
> >>>> problems in calculus, differential equations, linear algebra, and
> >>>> more recently numerical analysis using Mathematica since version
> >>>> 1.2 and I don't believe I've ever seen the types of problems you
> >>>> describe arise in that setting.
> Well, that was five years ago and, as I've continued to teach with
> Mathematica and even developed a course *on* Mathematica, I can now
> expand on that a bit. I have now seen a novice user develope some
> serious confusion due to unexpected behavior surrounding significance
> arithmetic - once.
> Incidentally, the significance arithmetic was triggered, not by one of
> RJF's standard tricks, but by a simple bug. In versions 6 and 7 of
> Mathematica, entering AiryA[0.0] yielded a non-machine number with
> Precision $MachinePrecision, rather than a machine number with
> Precsion MachinePrecision. I was studying the structure of Julia sets
> of Airy functions with an undergraduate research student and, as you
> might imagine, it was, uhmm, inconvenient to iterate with
> high-precision numbers. Danny can verify the bug at least, as he
> fixed it.
I have to chime in here, with a story that well predates Mathematica:
In my first job, circa 1970, I learned Fortran, and was writing a
program to convert a tape written on a 16-bit machine to the 36-bit
format of the Univac 1108 mainframe. I had endless trouble with the
Univac Field() function, which allowed access to defined subfields of a
36-bit word, the the bit level. Field() could appear on either side of
the equals sign, and so was perfect for reformatting tape data. I
struggled for a week, then asked my boss, who laughed and said that the
Field function was known not to work. Oh.
I subsequently took a course on 1108 assembler language, and when I
returned the first program I wrote was an assembly-coded fortran
function that did the needed bit twiddling, the twiddling that Field()
The point being that any large software entity will have errors, and
yet life goes on.