Re: As simple as it is now, I am still against motion 24.03...
On 2011-06-10 10:50:31 -0400, Michel Hack wrote:
> You have to realise that there are different classes of "users" who can
> benefit from a standard:
> (1) end-users, who want a predictable environment for doing their work.
> (2) library writers, who want a predictable set of primitives in order
> to provided the full functionality needed by group (1).
> (3) compiler and basic runtime writers, who need to know what primitives
> to provide for both (1) and (2).
There are not classes of users. All developers are end-users w.r.t.
what they depend on provides. And there may be cycles. For instance,
our MPFR library is based on the C standard and the GMP library, so
that we are end-users of the C standard and GMP, but we also provide
a predictable environment for our users, and MPFR is also used by
compilers (GCC).
You need to differentiate classes for some feature or standard.
Concerning P1788, you will have implementers of this standard
and end-users of this standard (one can also be a user of some
implementation and at the same time a writer of some other, more
powerful implementation...).
Implementers of P1788 will typically be users of the IEEE 754 standard
(when available, and when not, the implementations may be restricted
to some environment), and more generally the provided floating-point
environment.
If you think that some property of the floating-point environment
is useful for P1788, then write a standard for the floating-point
environment, but don't make such a property a requirement to
implement P1788, as this would not be constructive. What I mean
is that some environments (e.g. languages) are not targeted at users
of interval arithmetic (so do not provide directed rounding modes)
and may not change; still there may be solutions to provide an
interval arithmetic implementation.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)