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

Re: Motion P1788/M0014.01: 6.1_and_6.2_of_document: up for discussion



Folks

Dan has raised a point that worried me when I wrote the text in question. I did send a query round at the time but don't recall anyone answering.

On 22 Apr 2010, at 11:43, Dan Zuras Intervals wrote:
> 	One subtle point that is not made clear by this is that
> 	it requires that a representation of the form (mid,del1,
> 	del2) which represents the interval [mid+del1,mid+del2]
> 	must do so exactly.  That is lowerBound = mid + del1 &
> 	upperBound = mid + del2 EXACTLY, with no rounding errors.
> 
> 	This is not so much of a problem but it does mean that
> 	any system choosing to use this mid-rad form in an
> 	attempt to speed things up in the |rad| << |mid| case
> 	must find some other way of representing semi-infinite
> 	intervals such as [2,+oo] & [3,+oo] which don't fit in
> 	this format.

PLEASE, Multi-precision interval computation folk:

(a) What does "FP Format" and corresponding "Interval Format" MEAN 
  in your context?
  Is there a potentially infinite sequence of them, like "binary_N" 
  where N is an arbitrary multiple of 32, say?
  Or just ONE, the union of all these (regarding each one as a 
  subset of the extended reals)?
(b) If your implementation uses something like (mid,del1,del2) 
  does it achieve what Dan says:
>  lowerBound = mid + del1 & upperBound = mid + del2 EXACTLY ?
  The answer almost surely depends on the answer to (a).

Basically I'm asking whether you can map what 6.1, 6.2 say into what you implement
- easily
- in a tortured and unnatural way
- not at all.

This didn't matter so much until this motion, but now it does. Probably a lot.

John