Re: The current proposal
Nate Hayes schrieb:
Nate Hayes schrieb:
I think the point Siegfried 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+c,b+d]
breaks down if c=d=Inf and a=-Inf. In that case, IEEE arithmetic
produces
(-Inf,b] + (Inf,Inf) = [NaN,Inf),
which is indeed the current Intlab result. (No user of Intlab
ever had complained about this meaningless construct; so Siegfried
doesn't have to fear being grilled....)
I believe this is a reasonable result in a software implementation,
as it becomes very expensive to return something different.
It is quite cheap to convert (Inf,Inf) to NaN before doing the
operation. This settles the issue within the framework of the Vienna
Proposal.
And even though this proposal is not the standard to be, it
rebuts your claim that ''it becomes very expensive to return
something different''.
I don't know what you talk about.
It only validates what I said: that returning [NaN,Inf) in a software
implementation is cheap and easy.
You had claimed that ''it becomes very expensive to return something
different'' from [NaN,Inf].
But [NaN,Inf] is meaningless in any interpretation, and is in the
ienna Proposal not allowed as the result of an operation with standard
intervals. The correct result is [NaN,NaN]=Empty. This is produced
cheaply by converting infinities to NaN before doing an operation
(with a real argument; otherwise the situation does not occur in the
framework of the Vienna Proposal).
Nate Hayes schrieb:
>> Arnold Neumaier schrieb:
>>> Nate Hayes schrieb:
>>
>>>>>> 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.
>>>
>>> 1/[-1,0] + 1e400 should give in exact arithmetic [-inf,1e400],
>>> hence with infinity-as-number [-inf,inf] in verified floating
>>> point arithmetic.
>>>
>>> If you don't allow the operation 1/[-1,0] to give the value
>>> [-inf,0] then the division operation is not appropriate for
>>> applications to global oto=imization.
>>>
>>> But if you assume 1/[-1,0] = [-inf,0], your proposal gives the
>>> severe underestimate [0,inf].
>
> No.
>
> In your example, zero is a member of the denominator, so infinity is a
> member of the result produced by the reciprocal operation.
No. 1/0 is not defined, hence it does not contribute to the range.
It is like sqrt([-1,4]) returning [0,2] and not a complex interval.
This behavior is highly desirable in the applications, and is
required in the Vienna Proposal.
> C-sets must return [-Inf,Inf] because they allow the infinity to be
> member of the intervals,
No. Csets consider limits of real values, and do not treat infinity as
a number.
Arnold Neumaier