Re: As simple as it is now, I am still against motion 24.03...
On 2011-06-11 12:03:41 +0100, John Pryce wrote:
> That is, standardise a set of operations that have point input and
> interval output. Advantages:
> - The number of different operations is much reduced.
> - This is definitely within P1788's bailiwick, and doesn't trespass on 754's.
I don't think the number of operations is reduced (or what do you mean
by that?). Note that if x is a real, then [x,x] is a valid interval.
As [x,x] must be supported, then it also makes sense to support just x
as input. But you need to be very careful for the specification. For
instance, if not in tight mode, do you still require that f(x) and
f([x,x]) should return the same interval? (If yes, you need to say it.)
> I suggest that on 754-compliant systems the operations be
Why 754-compliant systems only?
> parameterised by the output interval format, like a 754 "formatOf"
> operation, and that interval format shall be of infsup type only. So
> one can input data of any FP format having the *same radix* as the
> output format.
I think that different input formats (whether in the same radix or
not) should be optional (and not forbidden). Perhaps recommended for
the same radix.
Also, if you accept different input floating-point formats, then it
should be the same for different input interval formats.
> (Recall this eliminates the "double rounding" problem, while being
> fairly easy to implement.)
Eliminating the "double rounding" problem is useful in floating point
(for some algorithms), but is it really useful for interval arithmetic?
It would be nice to avoid double rounding if it can be done internally
for free, but I don't see it as a requirement.
[...]
> On the other hand
> x_d64 [+]_b64 y_b32 or x_b64 [/]_d64 y_b32
> mix up the radixes and are not permitted.
It don't see why it shouldn't be permitted. If the implementation can
support it, why preventing it from doing so?
> An advantage of (point,point) -> interval is that it allows a
> P1788-oriented resolution of "what is the result when some input is
> not a finite real?" Whereas, if we take Ulrich's route we may find
> ourselves struggling with Qs like
>
> "What is the result of Inf-Inf in round-away from zero mode?"
>
> which is definitely not what P1788 was set up for.
I think that Inf-Inf should be regarded as an error. The behavior
would be implementation defined, but if an interval is returned,
then it should be some form of illegal interval. Ditto for
pow(1.0,Inf) or pow(1.0,NaN), even though 1^x = 1 for any real x.
Said otherwise, you do not know whether Inf or NaN stands for some
indeterminate value (that would be Entire for the intervals) or
some invalid value such as 1/0 or sqrt(-1) (that would be Empty
for the intervals).
> Michel, Vincent, other people who work at the lower level: Would
> such a set of operations be the right sort of compromise between too
> low-level and too high-level?
I think that f(x), with x being a floating-point datum and the
result being an interval, should just be regarded like f([x,x]),
with similar constraints and so on.
--
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 / Arénaire project (LIP, ENS-Lyon)