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

Reply to Beebe...



	I meant to cc the entire group on this.  - Dan

To: "Nelson H. F. Beebe" <beebe@xxxxxxxxxxxxx>
Cc: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
From: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
Subject: Re: small correction to the Vienna Proposal 
Date: Mon, 23 Feb 2009 14:29:30 -0800

> Date: Mon, 23 Feb 2009 11:14:38 -0700 (MST)
> From: "Nelson H. F. Beebe" <beebe@xxxxxxxxxxxxx>
> To: "Chenyi Hu" <chu@xxxxxxx>
> Cc: beebe@xxxxxxxxxxxxx, "stds-1788" <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: small correction to the Vienna Proposal
> 
> Chenyi Hu writes today:
> 
> >> I'd prefer m = 0.5 * (l + u) rather than m = l + 0.5*(u - l) because of
> >> 
> >> 1. Avoiding the loss of significance in performing u-l for narrow intervals
> >> 2. One less arithmetic operation.
> 
> Chenyi's alternative suffers from premature overflow when l and u are
> greater than half the maximum representable number.  The proposed form
> l + 0.5*(u - l) is safe.

	The proposed form is mostly safe.  It is safe unless
	the interval in question is so wide that the radius
	(0.5*(u - l)) is representable but the diameter (u - l)
	is not.

	The form m = 0.5*l + 0.5*u, r = 0.5*u - 0.5*l would
	be safer still in that sense.  Failing only when the
	answer cannot legitimately be represented either by
	overflow (of the add/subtract) or underflow (of the
	multiplies).

	There are more operations for m but in the form:

			a = 0.5*u
			b = 0.5*l
			m = a + b
			r = a - b

	only 4 in total for both m & r.

> 
> . . .
> 
> Computation with finite range and precision is often subtle!

	It is indeed!

> 
> -----------------------------------------------------------------------------
> - Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -

	Enjoy,

				Dan