Re: As simple as it is now, I am still against motion 24.03...
John Pryce wrote:
> 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?"
It does not address the point I had in mind: when implementing an
interval function one often needs round_down(f(x)) and round_up(g(y)).
Yes, as I said earlier, one can do this by taking low(interval(f(x)))
and high(interval(g(y))), but that is likely to do twice the work
actually needed. (A really good optimizing compiler might detect the
unused pieces and avoid the extra runtime cost.)
Btw, I see nothing wrong in expecting edge cases of directed-rounding
operations to behave like the underlying FP arithmetic. The answers
are then clear for 754-based systems. If the underlying arithmetic
does not support 754-style directed rounding (e.g. IBM's HFP, a S/360
legacy that is still supported on Z), the implementer would have to
do what it takes (e.g. truncate, compare, and add 1 ulp if needed) --
but the library writer would have a primitive that could be trusted
to do the best a particular platform can do -- and, at any rate, keep
enclosure promises.
Michel.
---Sent: 2011-06-11 16:28:01 UTC