Re: Request for motion [Fwd: Input from IFIP WG 2.5 to IEEE Interval Standards Working Group]
> Date: Thu, 10 Sep 2009 15:06:38 -0500
> From: "Chenyi Hu" <chu@xxxxxxx>
> To: "Dan Zuras Intervals" <intervals08@xxxxxxxxxxxxxx>
> Cc: <stds-1788@xxxxxxxxxxxxxxxxx>,
> "Ralph Baker Kearfott" <rbk@xxxxxxxxxxxx>
> Subject: Re: Request for motion [Fwd: Input from IFIP WG 2.5 to IEEE
> Interval Standards Working Group]
>
> Dan:
>
> 1. Yes, Baker explained the "cancellation" clearly. Thanks Baker. In
> short, it is the inverse operator of interval addition and can be useful
> in applications like Baker illustrated.
Thanks, Now that Baker has explained it, it turns out
I HAVE seen it before. Both John & Nate have spent time
explaining things to me & this is equivalent to an
operation that Nate uses heavily in his work. Also,
early on I attempted (& failed) to make intervals a true
field extension of the reals & found the need for this
operation as an inverse add.
>
> 2. In the Interval BLAS document, we did not specify empty interval and
> exceptions very clearly. We did not use NaI at all. Current discussions in
> 1788 on these issues are very important. In our C++ reference implementation,
> we handled them effectively (hopefully). We discussed our practical
> approach in Chapter 10 of that book. I follow the discussion in 1788
> closely and have learned a lot. We must have a clearly defined solid
> interval arithmetic standard first. Without the first step, we would not
> be able to standardize things built-up on it.
Your approach to interval BLAS is entirely reasonable.
And given that experience I wonder if YOU have experiences
that could guide US in defining the exception details of
1788 rather than us doing it with other considerations in
mind & inadvertently, perhaps, making life difficult for
the interval BLAS writer.
>
> 3. I think our previous work on interval BLAS could be useful in 1788.
> How does the committee want to use it, or not to use it at all, should be
> the decision by this group. By the way, I sent the Interval BLAS document
> to Bill years ago and he led the efforts to include it in Sun's interval
> computing environment.
>
> With regards,
>
> Chenyi
>
From what I can see in my quick skim of your chapter 5
document, it seems well enough worked out as to be able
to form the basis for a 1788 BLAS if not the code itself.
And, the existence of your work convinces me that we should
go ahead & define a standard BLAS for 1788. It is something
that our users will need as well as something hard enough
that they won't be able to write it for themselves.
For us as a standards body, it may fall into a different
class of well defined function than + - * & /. As with the
floating-point BLAS, a well written & efficient (for its host
machine) interval BLAS should return an accurate answer but
not the same from machine to machine. Therefore, specifying
the tolerances for a conforming BLAS will be somewhat more
complicated than 'it returns the best possible interval'.
While this may seem obvious & even trivial, I bring it up
not for technical reasons but to point out that getting
everyone to agree just what the definition of 'good enough
to conform' is turns out to be extremely difficult.
You will notice in clause 9.4 that the accuracy & range of
sum, dot, sum-squares, & sum-abs, are poorly defined. This
is not due to lack of a good definition but due to lack of
consensus.
Here's hoping we can do better...
Dan