Re: Comments on P1788_Level2RoughDraft.pdf
Subtopic: mid() and rad() functions for "implicit" interval types.
Vincent Lefèvre and I essentially agree: If a midrad implementation
uses different formats for encoding midpoint and radius, a relative
radius (with careful definition around zero) is a better choice than
an absolute radius. Also, the generic definition of the mid() and
rad() functions, as they apply to ALL interval types, should specify
the result type. It is in languages that support type overloading
where the issue could get murky, but that's probably beyond P1788.
An implementation that supports an implicit type with interesting
properties could have its own set of functions (not subject to 1788)
to exploit its features, e.g. exact midrat() and radrat() functions
for intervals with exact rational endpoints, using an appropriate
result type (e.g. a struct).
> But you didn't answer my real question: why is this restriction
> *artificial*?
I figured that if midpoint and (absolute, not relative) radius used
different precisions, the higher-precision type should be treated
as if it had the same exponent range as the lower-precision type.
I call that an "artificial" restriction because it is not natural.
Use of double+double for midpoint and plain double for radius does
not raise this issue because the exponent range is the same. This
would also be the case for S/360 HFP.
> > >> 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.
Different uses of "encode". The one at level 4 is the actual encoding.
What I was talking about later was essentially a level-2 way of returning
more information than simply NaN -- no applicable radius:
>> What I'm talking about is what the rad() function should return for
>> semi-unbounded intervals and for Empty -- irrespective of encoding.
Logically, rad() could return an ENUM to explain why there is no
applicable radius, or the radius (a nonnegative value) is there is one.
But those are two different types in most languages (the exception is
languages where everything is a string of characters, e.g. Rexx). I
was just pointing out that since a radius is non-negative, if it is
returned as a floating-point number, its interpretation can easily be
overloaded (without violating most languages' type) as I suggested.
> Or it could be undefined (at Level 1), which would mean NaN (at Level 2).
Right -- but we could also avoid a loss of information. It would be very
easy to write code such as: (in C)
r = rad(xx);
m = mid(xx);
if (r < 0) then switch (r) { /* Unusual case */
case -1: /* Handle empty */
case -2: /* Semi-bounded; m = upper endpoint */
case -3: /* Semi-bounded; m = lower endpoint */
}
There is a similar case in dealing with decomposition of floating-point
numbers in a manner that avoids NaN-caused exceptions: Extract Biased
Exponent, which returns a non-negative biased exponent, or conventional
values -1, -2 or -3 to denote Inf, QNaN and SNaN.
Michel.
---Sent: 2012-01-19 20:10:33 UTC