Re: Motion M0050:EDP-Without-CA
On 1 Oct 2013 at 13:41, Vincent Lefevre wrote:
Date sent: Tue, 1 Oct 2013 13:41:28 +0200
From: Vincent Lefevre <vincent@xxxxxxxxxx>
To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
Subject: Re: Motion M0050:EDP-Without-CA
> On 2013-10-01 14:20:45 +0300, Svetoslav Markov wrote:
> > > > Sorry, I do not understand what you say. If a true numeric result is a
> > > > number (degenerate interval) like 12345 + 12345^(-50)
> > >
> > > You probably meant 12345 + 12345*10^(-50).
> >
> > Yes, indeed, sorry!
> > >
> > > > then the MR form can be a tight number if an
> > > > EDP-data object is available, and a wider interval if not available.
> > > > In particular, if a true numeric result is the number
> > > > 1 + 1^(-50) then the MR form will be an exact number if an
> > > > EDP-data object is available, and will be an interval if not available.
> > >
> > > This is confusing. A mid-rad representation is different than a
> > > degenerate (singleton) interval like [12345 + 12345*10^(-50)].
> > > If it's a degenerate interval of the form [x+y], you shouldn't
> > > call it mid-rad.
> >
> > Thank for your correction.
> >
> > I had in mind that a singleton 12345 + 12345*10^(-50) can be
> > converted into a very tight mid-rad interval with centre 12345 and
> > radius, say, 12346*10^(-50). Sorry for careless writing.
>
> Note that when converting 12345 + 12345*10^(-50) to a mid-rad
> interval <12345,12346*10^(-50)> (with a non-zero radius), you
> lose information: you no longer have a singleton. Now, this
> may not be important for you...
well, it is important as long as it shows that conversion of
exact numbers involves interval arithmetic - under the inclusion
(containment) principle
>
> > Can you be more specific? How can we convert in MR-form tightly a
> > singleton result like 12345 + 12345*10^(-50) without EDP-data type
> > and without further knowledge (e.g. knowing that it is exactly
> > representable as x+y? )
>
> First an EDP-data type is just some particular case of a conventional
> multiple-precision type (possibly in a fixed precision). You can use
> such a type. You don't need the existence of EDP.
I see your point. However, I think that in its last version, the motion
only requires the possibility to extract (and make use of) the
exact numeric results, without stressing on the hardware implementation.
So, exact numeric results are needed for tight intervals
during conversion - therefore the motion is related to
the interval standard (in contrast to some opinions that it is not)
>
> But you can also use another format: a double-word format, where a
> number is represented by a pair (x0,x1) of a native floating-point
> format, with x1 << x0. Here, x0 = 12345 and x1 = 12345*10^(-50).
> This can be more efficient than a multiple-precision type such as
> "EDP-data type".
>
> --