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

Re: Motion P1788/M0030.01:Level_1_constructors -- discussion period begins



Baker and all,

May we re-consider the closing date of Saturday, December 24, 2011?

I'd suggest closing discussion on Friday, January 6.

Yes, we should follow our Policies and Procedures.
Yes, there is plenty of time for comment before Dec. 24.  I hope people DO.
Yes, we can extend the deadline as it approaches.  If we are doing to extend, I favor doing so at the beginning.

However, the spirit of the IEEE guidelines is for free, full, and fair discussion.  For many academic folks, the next 2-3 weeks are the end of semester and final exam rush.  For many, including non-Christians, the last couple weeks of the calendar year offer a bit of down time.

What do others think?

George

On Dec 3, 2011, at 8:52 AM, Ralph Baker Kearfott wrote:

> P-1788:
> 
> Since Motion 30 has been made by John Pryce and
> seconded by Dan Zuras, the discussion period now
> begins, and will end after Saturday, December 24, 2011.
> I append the motion, along with a comment from John.
> 
> Discussion on this motion will proceed according to the rules for
> position papers.
> 
> Juergen:  Please place the motion and associated information
>           in the appropriate place on the web page, as
>           you have aptly done in the past.
> 
> Acting secretary:  Please record the transaction in the minutes.
> 
> As usual, please contact me if you need the password to the private
> area of the P-1788 web site.
> 
> Best regards,
> 
> Baker (acting as chair, P-1788)
> ---------------------------------------------------------------
> 
> [Here is] the following specification of *constructors*. It is
> very close to what the Vienna proposal has (except Vienna
> doesn't distinguish Level 1 from Level 2). Separately from the
> "acceptance as standard text" motion, I hereby submit an
> (ordinary) motion as below.
> 
> I have a query however. When a constructor call "fails", should
> the call
> 
> (a) return Empty, as currently written;
> 
> (b) return a "Not an Interval" value, which must then exist at
>    Level 1; or
> 
> (c) not return any value, i.e. the function is simply undefined
>    at this input argument?
> 
> E.g. text2interval("rubbish").
> 
> John Pryce
> 
> Motion
> ======================================================================
> The standard shall specify constructors at Level 1 as described below.
> ======================================================================
> 
> Proposed Level 1 text on Constructors
> -------------------------------------
> The following operations shall be provided, that create an
> interval from non-interval data.
> 
> The operation nums2interval(l,u), where l and u are
> extended-real values, returns the set {x in R | l <= x <= u}. If
> (see subclause 5.2) the conditions l <= u , l < +oo and u  -oo
> hold, this set is the nonempty interval [l,u] and the operation
> is said to succeed. Otherwise the operation is said to fail, and
> returns Empty.
> 
> Success and failure are used in specifying how decorations are
> set by the corresponding finite-precision operations on
> decorated intervals.
> 
> The operation num2interval(x) is equivalent to nums2interval(x,
> x). It fails if and only if x is infinite.
> 
> The operation text2interval(t) succeeds and returns the interval
> denoted by the text string t, if t denotes an interval.
> Otherwise, it fails and returns Empty.
> 
> [Note. Since Level 1 is mainly for human-human communication,
> any understandable t is acceptable, e.g. "[3.1,4.2]" or
> "[2\pi,\infty]”. Rules for the strings t accepted at an
> implementation level are given in the Level 2 Subclause 6.11 on
> I/O and may optionally be followed.]
> -------------------------------------
> 
> I won't give a Rationale, because the above seems
> self-explanatory, but it may help to say that in the Level 2
> text I aim to circulate shortly, the finite-precision
> constructors are specified roughly thus:
> 
> A. There shall be a version of each Level 1 constructor for each
>   supported or available interval type T, explicit or implicit,
>   and it shall return the T-interval hull of what the Level 1
>   constructor returns.
> 
> B. Until we have sorted out decorations I can't say whether
>   finite-precision constructors shall return a bare or a
>   decorated interval, or whether both kinds exist. I have
>   sympathy with Dan Zuras' view that only decorated interval
>   constructors should exist.
> 
> C. The Level 2 Subclause 6.11  referred to above describes "the
>   strings t accepted" thus:
> 
>   - Vienna section 6.2 square brackets form, like "[3.4e1,
>     5.6e1]", is required (to be accepted).
> 
>   - The strings "Empty" and "Entire" are required, also "empty"
>     etc.
> 
>   - Vienna 6.3 "Centered intervals", like "<2.3+-0.005", are
>     recommended.
> 
>   - Vienna 6.4 "Uncertain numbers", like "1.23_" and "1.2?e3",
>     are recommended.
> 
>   - Vienna 6.5 "Exact numbers", like "-5/7" and "0.71428" and
>     "Pi", are required.
> 
>   - Vienna 6.6 and 6.7 look excellent but I haven't a view on
>     them yet.
> 
> ---------------------------------------------------------------
> 
> 
> 
> 
> -- 
> 
> ---------------------------------------------------------------
> R. 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
> ---------------------------------------------------------------

George Corliss
George.Corliss@xxxxxxxxxxxxx