Re: Draft: P1788.1 Standard for Interval Arithmetic (Simplified)
Sure. I spent an entire summer debugging errors of the form
0 should be in [-2, -1] x 10^{-16}
in my numerical quadrature package. Without intervals, I would have thought I had the right answers. I didn’t.
I am not trying to diminish the importance of thin and narrow intervals, but to raise up the importance of thick intervals in many practical scientific and engineering applications.
We need BOTH.
George Corliss
> On Jul 30, 2015, at 7:26 AM, Ralph Baker Kearfott <rbk5287@xxxxxxxxxxxxx> wrote:
>
> George et al,
>
> What about for development and debugging purposes?
>
> Baker
>
> ----- Original Message -----
> From: "George Corliss" <george.corliss@xxxxxxxxxxxxx>
> To: "Vincent Lefevre" <vincent@xxxxxxxxxx>, "IEEEP1788a" <stds-1788@xxxxxxxx>
> Cc: "George Corliss" <george.corliss@xxxxxxxxxxxxx>
> Sent: Thursday, July 30, 2015 6:22:24 AM
> Subject: Re: Draft: P1788.1 Standard for Interval Arithmetic (Simplified)
>
> I fully agree with Vincent on the value of hex.
>
> However, I cannot miss the opportunity to remind us that (EXCEPT FOR MATHEMATICS) very few numbers are known to more than a few places. Hence (EXCEPT FOR MATHEMATICS), no intervals are thin.
>
> Of course, mathematical analysis is important, too, and there, thin and 1 ULP intervals are appropriate.
>
> George Corliss
>
>
>
>> On Jul 30, 2015, at 5:08 AM, Vincent Lefevre <vincent@xxxxxxxxxx> wrote:
>>
>> [Resend of a mail I've sent in a private discussion]
>>
>> On 2015-07-29 11:53:25 -0400, Ned Nedialkov wrote:
>>> I did not feel the hex representation is used much in interval
>>> software. Surely, I can be wrong and I can put
>>> the hex representation back.
>>> Any views on to have it or not to have it?
>>
>> It is already used by software (but not interval software, which
>> I do not know specifically) that is low-level concerning the
>> arithmetic, such as GCC and the GNU C library. It is also used in
>> some MPFR tests (as strings, due to the multiple-precision context);
>> MPFR tests also use binary very often, but this is less compact. But
>> note that in C, the hex for has been available only since ISO C99,
>> while software still often needs to be compiled with C89 compilers
>> too (this is changing, though). But there's the same kind of problems
>> with changing the rounding mode and the fact that most programs don't
>> change it doesn't mean that it isn't useful/needed... in particular
>> for interval arithmetic.
>>
>> Though not strictly needed, hex may be much better than decimal,
>> and in particular less error prone, when one needs to provide
>> double precision numbers exactly, in particular for values that
>> come from another program. It can also make the code easier to
>> read, e.g. for powers of two, which have a particular importance
>> in a binary floating-point context (e.g. a ulp is a power of two).
>>
>> For very large or very small (in absolute value) numbers (i.e. with
>> a large or small exponent), if they are written in decimal, one has
>> the choice between:
>> * writing them exactly, but with two drawbacks:
>> 1. one needs many digits;
>> 2. when reading them with directed rounding (like in P1788.1),
>> one needs to look at *all* the digits to get their value as
>> double precision numbers, because such decimal sequences
>> correspond to breakpoints, which are the hardest-to-round
>> cases;
>> * writing an approximation (with something like 17 or 18 digits),
>> but this means that the rounding mode will mater. Thus this is
>> error prone, in particular because rounding to nearest is used
>> most often (if not always, in some contexts). To generate a
>> decimal string for a P1788.1 application, the program will need
>> to be aware of that, while most programs can just deal with
>> rounding to nearest. And even if it can change the rounding mode,
>> there may be bugs in the compiler (gcc needs -frounding-math,
>> C99's "#pragma STDC FENV_ACCESS ON" is not sufficient) and
>> libraries, such as for the GNU C library:
>> https://sourceware.org/bugzilla/show_bug.cgi?id=5044
>> (printf doesn't take the rounding mode into account)
>> https://sourceware.org/bugzilla/show_bug.cgi?id=14518
>> (strtod ignores the rounding mode)
>> now both fixed, but in 2012, so that this is quite recent.
>>
>> Note: For single-point intervals (singletons), one needs to write
>> the number exactly to be able to use the [x] form, thus possibly
>> with many decimal digits if one doesn't have the hex form. And using
>> the [l,u] form with l < u (as represented with few decimal digits)
>> for single-point intervals would make the code confusing.
>>
>> --
>> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/>
>> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
>> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)