Re: A Level 2 query
On 2013-06-10 08:52:49 +0100, John Pryce wrote:
> That was in floating point, where inconsistencies (between
> compilers, or between optimisation levels of one compiler) can be
> extremely annoying. With intervals, you have containment and the
> effect, especially if done throughout a long expression, will be to
> get a tighter enclosure than you "expected". Is that really so
> annoying? Actually I tend to agree with you and am playing devil's
> advocate.
I also find this less important for intervals. But note that the
double-rounding problem has a noticeable effect only for rounding
to nearest, not for the directed rounding modes used with inf-sup
interval types. Thus if
(1) T' is a superset of T;
(2) T -> T' tightest operations are implemented;
(3) T' -> T tightest hull is provided (this is required, isn't it?);
then the corresponding T -> T tightest operations are obtained by
composition of (2) and (3), so that I don't see any reason not to
provide these T -> T operations. But for a language not providing
them natively or in a library, saying "to get such an operation,
the programmer must write the composition explicitly" would be
a way to conform to the standard, IMHO, though languages should
define a shorter/simpler way to write these operations.
This is for the "tightest" accuracy mode. For the "valid" accuracy
mode, there are obviously no problems either with the composition,
even for implicit types.
It seems that the "accurate" accuracy mode is not specified for
formatOf operations, though it is rather easy to extend it to these
operations: the inner nextOut applies on type T and the outer nextOut
applies on type T'. Then I think that there are no problems either
with the composition ((3) still being tightest, of course), but this
needs to be checked carefully.
--
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)