Re: Motion P1788/M0014.01: 6.1_and_6.2_of_document: up for discussion
> From: "Svetoslav Markov" <smarkov@xxxxxxxxxx>
> To: "R. Baker Kearfott" <rbk@xxxxxxxxxxxxx>,
> stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Date: Thu, 22 Apr 2010 12:48:54 +0300
> Subject: Re: Motion P1788/M0014.01: 6.1_and_6.2_of_document: up for discussion
>
> P-1788:
>
> can somebody explain what for is the line of text in 6.1 that says:
>
> "provided that it shall be possible to retrieve the bounds of x exactly."
>
> What is the reason and motivation for this requirement? .
> I cannot think of any reason why "exactly" should be required.
> One would think inclusion isotonicity is enough. Besides,
> it is not clear in what sense the word "exactly" is used -
> in the sense of real or machine arithmetic (that is at most
> 1 ulp lost)?
>
> Regards,
>
> Svetoslav
>
Well, I did not write this text but I'll tell you what
it means to me.
I interpret 'exactly' in this context as stronger than
isotonicity. Stronger even than 1 ULP lost. I interpret
'exactly' as meaning that no information is lost in the
recovery of the bounds from whatever internal format is
used.
Formally, exactly means that the implementer's format
together with the method of recovering the bounds is
indistinguishable from the ordered pair [lowerBound,
upperBound] in some given floating-point format. Stated
slightly differently, the set of intervals representable
must be indistinguishable from the set of intervals
representable by [lowerBound, upperBound] where both
bounds are numbers in a given floating-point format.
Assuming that there exists -x for all x in a given
floating-point format we have that all of [lowerBound,
upperBound], [-lowerBound,upperBound], & [lowerBound,
-upperBound are indistinguishable in this sense. (So
is [-lowerBound,-upperBound] for that matter but it
doesn't seem to have any merit WRT fixing the rounding
mode problem. :-)
One subtle point that is not made clear by this is that
it requires that a representation of the form (mid,del1,
del2) which represents the interval [mid+del1,mid+del2]
must do so exactly. That is lowerBound = mid + del1 &
upperBound = mid + del2 EXACTLY, with no rounding errors.
This is not so much of a problem but it does mean that
any system choosing to use this mid-rad form in an
attempt to speed things up in the |rad| << |mid| case
must find some other way of representing semi-infinite
intervals such as [2,+oo] & [3,+oo] which don't fit in
this format.
Another thing one should note is that while the constraint
to recover 'the bounds of x exactly' is REQUIRED (under
the verb 'shall') the entire discussion of possible formats
is within a note (that is, informative ONLY & not at all
required).
I compliment the author on being careful in how this is
written.
So, does that clarify things or just make it harder?
Oh, well. I tried... :-)
Dan