Re: Motion 54: Introductory staff - signed zeros in inf-sup
P1788, especially Dmitry, Michel, Vladik
You are quite right that we have
(a) In 12.5.2 an imprecise statement of the relation between a member of a number-format and the interval-bound that it denotes,
(b) The use of "bound" and "endpoint" as synonyms throughout the text. It would be clearer if only one word were used.
For (a), my excuse is that its text pre-dates Vincent's Motion 33 on number formats, which clarified the relation between number datums and extended-real numbers.
(b) was carelessness, and I note neither "bound" nor "endpoint" appear in the Definitions at present!
My proposed solution is
A. Use only one of "bound" and "endpoint". Despite Vladik's reasonable point about explaining to mathematicians, I prefer "bound" because, as Michel said, "endpoint" sounds as if it is always a member of the interval.
B. Add "bound" to the Definitions. Maybe say "endpoint" is a synonym.
B'. I note that §4.1 "Frequently used notation and abbreviations" needs adjustment. Should we say
F,G,... generic notation for a number format.
Should we delete the "\overline{IF},\overline{IG}" entry as we don't use it? Or should we start using this notation systematically?
C. Dmitry suggests
On 2013 Nov 17, at 17:20, Dmitry Nadezhin wrote:
> 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 ?
I would prefer "extended-real value". How about in §12.4 "Number formats", at the end of paragraph "Following the convention of ..." add
"The *extended-real value* (or just *value* when context makes clear)
of an F-number is the extended-real number it denotes: namely the value
of -0 and +0 is 0, and of each other F-number is itself."
Also add this notion to the definition of a number format, 4.2.23.
D. In 12.5.2 change
"The inf-sup type derived from a supported number format F ... is the bare interval type T comprising all intervals whose endpoints are in F (with ±0 replaced by 0), together with Empty"
to
"The inf-sup type derived from a supported number format F ... is the
bare interval type T comprising all intervals whose bounds are the
extended-real values (see §12.4) of F-numbers, together with Empty".
Or, introduce new notation in 12.4, say Val(F), to mean the set of values of F-numbers. Then one could write (I prefer this):
"The inf-sup type derived from a supported number format F ... is the
bare interval type T comprising all intervals whose bounds are in Val(F)
(see §12.4), together with Empty".
Adjust the definition of mid-rad type similarly.
E. In 12.10.1, nextUp and nextDown need to be more precise. Are their input and output F-datums (as in 754 §5.3.1)? If so, we need to specify as 754 does that if x is the negative F-number of smallest magnitude then nextUp(x) is -0 if F contains this.
I would prefer to say nextUp and nextDown are maps from Val(F) to Val(F). (They could be from extended-reals Rbar to Val(F), but is that useful?)
F. In 12.12.8 "Difficulties in implementation" could "are values of" in "In the former case, l and u are values of supported number formats ..." be ambiguous? Change to "belong to"?
Comments please before I make such changes.
John Pryce
------------------------------------------------
On 2013 Nov 18, at 03:16, Dmitry Nadezhin wrote:
> Michel,
>
>>> 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 ?
>>
>> No, because 12.5.2 talks about the actual bounds as members of F, not
>> their values, as I had initially assumed.
>
> I understand nonempty intervals at different levels in such a way:
>
> Level 1 - mathematical interval.
> The bounds of interval are extended reals.
>
> Level 2 - a datum that is a pair of a type tag and a Level 1 interval.
> The bounds of datum are still extended reals.
>
> Level 3 - an object. Its fields might be elements of number format F.
> There is a mapping from valid Level 3 objects to Level 2 datum.
> Fields are not necessarily bounds (for example neginf-sup-nan representation).
>
> 12.5.2 is in Level 2 description. So its bounds are extended-reals.
> Hence I want to distinct
> - format F which is a disjoint sum of a few symbols
> and of a finite subset of extended reals;
> - its "extended-real image" that is a finite subset of extended reals.
> I guess that there is a better name for "extended-real image".
>
>> I think it would be preferable to use "bounds" instead of "endpoints",
>> except when the context is clearly about bounded intervals. This is
>> because "endpoint" suggests that it is a member, whereas "bound" does
>> not. I realise that "bound" can also mislead: "a bound" could mean
>> anything outside an interval, but "the bound" is pretty unambiguous.
>> Do we have to worry about the fact that the grammatical distinction
>> between indefinite and definite articles may not be sufficiently clear,
>> depending on the reader's linguistic background?
>
> Yes. "the bound" is unambigous and I always forget about articles.
>
>> Ok, I scanned the entire Oct 25 P1788 draft 8.1 for "endpoint" and "bound",
>> and found that both are used almost interchangeably, with "bound" generally
>> denoting the thing used in an inf-sup representation, often qualified
>> with "upper" or "lower", or used as "bounds" to mean both, and "endpoint"
>> (including "infinite endpoint, in D.2) used to denote the thing denoted by
>> the bound. The upper and lower bounds are introduced in 4.1 and 4.2.28,
>> but "endpoint" first appears in a side remark of an example at the end of
>> Clause 8, and begins to be used more frequently in Clauses 10 -- often right
>> next to uses of "bound".
>
> I would like to ask John hiw he intended to use these words.
>
> John,
>
> Are "the bound" and "endpoint" synonyms in P1788 or each of them has special meaning ?
> Can we choose one of them to use consistently across the P1788 ?
> Should we use the article "the bounds" everywhere ?
>
> -Dima
>
>
> ----- Исходное сообщение -----
> От: mhack@xxxxxxx
> Кому: stds-1788@xxxxxxxxxxxxxxxxx
> Отправленные: Понедельник, 18 Ноябрь 2013 г 5:43:11 GMT +04:00 Абу-Даби, Маскат
> Тема: Re: Motion 54: Introductory staff - signed zeros in inf-sup
>
> Before I reply I have to take something back. I had written, with
> respect to Dima's suggested fix of the first paragraph of 12.5.2:
>>> 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.
>
> I had overlooked the fact that this was specifically about the
> inf-sup type derived from a number format F.
>
> The number format F explicitly contains points named +Inf, and
> either 0 or both of -0 and +0, and the cohort distinction of
> decimal formats is considered inconsequential, even if that has
> not been said explicitly.
>
> What bothered me however was the word "endpoints" -- I think we
> should use "bounds" instead. But I'd have to scan the entire
> draft to verify whether "endpoint" is used consistently.
>
> Given the above, the addition of "(with +-0 replaced by 0)" is
> still wrong, as we are indeed talking about elements of F, which
> may not have an unsigned zero. I would therefore suggest:
>
> <<<<<<
> 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
> bounds are in F, together with Empty.
>>>>>>>
>
>> Are these words in 12.4 of P1788 correct?
>>
>> -> F comprises a subset of the reals R, together with values
>> -oo, +oo 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.
>
> Yes. It was reading this that opened my eyes.
>
>> 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 ?
>
> No, because 12.5.2 talks about the actual bounds as members of F, not
> their values, as I had initially assumed.
>
> I still stand by my second suggested correction which also removes the
> qualification "(with +-0 replaced by 0)" in the definition of "accurate",
> because in that case it is explicitly about values and not datums.
>
>> 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 ?
>
> I think it would be preferable to use "bounds" instead of "endpoints",
> except when the context is clearly about bounded intervals. This is
> because "endpoint" suggests that it is a member, whereas "bound" does
> not. I realise that "bound" can also mislead: "a bound" could mean
> anything outside an interval, but "the bound" is pretty unambiguous.
> Do we have to worry about the fact that the grammatical distinction
> between indefinite and definite articles may not be sufficiently clear,
> depending on the reader's linguistic background?
>
> Ok, I scanned the entire Oct 25 P1788 draft 8.1 for "endpoint" and "bound",
> and found that both are used almost interchangeably, with "bound" generally
> denoting the thing used in an inf-sup representation, often qualified
> with "upper" or "lower", or used as "bounds" to mean both, and "endpoint"
> (including "infinite endpoint, in D.2) used to denote the thing denoted by
> the bound. The upper and lower bounds are introduced in 4.1 and 4.2.28,
> but "endpoint" first appears in a side remark of an example at the end of
> Clause 8, and begins to be used more frequently in Clauses 10 -- often right
> next to uses of "bound".
>
> So perhaps all we really need is to mention "endpoint" in 4.1 in the
> description of IFbar, IGbar:
>
> IFbar, IGbar, ... the members of IRbar whose lower and upper bounds
> (also known as \em{endpoints}) are in F, G, ...
>
> Then we can continue to use both terms.
>
> Michel.
> ---Sent: 2013-11-18 01:40:21 UTC