Re: dependent and independent intervals, proposal to toss out text2interval. Was re: about emp (was: Motion 42:no)

[Ian McIntosh <ianm@xxxxxxxxxx>]

I assumed one would convert the whole thing with round to negative infinity for the lower bound, and to positive infinity for the upper bound.  An alternative is to convert 0.1 that way and add a predefined interval for pi.  Either way, the width of the result should not exceed 4 ULPs.

- Ian McIntosh          IBM Canada Lab         Compiler Back End Support and Development


Dan Zuras Intervals ---02/19/2013 04:40:58 PM---> Date: Tue, 19 Feb 2013 12:37:40 -0800 > From: Richard Fateman <fateman@xxxxxxxxxxxxxxxxx>

From:	Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
To:	Ian McIntosh/Toronto/IBM@IBMCA
Date:	02/19/2013 04:40 PM
Subject:	Re: dependent and independent intervals, proposal to toss out text2interval. Was re: about emp (was: Motion 42:no)

---

> Date: Tue, 19 Feb 2013 12:37:40 -0800
> From: Richard Fateman <fateman@xxxxxxxxxxxxxxxxx>
> To: "'stds-1788'" <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: dependent and independent intervals, proposal to toss out text2interval. Was re: about emp (was: Motion 42:no)
> 

		 Folks,

		 I have remained silent on this problem since it began.
		 (Actually, I am mostly listening to this list these days.)

		 But Richard has raised a point about decimal to binary conversion
		 that I'm not quite sure he is aware of.  Indeed, as the quotations
		 are a bit unclear, *I'M* not quite sure just who raised it.

		 In the past, I have considered problems such as the conversion of
		 expressions like "0.1 + pi" or "0.1 + 3.141" as being the conversion
		 of strings to intervals followed by an interval add.

		 Now lets ignore the interval add on the grounds that we all know
		 how its done.  But what about the string conversion?  Again, in the
		 past, I have always considered it a problem of generalizing the
		 floating-point string conversion to intervals.

		 In the floating-point conversion, one converts the entire string
		 to the form m*10^e or m/10^e, exactly if possible, & does the
		 floating-point operation on those (mostly) exact floating-point
		 operands.  For interval conversion, I would generalize to something
		 like [m-1,m+1]*[10^e-ulp,10^e+ulp] which is already widening the
		 result quite enough to cover the original decimal operand.

		 However, given the way it is written, 0.1 + 3.141, such a formula
		 must be converted to something equivalent to an interval like
		 [0,0.2] + [3.140,3.142] = [3.140,3.342] which is quite a bit wider
		 than I believe the user expects.  *I*, as a user, would expect
		 something like 0.10000000000 + 3.14100000000 to be the result.

		 This has 2 problems.  If you don't do it then the user is left
		 with far wider intervals than I believe are reasonable.  And if
		 you do, the result of 0.10000000000 + 3.14100000000 will not
		 contain the answer to 0.1 + pi.

		 Which is it to be?  We can justify the first even if the user
		 cannot.  I don't believe we can justify the latter.

		 But its up to you...


		 		 		 		 		 Dan


> 
> On 2/19/2013 2:00 AM, Guillaume Melquiond wrote:
> .... snip,   , expressions meaning what they say...
> 
> I think that whatever advantage can be gained by  allowing an implementation
> to process string expressions like "0.1 + pi" is more than overcome by 
> . . .
> 
> If we are allowed to be slightly sloppy, by about half a unit in the 
> last place, we can take
> the closest binary approximation for 0.1d0 and widen it by one ulp up 
> and down, and enclose
> it.  It turns out that for careful decimal-to-binary conversion, this 
> interval will
> also enclose the mathematical  value of 1/10 as well.
> 
> If we want to get the _tightest_ interval some work is required but I'm 
> not sure which of several
> approaches is simplest.
> 
> One way is to form an interval  [1.0d0,1.0d0]  and divide by the scalar 
> 10.0d0. If proper IEEE-754
> directed rounding is available, we are done.
> 
> Any decimal constant, say 3.141, could be done by 
> scalar_to_interval(3141d0)/10^3.
> 
> (I believe that directed rounding here can  be cheaply simulated by 
> default rounding-to-nearest
> by bumping 3141  up and down before division.  for example, to get the 
> tightest enclosure
> around 1/3, in double-float binary, let eps =  double-float-epsilon = 
> 2.0d0^-53= 1.11022...d-16;
>   then create an interval   [ 3141*(1-eps), 3141*(1+eps)]  and then 
> divide, default rounding,
> by 10.
> )
> 
> Another more elaborate way is to make available tight intervals around 
> 1/10, 1/100, etc.
> 
> . . .
> 
> 
> Richard Fateman
>