Re: Draft: P1788.1 Standard for Interval Arithmetic (Simplified)
[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)