Re: The current proposal
I think the point Siegfreid makes is that the "ideal" mathematical properties of the interval arithmetic should drive the implementation, not the other way around.
For example, the very simple formula for addition
[a,b] + [c,d] = [a+b,c+d]
breaks down if c=d=Inf and a=-Inf. In that case, IEEE arithmetic produces
(-Inf,b] + (Inf,Inf) = [NaN,Inf),
whereas the "ideal" result would be
(-Inf,b] + (Inf,Inf) = [0,Inf),
assuming the "infinity is number" paradigm where the infinity is not a member of the interval but rather a token for an unbounded real endpoint.
My additional point is that for an interval processor, returning such an "ideal" result is easy and causes no performance penalty.
So the question is, what are the "ideal" properties of the interval arithmetic that we all desire? I agree the properties 1-4 Siegfried lists are desireable, and I _beleive_ the "infinity as number" example above satisfies them all. But
perhaps others can double-check.
Nate
----- Original Message ----- From: "John Pryce" <j.d.pryce@xxxxxxxxxxxx>
To: <stds-1788@xxxxxxxxxxxxxxxxx>
Sent: Monday, February 23, 2009 4:47 AM
Subject: Re: The current proposal
Dear all
Arnold wrote, re Siegfried's proposal:
It does not make any sense at all to complicate a standard just to
hide one possible source of naive semantic errors.
This is also my feeling, at least initially, but I will consider
Siegfried's proposal in more detail.
John Pryce