Alternate floating-point results under directed rounding
On Mon, 10 Nov 2008 12:17:31 -0800, Van Snyder wrote:
>On Sun, 2008-11-09 at 23:13 -0800, John Pryce wrote:
>> Similarly if a mixed point & interval computation goes close to
>> overflow then - in genuine application code - that's dumb, and
>> you should be _grateful_ for a mechanism, like returning Empty,
>> that tells you so.
>>
>> Actually I say it should return NaI. Empty can be a genuine, correct
>> result, whereas NaI is _always_ an indicator that something went wrong.
>
> I don't understand the advantage of NaI as the result of a computation
> such as 2.0*?0.25*HUGE,0.75*HUGEÙ, instead of returning ?0.5*HUGE,infÙ
> with overflow signaling.
If this is computed as intval(2.0)*[0.25*HUGE,0.75*HUGE] you should get
what you expect (but possibly WITHOUT overflow).
However, if you have 2.0*HUGE*[0.25,0.75] and evaluation associates to
the left (as is usual), you would indeed get NaI, because the overflow
happened before IA was entered.
It all depends on how type coercions are defined -- and we should indeed
think about proper guidelines. I mentioned another case earlier where
precedence of type conversions is critical: converting a binary128 to
an interval based on binary64.
I already commented to Arnold that he should consider floating-point type
issues in his proposal, especially for float->interval conversions. In
his proposal, mixed float/interval computations are carried out by first
converting floats (or strings) to intervals, not by having explicit mixed
operators such as addFloatToInterval (of which there would have to be a
bewildering variety).
Michel.
Sent: 2008-11-10 21:43:18 UTC