Re: The current proposal
I do agree. In both examples provided by Siegfried, the underlying interval libraries may be fast. But if the user wishes a reasonable answer, they must add their own code, and this makes things slow anyways. It also does not standardize
the way in which people may then handle these exceptional cases. So I see it as a Pandora's box.
Furthermore: in the context of the current discussion, a fast software implementation may conform to an IEEE 1788 standard that is "perfectly documented" but perhaps unreasonable or tedious. Yet at the same time, an interval processor which
can easily implement non-tedious and expected behavior would then be non-conformant to such a standard.
I think it is a good goal to aim at an IEEE 1788 standard that will be as friendly as possible to fast and efficient software implementations. But it also seems that if preference is not given to an "ideal" interval arithmetic that could be
fast in hardware (even if it is slow in software), then we may be stuck for a long, long time with interval arithmetic that is not really what we would all hope for.
Sincerely,
Nate Hayes
Sunfish Studio, LLC
P.S. Baker, if I still have problems with the reflector, could you see this gets forwarded to stds-1788?
----- Original Message ----- From: "Siegfried M. Rump" <rump@xxxxxxxxxxxxx>
To: "stds-1788" <stds-1788@xxxxxxxxxxxxxxxxx>
Sent: Saturday, February 21, 2009 8:35 PM
Subject: The current proposal
> Dear all,
>
> we are discussing the standardization of interval arithmetic. This
> is not intended to pass and put into the cabinet, but intended to use.
>
> May I ask how many of you have experience in using interval arithmetic?
>
> Here is why I must insist that the current proposal is academic and
> puts burden of case distinctions on the user.
>
> Trust me, it is very natural in interval arithmetic to do interval
> calculations with the bounds.
> For a given function F, for example, X=F(interval(A.sup)) should give an
> inclusion of the value of F at the right bound of A.
>
> With the current proposal, this needs a case distinction:
>
> if A.sup==Inf
> X = F(interval(realmax,Inf));
> else
> X = F(interval(A.sup));
> end
>
> This burden is on the part of the user. Even worse, it is likely to be
> forgotten and to pass unoticed. And then false results may appear, the
> worst what can happen to a verication method.
>
> Let me transpose this to the floating-point world.
>
> Imagine the question "What is the result of -0==0" is at stake. There
> are good arguments that it should be true, like in IEEE 754, but one
> may also argue that these are two different quantities, so how can they
> be equal.
>
> Now suppose it is voted for the latter, so that from now on one cannot
> just write
>
> res = ( x==y );
>
> but must use
>
> if abs(x)==0
> res = ( abs(x)==abs(y) );
> else
> res = ( x==y );
> end
>
> or alike. It may be perfectly documented, but is this reasonable?
>
> IMHO the current proposal for interval arithmetic is very similar.
>
> Best wishes
>
> Siegfried M. Rump
>
>
> --
> =====================================================
> Prof. Dr. Siegfried M. Rump
> Institute for Reliable Computing
> Hamburg University of Technology
> Schwarzenbergstr. 95
> 21071 Hamburg
> Germany
> phone +49 40 42878 3027
> fax +49 40 42878 2489
> http://www.ti3.tu-harburg.de
>
> and
>
> Visiting Professor at Waseda University
> Faculty of Science and Engineering
> Shinjuku Lambdax Bldg. 902
> 2-4-12 Okubo, Shinjuku-ku
> Tokyo 169-0072
> Japan
> phone/fax in Japan +81 3 5286 3414