Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Motion M0050:EDP-Without-CA



On 1 Oct 2013 at 12:29, Vincent Lefevre wrote:

Date sent:      	Tue, 1 Oct 2013 12:29:31 +0200
From:           	Vincent Lefevre <vincent@xxxxxxxxxx>
To:             	stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
Subject:        	Re: Motion M0050:EDP-Without-CA

> On 2013-10-01 12:54:21 +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.

> 
> While that's true that an EDP-data object can represent such a
> value exactly, you *don't need* such an object. P1788 already
> allows interval types with whatever precision you like and
> whatever representation you like, with greater benefit than
> EDP-data objects: the operations on an EDP-data objects are
> rather limited, while you have all the P1788 operations on
> interval types.

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? )

> 
> Moreover many applications don't need such a form specifically.
> So, the representation of such forms should be left to the
> implementation, just like it is the implementation that chooses
> the precision of interval types.
> 
> --