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)