Re: Motion: Number format (Motion 33?)
On 2012-04-13 11:58:19 +0200, J. Wolff von Gudenberg wrote:
> Vincent
> I agree that such a motion restricting the associated formats makes
> sense.
> But I would be more selective. the directed rounding modes, e.g. should be
> supported
They are supported ("A constraint can be given on the rounding
direction. It must be satisfied."). However it isn't necessarily
a correct rounding.
> Am 13.04.2012 03:50, schrieb Vincent Lefevre:
> >A2. A datum can have different variants or different representations
> >(e.g. qNaN / sNaN [IEEE 754 §6.2], cohorts for decimal floating-point
> >numbers [IEEE 754 §2.1.10 and §3.5.1], signed zeros), but they are
> >not distinguished in F, possibly except for the number 0, which may
> >be regarded as signed by the P1788 implementation; in such a case,
> >it has exactly two possible values, denoted -0 and +0.
> there is no +0 , -0 in p1788
In intervals. However the set of numbers may have signed zeros, e.g.
the IEEE 754 binary64 format. There are two possibilities:
1. Consider that both zeroes are equivalent (i.e. they are the same
variant of the same value), and do not specify anything about the
sign.
2. On the contrary, specify the sign of 0 on implementation where it
matters.
I think that in the IEEE 754 spirit, one should specify the sign if
zero is regarded as signed (that is mandatory only in 754-conforming
implementations). Some other standards, like ISO C (currently C11,
but this was already the case in C99) and LIA-2, have a similar
specification: zero can be signed or not for floating-point datums.
Note: in IEEE 754, there is also a distinction between representations
of a same datum (a.k.a. cohorts), but specifying them would be to go
too far (BTW, in IEEE 754, the sign of zero is a Level 2 notion, while
cohorts are a Level 3 notion).
> >A5. An element of Rbar (Level 1) is mapped (rounded) to an element
> >of F (Level 2) according to the following rules:
> rounding is a function r fom Rbar to F with
> r(x) = x if x in F
> r is monotone
This may be too complex in exotic format (which could involve
transcendental functions, e.g. like in a logarithmic arithmetic).
Monotonicity of math functions isn't even required by IEEE 754.
Correct rounding is recommended like here (2nd and 3rd points
below).
One could require that r(x) = x if x in F *and* there are no
rounding-direction constraints.
> directed rounding ru and rd are available
> rd(x) <= x <= ru(x)
This is more or less the point below (but rd and ru are not
necessarily functions, i.e. the roundings of f(I) and g(J)
may be different even in cases where f(I) = g(J)).
> > * A constraint can be given on the rounding direction. It must
> > be satisfied.
> > * Following this constraint, the rounded result should be an
> > element of F that is the closest to the exact result (with
> > a special implementation-defined rule for the distance to
> > an infinity).
> > * In general, this element is unique, but there may exist two
> > elements satisfying this property (halfway cases). How these
> > cases are rounded should be documented by the implementation.
[...]
> >On A1, we require the subset to be finite
> in
> > order to be able to
Thanks, corrected.
> >On A5, correct rounding is recommended, but not required because it
> >may be difficult or may not really be useful in exotic number formats.
> who wants to implement p1788 on exotic number formats ?
One point is that such exotic number formats may already exist on
the system (e.g. double-double on PowerPC, and according to a recent
discussion in the GCC dev list, it won't go away in the near future).
Implementing a few primitives and reusing the high-level code may be
sufficient for a P1788 implementation (I suppose that's what classes
do in OO languages).
I recall that correct rounding is required for 754-conforming
implementations.
--
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 / AriC project (LIP, ENS-Lyon)