MathGroup Archive 2001

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Re: Zero does not Equal Zero is a feature

  • To: mathgroup at
  • Subject: [mg31541] Re: Re: Zero does not Equal Zero is a feature
  • From: Daniel Lichtblau <danl at>
  • Date: Fri, 9 Nov 2001 06:13:58 -0500 (EST)
  • Approved: Steven M. Christensen <>, Moderator
  • References: <9rdg39$7ob$> <> <> <>
  • Sender: owner-wri-mathgroup at

>Yep. J. Symbolic Computing vol 13, no 5, May 1992.  Also on line.

Computation. And I have a copy.

>Well I am not a historian of Mathematica, but I recall that
>there were substantial changes in Interval and/or RealInterval which
>I assumed required substantial redesign.  The meaning of
>N[expression,d] changed from "do the arithmetic using precision d"
>to "give me the answer accurate to d digits".  This is a major
>change in my view.

In mine as well, but if it happened it was more than 10 years ago.

Any change in RealInterval is a minor issue. I am certain of that
because I do not recall what RealInterval is/was in Mathematica.
Interval has
not changed in any substantial way in at least 7 years. It is possible
that Jerry keiper made changes not too long before that although to the
best of my recollection they were not large.

>The meaning of Accuracy and Precision seems to have been altered
>so that these became floating-point numbers.

I feel a bit like Mark Fuhrmann might have felt at the Simpson trial
when confronted with his past use of a particular epithet. Ya got me.
That change was indeed within the last 10 years. It was introduced in
version 2.1, about 9 years and 9 months ago.

Note that this was more to make the internals work than an issue in
design. Significance arithmetic does not work well if you cannot treat
these as lying in a continuum. My recollection is that Jerry claimed
this flaw was what led to that model being abandoned for a generation or

>Since actual numerical analysis texts do not use these words, but use
>relative and absolute error, it is in my view confusing to
>someone who is trained in numerical analysis.

Perhaps mildly so. According to Mark Sofroniou, "Higham's book states
that, usually but not universally, precision means number of digits and
accuracy usually mean the amount of computed error. Precision is the
scale of the relative error which is related to the number of digits.
Accuracy is the scale of the absolute error so it is related to the
computed error. Thus the terms used in Mathematica are not exactly the
same but they are not entirely unrelated."

Alot of detail about Mathematica's arithmetic may be found in:
(click on the "Numerics in Mathematica" item).


Keiper, J.B. 1994. New numerical features of Mathematica. Wolfram
Research Technical Report.

Also Mark Sofroniou is collaborating on an up-to-date article
discussing, among other things, the history of significance arithmetic
in Mathematica (as well as indicating some more general numeric
computation history). Though not about Mathematica per se, it will
elucidate in some detail the Mathematica implementation of significance
arithmetic. You may recall he sent you a draft perhaps two years ago.

>I think Max/Min precision were not in early Mathematicas;

I'm not certain. I think they were here when I arrived in '91.

>I also suspect that SetAccuracy and SetPrecision have changed but I
>don't recall how.

I will say that these are yet evolving. But they are not heavily used in
the way that N is.

>I think the intention of a floating-point design should be
>(a) minimum number of surprises
>(b) ease of modeling / understanding
>(c) clear definition
>(d) high accuracy, wide range
>(e) speed
>(f) control (e.g. of exceptions)
>(g) access to libraries
>.. at least off the top of my head.

First I'll point out that your set of desired attributes of a floating
point package, while nice, may not be entirely attainable in practice.
Some of the items will be at odds with others. That said, it is a
reasonable wish list.

>Mathematica's approach leads to
>(a) difficult to explain transition from machine to software

I think this one is not so hard except for issues wherein e.g. N[e,p]
works in machine hardware arithmetic for p<=16. This is something we are
addressing in our development kernel. I would not categorize this as a
major redesign (especially given that N[e] behavior remains unchanged),
I agree neither is it entirely minor. Other issues regarding the
hardware/software transition tend to be related to ability to represent
a result of intemediate step in hardware floats. These are not so hard
to fathom, and are almost certainly faced in similar ways by all
point implementations that offer arbitrary precision. They do not strike
me as being peculiar to Mathematica.

>(b) difficult to explain model of error transmission/control

It may be harder than fixed precision, because the latter really has no
such model. Specifically, in fixed precision this is entirely a function
of the algorithm, and error estimation is the job of the programmer.
As I recall significance arithmetic uses estimates of error bounds based
on derivatives.

>(c) difficult implications to programming language (e.g.
>what does == or === mean)

I'm gonna pass on this one.

>(d) duplication of interval computation as float computation

It is an approximation thereof, is MUCH faster in practice, and I
believe it is much easier to make work in the realm of complex numbers.

>(e) slow speed

Not entirely. It really depends on what you are doing. Linear algebra,
for example, generally reguires fast fixed precision BLAS. While this is
certainly an area in which we could improve, what we have now is not
bad. For many other purposes the speed of significance as opposed to
fixed precision arithmetic is not a serious issue.

An indication of hiw version 4 of Mathematica fares regarding bignum
arithmetic speed may be found at

>> We are of course in the business of extending useful capabilities of
>> Mathematica. Specific examples in response to the above would be of
>> interest for such work.

>Undoubtedly. They might also present a competitive advantage
>to WRI, compared to (say) Maple.
>I would hope that in such circumstances your company would
>be happy to pay for consultation on such matters. :)

Of course there is also the possibility of making such examples (which I
imagine would indicate weaknesses in many programs, not just
Mathematica) generally available rather than just to WRI.

Daniel Lichtblau
Wolfram Research
Opinions expressed herein are mine and not to be taken as those of my

  • Prev by Date: Re: Complex Number Simultaneous Equation 2 Unknowns
  • Next by Date: Re: Re: Zero does not Equal Zero is a feature
  • Previous by thread: Re: Re: Zero does not Equal Zero is a feature
  • Next by thread: Re: Re: Zero does not Equal Zero is a feature