Re: Comments on P1788_Level2RoughDraft.pdf
On 2012-01-18 14:14:12 -0500, Michel Hack wrote:
> On Tue, 17 Jan 2012 16:03:51 +0100 Vincent Lef?vre wrote:
> > On 2012-01-04 15:03:35 -0500, Michel Hack wrote:
> >> 6.3.1 section on MidRad types. I often hear that the radius could be
> >> expressed in a different format than the midpoint, e.g. with
> >> less precision. This might be meaningful if it is RELATIVE,
> >> but is problematic if it is absolute, unless the exponent
> >> range for the midpoint format is artificially restricted to
> >> match that of the radius format.
> >
> > Why artificially?
>
> Because otherwise we get a very strange and non-uniform landscape of
> intervals: tiny islands around widely scattered large midpoints, and
> vastly overlapping nearly-undistinguishable blobs around zero.
I'm not advocating this choice done on purpose, but is this really
a problem in practice? (Note: for the *final* result, the user still
has the possibility to do some clean-up or convert it to inf-sup if
he doesn't like that.)
But you didn't answer my real question: why is this restriction
*artificial*?
> In my opinion a midrad format that uses binary64 for midpoint and
> binary32 for radius should flush tiny midpoints (magnitude smaller
> than Dmin32) to zero.
A better solution would be to see the radius as an error in ulp's
(or a relative error), in which case you would no longer want to
flush tiny midpoints.
FYI, this is what is done inside MPFR for some functions (though this
isn't really an interval arithmetic because this is a mix of static
error and dynamic error bound computation).
> Unfortunately I see no good solution for large midpoints, other than
> Entire (radius=+Inf).
Again, an error in ulp's (or a relative error) solves this problem.
> Well, I guess that is what would happen anyway as the radius is very
> likely to overflow, and the midpoint could survive as a useful
> debugging hint. This is why I mentioned a RELATIVE radius, and
> Vincent seems to agree, having offered some alternatives that are
> also relative.
>
> > At Level 4, the radius need not be represented by a floating-point
> > number. It could be represented by an (unsigned) integer, and the
> > scaling factor would depend on the midpoint, the type, and/or some
> > other parameter.
>
> Ok; I also agree with the comments about relative radius. Nevertheless,
> the mid() and rad() functions should return the appropriate floating-point
> type
But what I'm saying is that there isn't necessarily a natural
floating-point format associated with the interval type. The
FP format should be associated with the function itself (like
the interval type).
In particular, you may want to have mid() and rad() return results
in different formats.
> (as the functions should apply to all intervals), as discussed in my
> earlier posting today -- and the precision should reflect that of
> the midpoint, even if the actual representation uses mixed
> precisions or types.
For rad(), I don't see why it must have the same precision as the
midpoint.
Also, think about particular implementations, e.g. with rational
bounds (can Boost do this?). Another possibility is to use a midrad
representation with the double-double arithmetic ("long double" C
type on PowerPC under Mac OS X and GNU/Linux) for the midpoint and
the double arithmetic for the radius.
> >> My other concern is with the last sentence. I suppose it is
> >> possible (at Level 3) to encode Empty, Entire and semi-unbounded
^^^^^^
> >> intervals, e.g. by using selected negative values for the radius.
> >
> > That would be Level 4 (Level 3 is still quite abstract). And it
> > depends on whether the radius field can hold negative numbers.
>
> If a midrad type encodes semi-unbounded intervals with a defined finite
> endpoint, I don't care HOW it encodes this.
You were talking about the encoding above.
> What I'm talking about is what the rad() function should return for
> semi-unbounded intervals and for Empty -- irrespective of encoding.
This isn't specific to implicit interval types. You have the same
problem with inf-sup and this is a Level 1 problem (discussed in
another thread), not primarily a Level 2 problem (this thread).
> It should return a floating-point value of the appropriate precision
> (see my earlier post, on bisection), and since any legitimate radius
> is non-negative, we could standardize *by convention* certain small
> negative integers to denote cases that don't have a radius, but do
> have a well-defined numeric bound.
Or it could be undefined (at Level 1), which would mean NaN (at
Level 2).
> Then a radius of +Inf can unambiguously denote Entire.
Yes.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)