Re: Motion M0050:EDP-Without-CA
On 1 Oct 2013 at 11:11, Vincent Lefevre wrote:
Date sent: Tue, 1 Oct 2013 11:11:48 +0200
From: Vincent Lefevre <vincent@xxxxxxxxxx>
To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
Subject: Re: Motion M0050:EDP-Without-CA
> On 2013-10-01 11:14:14 +0300, Svetoslav Markov wrote:
> > I would gladly change my vote if someone answers my contra-argumnts
> > of sept 16. I slightly modify my first argument to make it more clear.
> >
> > To the agument of Richard Fateman:
> >
> > I think that translation from end-point (EP) to mid-rad (MR)
> > form and vice versa will benefit from the EDP. In particular,
> > if one of the two forms (say EP) is a numeric resul of
> > some computation (degenerate interval),
> > obtained as EDP-data object, then the other form (say MR)
> > may be necessarily nondegenerate interval. The latter will
> > be (or may be) sharper if EDP is available.
> >
> > Thus, translation actually may involve intervals. This means that
> > EDP is not related just to numbers, and its use is justified in an
> > interval standard.
>
> This translation is done by the implementation, either by EDP
> or directly in a *more efficient way*. You don't need EDP in
> the external interface for that.
Sorry, I do not understand what you say. If a true numeric result is a
number (degenerate interval) like 12345 + 12345^(-50)
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.
>
> > To the agument of Vincent Lefevre:
> >
> > If EDP is available then the operations exact sum or an exact product
> > of two numbers are readily available as special cases of EDP.
>
> This is an ugly way to get them, and it may be difficult (if not
> impossible, e.g. in case of a library) for the compiler to detect
> these special cases and optimize.
>
Well ...