Re: Motion P1788/M0014.01: 6.1_and_6.2_of_document: up for discussion
Svetoslav
I think Dan's explanation is spot on. The (one-to-many in general) maps
(Level 2 interval datum) -> (Level 3 interval object) -> (Level 4 interval bit-string)
are to be "lossless" (not lose any information whatever) in the same way and for the same reason that in 754, the maps
(Level 2 floating point datum) -> (Level 3 floating point object) -> (Level 4 floating point bit-string)
are lossless. Inexactness happens, but in the map Level 1 -> Level 2 ("rounding" for FP, "hull" for intervals).
As we've discussed at length, there is NOTHING in this that forbids an algorithm to use midrad for its own internal purposes.
John
On 22 Apr 2010, at 16:30, Dan Zuras Intervals wrote:
>> Nate Hayes" wrote:
>> ...Why is this important?
>
> Imagine an internal format (such as mid-rad) for which
> the extraction of the upper & lower bounds involves an
> arithmetic operation that admits the possibility of a
> rounding error.
>
> Then it is possible for that format to internally
> represent two different intervals, say (m1,r1) & (m2,r2)
> such that those two intervals would BOTH extract the
> same floating-point numbers as their upper & lower
> bounds.
>
> Two such intervals would be both different &
> indistinguishable. They would participate in subsequent
> operation differently & one would not be able to
> understand why.
>
> ...
> Dan
On 22 Apr 2010, at 10:48, Svetoslav Markov wrote:
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)?