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

P1788: PLEASE VOTE: Motion 0037.01:MidAndRadSpecs



P1788,

Voting on Motion 0037.01 Mid and Rad Specifications is in progress through Monday, November 12

Current tally: Yes: 14; No: 0; Needed for quorum: 25

PLEASE VOTE.

George Corliss, P1788 Voting Tabulator
George.Corliss@xxxxxxxxxxxxx



Begin forwarded message:

> From: Ralph Baker Kearfott <rbk@xxxxxxxxxxxx>
> Subject: Motion P1788/M0037.01:MidAndRadSpecs: voting period restarted (unless objection)
> Date: October 22, 2012 6:45:43 AM CDT
> To: John Pryce <j.d.pryce@xxxxxxxxxx>
> Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>, Ralph Baker Kearfott <rbk@xxxxxxxxxxxxx>
> Reply-To: <rbk@xxxxxxxxxxxxx>
> 
> P-1788:
> 
> Unless I receive objections, let us amend the motion to read Rad(Empty) = NaN,

GC: and mid(Empty) = NaN

> and immediately re-start the voting.  The new voting period will end after
> Monday, November 12.  I append the amended motion.  (Those few
> who have already voted, please re-post a vote to the amended motion.)
> 
> Juergen: Please update the web page with this information.
> 
> Best regards,
> 
> Baker
> -----------------------------------------------------------------------------
> This motion about midpoint and radius is based on the
> discussions during our 2012 annual meeting at SCAN'2012,
> specifically on the idea proposed by Siegfried Rump:
> *******************************************************
> Definition of the _midpoint_ of an interval [a,b]:
> 
> * we compute the mathematical midpoint
> (a + b) / 2 in the extended real line (whenever it is
> possible), and then take a finite computer representable
> floating point number which is the closest to this mathematical
> midpoint; if there are two closest numbers, we use rounding to
> even, i.e., select the one whose binary expansion ends in 0
> 
> * the only interval for which the mathematical midpoint is not
> defined is the interval (-oo, +oo); for this interval, natural
> symmetry prompts us to define the midpoint as 0;
> 
> 
> Examples:
> 
> * for an interval [a, +oo) with finite a, the midpoint is the
> number closest to +oo, i.e., MAXREAL
> 
> * for an interval (-oo, a) with finite a, the midpoint is the
> number closest to -oo, i.e., -MAXREAL
> 
> * for an interval [1, 1 + u], where 1 + u is the number closest
> to 1, the mathematical midpoint is 1 + (u / 2), so the closest
> numbers are 1 and 1 + u; rounding to even results in 1 being
> the desired midpoint
> 
> * mid(Empty) is defined to be NaN.
> 
> Please note that a midpoint is, in general, different from a
> bisection point used to bisect an interval in different
> interval algorithms
> ************************************************************
> For any interval [a, b], once its midpoint m is defined, we can
> define its _radius_ r as the smallest computer representable
> floating point number (finite or infinite) for which the
> interval [m - r, m + r] contains the original interval [a, b].
> 
> Examples:
> 
> * for the interval [1, 1 + u], the radius is u
> 
> * for the intervals [a, + oo) and (-oo, a), the radius is oo;
> this example shows the need for using an infinite number.
> 
> * rad(Empty) is defined to be NaN.
> 
> 
> -----------------------------------------------------------------------------
> 
> On 10/22/2012 06:13 AM, John Pryce wrote:
>> Baker
>> 
>> It looks as though there is a consensus, will you state the revised motion and let voting proceed?
>> 
>> On 21 Oct 2012, at 23:56, Kreinovich, Vladik wrote:
>>> Rad(Empty) = NaN is good too, let us go with Michel's suggestion
>> 
>> I have another query, though it is about wid() so it doesn't affect this motion.
>> 
>> I thought that with the revised definition that (for nonempty xx = [xlo,xhi])
>>      wid_F(xx) = smallest F-number >= xhi-xlo
>> one would always have
>> (*)  wid_F(xx) <= 2*rad_F(xx).
>> But this is not so as shown by the example xx = [-.001,1.00] where F is 3-digit decimal. It gives rad=0.501, wid=1.01.
>> 
>> So though always wid=2*rad in exact arithmetic, both < and > can happen in finite precision.
>> 
>> Are we happy with this, or should we, say, adjust the definition of rad_F so that (*) always holds?
>> 
>> John Pryce
>> 
> 
> 
> -- 
> 
> ---------------------------------------------------------------
> Ralph Baker Kearfott,   rbk@xxxxxxxxxxxxx   (337) 482-5346 (fax)
> (337) 482-5270 (work)                     (337) 993-1827 (home)
> URL: http://interval.louisiana.edu/kearfott.html
> Department of Mathematics, University of Louisiana at Lafayette
> (Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
> Box 4-1010, Lafayette, LA 70504-1010, USA
> ---------------------------------------------------------------