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

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
>