Re: Motion 54: Introductory staff - signed zeros in inf-sup definition
Michel,
Are these words in 12.4 of P1788 correct ?
– F comprises a subset of the reals R, together with values −∞, +∞ and NaN, and optionally
signed zeros −0 and +0.
– F contains 0, or contains −0 and +0, or both.
So real endpoints (except 0) are in F.
But real 0 is not in F, when F is 754-format.
Later 12.4 says
<<<
For an operation that has an extended-real argument at Level 1 and has a Level 2 version with
input of some format F, this input is first mapped to an extended-real value. Namely, ±0 map to
0, all other numeric values map to themselves, and NaN is treated as an invalid input.
>>>
If there were a name of the result of the map above (say "extended-real image of F"),
then we could say "comprising all intervals whose endpoints are in extended-real image of F".
Is this better ?
> Or have we formally defined "endpoint" to include infinite
> numbers of the Extended Reals? (If so, ny correction is
> not needed.)
Section 10.2 defines "bounds" \underline{x} \overline{x} as extended-real numbers.
The third note in 10.2 says: pairs \underline{x} \overline{x} of "endpoints".
So there is no definition of "endpoints", but it is used as synonim of "bounds".
Will it be clearer to use only one of these two word through all the standard ?
-Dima
----- Исходное сообщение -----
От: mhack@xxxxxxx
Кому: stds-1788@xxxxxxxxxxxxxxxxx
Отправленные: Воскресенье, 17 Ноябрь 2013 г 20:37:38 GMT +04:00 Абу-Даби, Маскат
Тема: Motion 54: Introductory staff - signed zeros in inf-sup definition
Dmitry Nadezhin wrote, with respect to subsection 12.5.2:
> Format F might contain symbols +0 and -0 instead of real 0
> (as all 754 formats). Then real endpoint can't be in F.
> More precises wording:
> <<<<<<
> The inf-sup type derived from a given number format F
> (the type inf-sup F, e.g., "inf-sup binary64") is the bare
> interval type T comprising all intervals whose endpoints
> are in F (with +-0 replaced by 0). together with Empty.
> >>>>>>
NO -- please don't! The actual datums of format F may not even
appear as endpoints -- e.g. MidRad -- and all that matters are
the mathematical VALUES of the endpoints. Zero has only one
value, regardless of its form (+0, -0, or one of the many cohorts
of zero in a decimal format).
A more important correction would be:
<<<<<<
The inf-sup type derived from a given number format F
(the type inf-sup F, e.g., "inf-sup binary64") is the
bare interval type T comprising all intervals whose
finite endpoints are in F, together with Empty.
>>>>>>
That's because an unbounded interval doesn't have an
endpoint on one or both sides, except in the Extended Reals.
Or have we formally defined "endpoint" to include infinite
numbers of the Extended Reals? (If so, ny correction is
not needed.)
The issue of the value of zero also arises in a later post:
> accurate may refuse when [min(l,u),max(l,u)] is bounded
> and contains no more than one value of F
> (with +-0 replaced by 0), and
> may return f(x) \subseteq nextOut(hull_T([min(l,u),max(l,u)]))
Again, the qualification for zero is not needed because we are talking
about the value -- and it would in any case be incomplete if we really
meant the datum, due to decimal cohorts. So please remove it!
Michel.
---Sent: 2013-11-17 16:26:01 UTC