Re: Comments on P1788_Level2RoughDraft.pdf
Here are my comments, and comments to Michel's comments.
In §6(b), I would say that the output could be numeric or text
(just like the input is numeric or text for (c)).
§6.2 is unclear about the signed zeros. If F has signed zeros, then
it is not a subset of R*.
On 2012-01-04 15:03:35 -0500, Michel Hack wrote:
> Very nice! (As requested I did not read 6.7 and beyond.)
>
> 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?
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.
For instance, the radius could be interpreted as a number of ulp's
(and the precision of the midpoint could automatically be reduced
so that the radius fits in a native integer).
> On the other hand, relative radius is problematical near a
> zero midpoint.
By convention, the implementation could define the ulp of 0 as being
the same as the ulp of the minimum positive floating-point number.
> 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.
Anyway, one isn't necessarily interested by semi-unbounded intervals.
If they are useful, a switch to inf-sup may be a better idea than
trying to handle them in mid-rad.
> 6.4.1 The "arbitrary set of reals s" as input to the hull(s) function is
> a concept only, not an actual function argument. For example, it
> is typically the range of a Level 1 function or operation. This
> should perhaps be made clearer.
Actually the hull is mainly used as a "helper function" (perhaps it
is better to call the non-helper function "union"). What I mean by
"helper function" is:
[LIA-2]
helper function: A function used solely to aid in the expression of
a requirement. Helper functions are not visible to the programmer,
and are not required to be part of an implementation. However, some
implementation defined helper functions are required to be
documented.
> 6.6.1 "Tightest" is unambiguous for any interval type only in its technical
> sense of the T-hull requirements for "implicit" types.
Yes.
> Typo in definition of widen(x): missing right square bracket
And concerning the description of "Tightest": "That is, equality
is to hold in (20)." -> This is not equality (a hull_T is missing).
Concerning the "Accurate" mode, I would replace
T-hull of Range(f | widen(x))
by
widen(T-hull of Range(f | widen(x)))
because the slope of an operation could be very low (e.g. the function
would be almost constant on widen(x)).
> Table 8: Please consult with Jean Michel Muller or his colleagues.
This will depend on Level 1, but it should be noted that IEEE 754
only recommends (correctly-rounded) elementary functions, so that
in practice, with some FP implementations, the "accurate" accuracy
mode could be provided only by re-implementing the elementary
functions for P1788!
> I was under the impression that exp/log were as difficult as
> sin/cos, at least when sin/cos arguments are within reasonable
> bounds.
Yes, the TMD can occur for exp/log. So, "tightest" should be
recommended but not required. Anyway I think that P1788 should not
go beyond the IEEE 754 requirements.
--
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)