Re: Motion P1788/M0014.01: 6.1_and_6.2_of_document: up for discussion
> From: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
> To: "Svetoslav Markov" <smarkov@xxxxxxxxxx>,
> "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
> Cc: "stds-1788" <stds-1788@xxxxxxxxxxxxxxxxx>,
> "R. Baker Kearfott" <rbk@xxxxxxxxxxxxx>
> Subject: Re: Motion P1788/M0014.01: 6.1_and_6.2_of_document: up for discussion
> Date: Thu, 22 Apr 2010 09:53:46 -0500
>
> Corliss, George wrote:
> > Svetoslav,
> >
> > On Apr 22, 2010, at 4:48 AM, Svetoslav Markov wrote:
> >> 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."
> > My understanding:
> >
> > This language prohibits mid-rad as an internal representation.
> >
> > Once an interval \x has been created, it has lower and upper bounds
> > which are machine numbers. This language requires that accessor
> > functions inf(\x) and sup(\x) return the lower and upper bounds,
> > respectively, as the machine numbers that are stored. There is no
> > rounding on retrieval.
>
> Why is this important?
>
> Nate
>
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.
George says this restriction prohibits the mid-rad form.
I disagree. At least in principle.
But it DOES mean that such a representation must take more
care to represent exactly that set of intervals that would
be represented by an inf-sup form, nor more & no less.
That may place an unreasonable burden on the mid-rad form
that causes people to want to abandon it. I don't know.
But I'd like to think not. Because there are computational
efficiencies available in that form that favor its use in
some applications.
Time will tell.
Dan