Interval vs default, was Re: Mathematica numerics and... Re: Applying
- To: mathgroup at smc.vnet.net
- Subject: [mg130999] Interval vs default, was Re: Mathematica numerics and... Re: Applying
- From: Richard Fateman <fateman at cs.berkeley.edu>
- Date: Sun, 2 Jun 2013 00:29:33 -0400 (EDT)
- Delivered-to: l-mathgroup@mail-archive0.wolfram.com
- Delivered-to: l-mathgroup@wolfram.com
- Delivered-to: mathgroup-outx@smc.vnet.net
- Delivered-to: mathgroup-newsendx@smc.vnet.net
- References: <kmngb2$3rv$1@smc.vnet.net> <20130519095011.606CD6A14@smc.vnet.net> <koch34$t5h$1@smc.vnet.net>
On 6/1/2013 3:06 AM, Daniel Lichtblau wrote:
> Others have commented on most issues raised in this subthread. I
> wanted to
> touch on just a few details.
>
> On May 31, 2:15 am, Richard Fateman <fate... at cs.berkeley.edu> wrote:
>> On 5/30/2013 3:09 AM, John Doty wrote:
>>
>>> Changing the topic here.
>>
>>> On Tuesday, May 28, 2013 1:49:00 AM UTC-6, Richard Fateman wrote:
>>
>>>> Learning Mathematica (only) exposes a student to a singularly
>>>> erroneous model of computation,
>
> I assume you (as ever) refer to significance arithmetic.
Yes.
If so,
> while it is many things, "erroneous" is not one of them. It
> operates as designed. You have expressed a couple of reasons
> why you find that design not to your liking. The two that most
> come to mind: bad behavior in iterations that "should" converge,
> and fuzzy equality that you find to be unintuitive 9mostly this
> arises at low precision).
Yes. I consider these to be errors in the design. I am not
complaining that the implementation (erroneously) diverges from
the design.
>
>
>>> A personal, subjective judgement. However, I would agree that
>>> exposing the student to *any* single model of computation, to the
>>> exclusion of others, is destructive.
>>
>> Still, there are ones that are well-recognized as standard, a common
>> basis for software libraries, shared development environments, etc.
>> Others have been found lacking by refereed published articles
>> and have failed to gain adherents outside the originators. (Distrust
>> of significance arithmetic ala Mathematica is not a personal
>> subjective opinion only.).
>
> No, but nor is it one that appears to be widely shared. As best I can
> tell, most people in the field either do not write about it, or else
> make the observation, correctly, that it is simply a first-order
> approximation to interval arithmetic.
There is a wikipedia entry on the topic that (at least as of this time
and date) is pretty good.
>
> As such, it has most of the qualities of interval arithmetic. Among
> these are the issue that results with "large" intervals are sometimes
> not very useful. Knowing that one ended up with a large interval,
> however,
> can be useful: it tells one that either the problem is not well
> conditioned, or the method of solving it was not (and specifically, it
> may have been a bad idea to use intervals to assess error bounds).
The important quality of interval arithmetic that is not preserved is
that interval arithmetic (done correctly) preserves validity. That is,
the correct answer is guaranteed to be enclosed in the result.
>
> Significance arithmetic brings a few advantages. One is that computations
> are generally faster than their interval counterparts.
I wonder about this. There are libraries that do interval arithmetic,
and even interval arithmetic in arbitrary precision. It might be
possible to benchmark interval arithmetic against Mathematica arithmetic
in some neutral setting. (I think it would be difficult to
compare the two fairly in Mathematica ... there might be an issue if
an interval's endpoints were computed with significance arithmetic so it
would naturally be slower.... But perhaps there is another way. See
below, though.)
It seems to me that the default arithmetic is fairly complicated. Each
extended float number F has some other number E associated with it
(guess: it is a machine float representing something like log of
relative error), and calculations require mucking about with F and E
both, e.g. some calculations involving condition numbers relating to how
fast a function changes as the argument changes.
> Another is that it
> is "significantly" easier to extend to functions for which interval
> methods are out of reach (reason: one can compute derivatives but cannot
> always find extrema for every function on every segment). A third is that
> it is much easier to extend to complex values.
I don't understand the derivative argument -- intervals can be computed
essentially by composition of interval functions. This may be overly
pessimistic compared to actually finding extrema, but it is, so far
as I know, fairly easy. The extension of intervals to complex values
is another issue, but I don't know that significance arithmetic really
does better. My understanding is that complex numbers as intervals
can be done by enclosures that are 2-D in the complex plane (e.g.
circles, rectangles, or some other shapes) or a design in which the
real and imaginary parts are expressed as separate intervals. I expect
that the Mathematica significance version is more like the latter, in
which case it shouldn't make much difference in ease of implementation.
Is there a place where this distinction is explained? Besides which,
if Mathematica allows Interval[{}] data, don't you have to write the
program, anyway?
>
> A drawback, relative to interval arithmetic, is that as a first-order
> approximation, in terms of error propagation, significance arithmetic
> breaks down at low precision where higher-order terms can cause the
> estimates to be off. I will add that, at that point, intervals are going
> to give results that are also not terribly useful.
An advocate of interval arithmetic (and at least for the moment I will
take this position :) ) would say that interval arithmetic guarantees
a valid answer. That is, the answer is inside the interval. Sometimes
the interval may be very wide, even infinitely wide. But it contains
the answer. Not so for significance arithmetic. While it may be
appropriately modest for the documentation for N[] to say that
N[expr,n] >>>attempts<<< to give a result ... This is not really
what interval arithmetic does. It guarantees...
>
> I'm not sure what are the refereed articles referred to above. I suspect
> they do not disagree in substantial ways with what I wrote though. That
> is to say, error estimates may be too conservative, and at low precision
> results may not be useful.
There are a few references in the Wikipedia article. There are a few
rants that you can find via Google. I think the interaction of
significance arithmetic and testing for equality / comparison in
Mathematica is potentially hazardous, in large part because it can do
bad things quite invisible to the user. I do not know of a simple
consistent way of fixing this. While I haven't thought about this in a
while, the last time I did, I found it necessary to keep backing out of
pieces of the Mathematica arithmetic design quite far. (like a
retrenchment of significance arithmetic!)
>
> Fixed precision has its own advantages and disadvantages in terms of speed,
> error estimation, and the like. We certainly use it in places, even if
> significance arithmetic is the default behavior of bignum arithmetic in
> top-level Mathematic. For implementation purposes we use both modes.
Yes.
>
>
>>> Mathematica applied to real problems is pretty good here.
>>
>> Maybe, but is "pretty good" the goal, and the occasional identified
>> errors be ignored?
>
> We do try to fix many bugs that are brought to our attention. We have a
> better track record in some areas than others. I have no reason to
> believe that numerics issues have received short shrift though.
I appreciate that you try to fix errors. I appreciate that you engage
in such discussions!
>
>
...
RJF
appendix, timing.
Timing[(z = 1.11111111111111111; Do [z = 2*z - z, {3600}]; z)]
takes 0.0156 seconds. It gives the answer 0 * 10^1700,
Timing[(z = 1.111111111111; Do [z = 2*z - z, {3600}]; z)]
takesl 0.0156 seconds. It gives the right answer, 1.11111..
Timing[(z = Interval[1]; Do [z = 2*z - z, {3600}]; z)]
takes 0.0625 seconds. It gives the correct answer, Interval[{1,1}].
Slower by a factor of 4. If intervals were economically
represented and efficiently manipulated, I expect that one could
get a factor of 4 back.