Re: Comments on P1788_Level2RoughDraft.pdf
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. 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. Unfortunately I see no good solution for large midpoints,
other than Entire (radius=+Inf). 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 (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.
>> 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. What I'm talking about is
what the rad() function should return for semi-unbounded intervals and
for Empty -- irrespective of encoding. 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. Then
a radius of +Inf can unambiguously denote Entire.
Michel.
---Sent: 2012-01-18 19:46:39 UTC