Re: Motion M0050:EDP-Without-CA
On 1 Oct 2013 at 8:08, John Pryce wrote:
Subject: Motion M0050:EDP-Without-CA
From: John Pryce <j.d.pryce@xxxxxxxxxx>
Date sent: Tue, 1 Oct 2013 08:08:19 +0100
To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> P1788
>
> I'm a little surprised that a few people who voted No on Motion 47 have voted Yes on Motion 50, and I suggest that they may reconsider.
>
> With respect to Prof Kulisch, I agree with the arguments of Richard Fateman and Vincent Lefevre copied below.
Motion 45 gives our standard the *effect* of EDP rounded to the precision of any supported interval type,
without mandating a specific *mechanism*. That's how it should be, in this standard. CA+EDP are great, and deserve their own standard, but do not fit into 1788.
>
> John Pryce
>
> =======================
> On 2013 Sep 15, at 17:25, Richard Fateman wrote:
> > This is motion 50 in the
> > http://grouper.ieee.org/groups/1788/private/Motions/AllMotions.html
> >
> > As I understand it ..
> > A motion (47) to require both EDP and CA failed. 6 Yes, 30 No.
> > This motion (50) requires EDP but recommends CA.
> >
> > I think that many of the arguments already presented in motion 47 are relevant
> > even if CA is merely recommended. I repeat just one of them.
> >
> > Regardless of the possible arguments for or against EDP as a computational tool,
> > adding a functionality which has neither interval inputs nor interval outputs and appears to require a data object (extended accumulator) not otherwise present in the standard, seems gratuitous in the context of an interval standard.
>
>
> On 2013 Sep 15, at 18:02, Vincent Lefevre wrote:
>
> > I vote NO on Motion P1788/M0050:EDP-Without-CA.
> >
> > Same reason as what Richard Fateman said.
> >
> > I also disagree on requiring a complex operation such as EDP while
> > simpler exact operations such as an exact sum or an exact product
> > of two numbers aren't even mentioned. Something like that is seen
> > nowhere in other standards. EDP and other exact operations have
> > their place only in their own standard.
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.
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.