In article <koehbr$2s6$1 at smc.vnet.net>, Mark McClure
<mcmcclur at unca.edu> wrote:
> On Sat, Jun 1, 2013 at 6:27 AM, Richard Fateman <fateman at cs.berkeley.edu>
> wrote:
> > 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()
couldn't do.
The point being that any large software entity will have errors, and
yet life goes on.
Joe Gwinn