>>(And it would even
>>more simplify an implementation to replace "required tightest"
>>with "required accurate, recommended tightest" for
>>ALL "tightest", since some systems without access to rounding modes
>>will have to work hard to get tightest, but can be accurate
>>extremely efficiently. )
>
>Possibly useful for some languages, like XPath (without extensions),
>where all operations are required to be correctly rounded to nearest.
>But I'm not sure whether this is a good idea. The interval type could
>be degraded to an implicit type is such a case.
The principal point in such a specification would be to encourage
languages to do that more generally. I am utterly sick of languages
and libraries that say that, as soon as you use certain critical
facilities, all behaviour is undefined.
Inaccuracy is a minor form of undefined behaviour, but the point
stands.
This is true for floating-point, when the error bound is not given
(or when the error bound is too large to be useful in practice).
Even if the result happens to be accurate, there is no guarantee,
and one doesn't know whether one can trust the result.
This isn't really true for interval arithmetic, as containment gives
useful information. And if one gets a tight interval, one knows one
can trust it.