Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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