| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
P1788,
Motion M0030.02 Constructors was passed 41 - Yes to 3 - No. Here is my attempt to summarize the discussions.
Begin forwarded message:
> From: Dmitry Nadezhin <dmitry.nadezhin@xxxxxxxxxx>
> Subject: Re: Motion P1788/M0030.02:Level_1_constructors -- voting period begins - YES
> Date: March 27, 2012 9:37:38 PM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote YES, because I agree that nums2interval(u,v) should be undefined when u > v
> and that num2interval(x) is not safe.
>
> However, after the end of the voting period of this motion I would like to query
> an opinion of the working group about mentioning int2interval(x) constructor in the standard.
> Perhaps it will be another motion.
>
> -Dima
Begin forwarded message:
> From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> Subject: Motion M0030 and M0031: YES and NO
> Date: March 30, 2012 9:15:39 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
>
> I vote YES on Motion M0030 Level 1 Constructors because invalid construction
> should be treated as undefined operation. However my support is provisional,
> since the motion as currently written is incompatible with a standard for
> Kaucher/modal intervals.
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: I vote YES on Motion P1788/M0030.02:Level_1_constructors
> Date: April 2, 2012 8:55:23 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote YES on Motion P1788/M0030.02:Level_1_constructors.
>
> However it seems to be contradictory:
>
> The following Level 1 decorated interval constructors are defined,
> which shall have Level 2 versions as specified in <<suitable place
> in Clause 6>>.
>
> and
>
> The decorated interval constructors are defined in terms of the
> following bare interval constructors, which are "virtual" since
> they have no Level 2 counterparts in the standard.
>
> So, will there be Level 2 versions of the bare interval constructors?
> Anyway, since this motion is about Level 1, this doesn't affect my
> vote here.
>
> --
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Begin forwarded message:
> From: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Subject: I vote NO on Motion P1788/M0030.02:Level_1_constructors
> Date: March 28, 2012 12:34:28 AM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
> Cc: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Reply-To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
>
> Folks,
>
> This motion defines nums2bareinterval, text2bareinterval,
> bareempty, & bareentire in some detail & then goes on to
> define decorated constructors as something of an
> afterthought.
>
> It is my opinion that bare intervals will be of great
> utility to optimizing compilers to reduce both storage &
> computation for those applications that can PROVABLY do
> without decorations. But I believe it will turn out to
> be poor programming practice for users to create bare
> intervals on their own.
>
> Of course, it must be possible for users to do this. So
> we must provide something like a makeBare. But to provide
> a complete set of operations supporting bare intervals as
> a first class datatype makes us complicit in that poor
> programming practice.
>
> For when the rocket blows up due to some decoration being
> ignored, finding
>
> xx = makeBare(nums2interval(a,b));
>
> in the code makes it the programmer's fault. Finding
>
> xx = nums2bareinterval(a,b);
>
> makes it our fault.
>
> And, as I would rather not be named in a $1 billion lawsuit,
> I vote NO on this motion.
>
> I would vote yes if the bare versions of these constructors
> were removed.
>
>
> Dan
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Re: I vote NO on Motion P1788/M0030.02:Level_1_constructors
> Date: March 28, 2012 7:13:13 AM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
>
> First I'm a bit lost. Has voting officially started on this motion?
>
> On 2012-03-27 22:34:28 -0700, Dan Zuras Intervals wrote:
>> Folks,
>>
>> This motion defines nums2bareinterval, text2bareinterval,
>> bareempty, & bareentire in some detail & then goes on to
>> define decorated constructors as something of an
>> afterthought.
>
> at Level 1.
>
>> It is my opinion that bare intervals will be of great
>> utility to optimizing compilers to reduce both storage &
>> computation for those applications that can PROVABLY do
>> without decorations. But I believe it will turn out to
>> be poor programming practice for users to create bare
>> intervals on their own.
>
> I agree, but the motion is about Level 1 (not available to
> programmers) and it says:
>
> The decorated interval constructors are defined in terms of the
> following bare interval constructors, which are "virtual" since
> they have no Level 2 counterparts in the standard.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> If I understand correctly, they won't exist at Level 2, i.e. for
> programmers.
>
> --
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Begin forwarded message:
> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> Subject: Re: I vote NO on Motion P1788/M0030.02:Level_1_constructors
> Date: April 11, 2012 4:26:40 AM CDT
> To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Dan and P1788
>
> On 28 Mar 2012, at 06:34, Dan Zuras Intervals wrote:
>> This motion defines nums2bareinterval, text2bareinterval,
>> bareempty, & bareentire in some detail & then goes on to
>> define decorated constructors as something of an
>> afterthought.
>>
>> It is my opinion that bare intervals will be of great
>> utility to optimizing compilers to reduce both storage &
>> computation for those applications that can PROVABLY do
>> without decorations. But I believe it will turn out to
>> be poor programming practice for users to create bare
>> intervals on their own.
>>
>> Of course, it must be possible for users to do this. So
>> we must provide something like a makeBare. But to provide
>> a complete set of operations supporting bare intervals as
>> a first class datatype makes us complicit in that poor
>> programming practice.
>>
>> For when the rocket blows up due to some decoration being
>> ignored, finding
>>
>> xx = makeBare(nums2interval(a,b));
>>
>> in the code makes it the programmer's fault. Finding
>>
>> xx = nums2bareinterval(a,b);
>>
>> makes it our fault.
>>
>> And, as I would rather not be named in a $1 billion lawsuit,
>> I vote NO on this motion.
>>
>> I would vote yes if the bare versions of these constructors
>> were removed.
>
> I agree with Dan's basic point that it is best if constructors always make decorated intervals, but either he is looking at different text from my motion, or he is misreading its intention. I copy it below plus note B of the mini-rationale.
>
> The ONLY reason why the motion doesn't define constructors of decorated intervals, explicitly, is that we haven't resolved the decoration impasse yet. The motion doesn't even explicitly say that the constructed interval is a bare one! Please regard this as sort of "virtual" text to become concrete when a decoration system is fixed.
>
> I hope therefore that Dan will change his vote, if the "bare"ness is the only thing that concerns him.
>
> John Pryce
>
>> 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.
> (This constructor is now officially removed, by a friendly amendment.)
>
>>> 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.]
>>
>> -------------------------------------
>> ...
>> 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.
Begin forwarded message:
> From: Lee Winter <lee.j.i.winter@xxxxxxxxx>
> Subject: Re: P1788: PLEASE VOTE on Motions 30.02, 31.01, and 32.01
> Date: April 12, 2012 11:04:22 PM CDT
> To: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
> Cc: stds-1788 <STDS-1788@xxxxxxxxxxxxxxxxx>
>
> On Thu, Apr 12, 2012 at 8:30 AM, Corliss, George
> <george.corliss@xxxxxxxxxxxxx> wrote:
>> P1788,
>>
>> Voting is underway on three motions. Baker's calls for each are appended below.
>>
>> Motion M0030.02 Constructors
>> Current tally: Yes: 21; No: 1; Required for quorum: 31
>> Voting by rules for position papers
>> Voting closes Tuesday, April 17
>
> My vote is NO.
>
> Lee Winter
> Nashua, New Hampshire
> United States of America
Begin forwarded message:
> From: Frédéric Goualard <Frederic.Goualard@xxxxxxxxxxxxxx>
> Subject: Motion P1788/M0030.02 Constructors
> Date: April 16, 2012 3:33:35 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote NO on Motion 30.02 because of the presence of "NaI" in the
> text. I voted against that concept for Motion 7 and I am still opposed
> to it. I would change my vote to yes if the text specifically replaced
> the notion of NaI by "empty set with proper decoration".
>
> FG.
> - --
> Frйdйric Goualard LINA - UMR CNRS 6241
> Tel.: +33 2 76 64 50 12 Univ. of Nantes - Ecole des Mines de Nantes
> 2, rue de la Houssiniиre - BP 92208
> http://frederic.goualard.net/ F-44322 NANTES CEDEX 3
>
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Re: Motion P1788/M0030.02 Constructors
> Date: April 16, 2012 10:01:09 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> On 2012-04-16 10:33:35 +0200, Frédéric Goualard wrote:
>> I vote NO on Motion 30.02 because of the presence of "NaI" in the
>> text. I voted against that concept for Motion 7 and I am still opposed
>> to it. I would change my vote to yes if the text specifically replaced
>> the notion of NaI by "empty set with proper decoration".
>
> Though I voted YES on Motion 30.02, I completely agree with Frédéric,
> meaning that I will vote NO on any NaI definition if it is not the
> empty set. But I don't think this will happen, and that's why I didn't
> feel the need to reject this motion for this purpose.
>
> --
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Begin forwarded message:
> From: Ulrich Kulisch <Ulrich.Kulisch@xxxxxxxxxxx>
> Subject: Motion 30.02
> Date: April 16, 2012 10:12:13 AM CDT
> To: IEEEP1788a <stds-1788@xxxxxxxx>
>
> I vote Yes on Motion 30.02.
>
> However, I agree with Frédéric Goualard that "NaI" should not be used in the text.
>
> Ulrich Kulisch
>
Begin forwarded message:
> From: Michel Hack <mhack@xxxxxxx>
> Subject: Motion P1788/M0031.01:Level_1_text -- YES
> Date: April 16, 2012 12:56:01 PM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote YES on Motion P1788/M0030.01:Level_1_text.
>
> I do so because I believe the kinds of correction that I will suggest
> do not detract from the intrinsic value of the work that has been put
> into this motion. In fact, I only offer one:
>
> change "powr" to "powq" for the 3-argument rational-power function.
>
> (This was mentioned already).
>
> I also agree with Vincent's recommendations for stylistic improvement.
>
> I'm less sympathetic to Vincent's request to define inf(Empty) and
> sup(Empty) as suggested by Dan Zuras' "Table 4 proposal version 0.2"
> (namely +oo and -oo, respectively). Dan's argument is actually pretty
> strong for these, but the same proposal included the early attempts
> to define midpoint, and we're still having trouble with that. So I'm
> comfortable with leaving a couple of numeric Level 1 functions Undefined
> for Empty or Unbounded intervals. Level 2 will supply the appropriate
> definitions.
>
> Michel.
Begin forwarded message:
> From: Dmitry Nadezhin <dmitry.nadezhin@xxxxxxxxxx>
> Subject: int2interval, frac2interval, rat2interval
> Date: April 18, 2012 10:11:14 PM CDT
> To: <STDS-1788@xxxxxxxxxxxxxxxxx>
>
> Previously, I noticed that we forgot about constructors like int2rational.
> It was too late and I didn't want to disturb voting of motions M030.02 and M031.01 .
> Now they passed and I want to prepare a motion(s) that add such constructors.
>
> -Dima
>
> -------------------
>
> 1) Add following items to section 3.2 Definitions of the Level 1 text approved by the motion 31.
>
> 3.2.999. integer. Any member of the set Z of integer numbers.
> 3.2.999. rational. Any member of the set Q of rational numbers.
>
> 2) Add following paragraphs to the constructor text approved by the motion 30.
>
> - The constructor int2bareinterval(i) is defined for an integer value i.
> Its value is the singleton interval [i,i] = { i }.
>
> - The constructor frac2bareinterval(p,q) is defined for a pair of integer values (p,q) with q > 0.
> Its value is the singleton interval [p/q,p/q] = { p/q }.
>
> 3) Add a phrase to 5.7 (Recommended operations(informative)).
>
> - The recommended constructor rat2bareinterval(r) is defined for a rational value r.
> Its value is the singleton interval [r,r] = { r } .
>
> 4) Add new constructors to the list in the last paragraph o fthe constructor text.
>
> The decorated interval constructors nums2interval(l,u), int2interval(i), frac2interval(p,q), rat2interval(r), text2interval(t), empty(), entire() are defined as follows....
>
> ------------------
>
> Rationale .
>
> User may need to write an expression with precoomputed rational number like
> (1/n!)*x^n .
>
> User could compute interval extendsion of 1/n! using mul/div interval operations,
> but this accumulates rounding errors for large n.
>
> Underlying system may have types that implement integers or rationals that
> can't be represented by default number format (like double):
> - "long long int" types; with larger precision than precision of default number format (double).
> - arbitrary size integers like GMP "mpz", or Java "BigInteger".
> - arbitrary size rationals like GMP "mpq";
> User could compute exact rational number 1/n! using above type, then convert it to text, then use text2interval constructor,
> but text2interval doesn't define details of text representation, so this may be not portable.
>
> So it is desirable to have Level 1 operations that convert rational numbers to intervals.
>
> The corresponding Level 2 constructors will return the hull of Level 1 singleton interval.
> The hull may become non-sigleton for some inputs, but it will not suffer from double-rounding.
>
> ---------------------
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Re: int2interval, frac2interval, rat2interval
> Date: April 19, 2012 3:38:00 AM CDT
> To: <STDS-1788@xxxxxxxxxxxxxxxxx>
>
> On 2012-04-18 20:11:14 -0700, Dmitry Nadezhin wrote:
>> 1) Add following items to section 3.2 Definitions of the Level 1
>> text approved by the motion 31.
>>
>> 3.2.999. integer. Any member of the set Z of integer numbers.
>> 3.2.999. rational. Any member of the set Q of rational numbers.
>>
>> 2) Add following paragraphs to the constructor text approved by the
>> motion 30.
>>
>> - The constructor int2bareinterval(i) is defined for an integer value i.
>> Its value is the singleton interval [i,i] = { i }.
>
> This is not Level 2 yet, but I suppose that what is an integer will be
> language-defined. I mean, it can come from an integer type or from some
> floating-point number (if it happens to be an integer) if the language
> doesn't have a specific integer type.
>
>> - The constructor frac2bareinterval(p,q) is defined for a pair of
>> integer values (p,q) with q > 0.
>> Its value is the singleton interval [p/q,p/q] = { p/q }.
>
> Why the restriction to q > 0? IMHO, it would be safer to allow
> any q <> 0.
>
> [...]
>
> --
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Begin forwarded message:
> From: Alan Eliasen <eliasen@xxxxxxxxxxxxxx>
> Subject: Motion P1788/M0031:Constructors NO
> Date: April 17, 2012 6:20:26 PM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote NO on this proposal. In order for me to vote YES, the motion
> would need be changed to provide clearly defined behavior in several cases:
>
> * When the conditions for nums2bareinterval(l,u) are not correctly
> specified.
>
> * When the string passed to test2bareinterval(t) is not accepted.
>
> The standards must give defined behaviors in these cases.
>
> I am also reticent to approve use of NaI unless better mechanisms are
> impossible to use (e.g. constructors that throw exceptions, which will
> never cause "invalid" intervals to be constructed, which eliminates the
> need to check for NaI everywhere else in code, which is a potentially
> large savings in code complexity and performance.)
>
> --
> Alan Eliasen
> eliasen@xxxxxxxxxxxxxx
> http://futureboy.us/
Begin forwarded message:
> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> Subject: Re: Motion P1788/M0030:Constructors NO (was M0031...)
> Date: May 1, 2012 9:12:33 AM CDT
> To: Alan Eliasen <eliasen@xxxxxxxxxxxxxx>
> Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Alan, and P1788
>
> On 18 Apr 2012, at 00:20, Alan Eliasen wrote:
>> I vote NO on this proposal. In order for me to vote YES, the motion
>> would need be changed to provide clearly defined behavior in several cases:
>
> I'm assuming this is about about Motion 30, despite the subject line.
>
>> * When the conditions for nums2bareinterval(l,u) are not correctly
>> specified.
>>
>> * When the string passed to test2bareinterval(t) is not accepted.
>>
>> The standards must give defined behaviors in these cases.
>
> The motion text uses the phrase "... it is undefined" twice in specifying these. Someone (I've mislaid the email) recently pointed out that "undefined" has two clashing meanings:
> (a) a mathematical meaning: "the function returns no value for this input",
> (b) a standardese meaning: "no behavior is specified, so implementers can do what they like".
>
> I wish to make clear that (a) is meant. The behavior is specified, and it is "there is no value". So I aim to change the Level 1 text to make this clear, probably by changing "undefined" to "no value" where appropriate and adjusting the grammar as required. And add an item "no value" to the Definitions.
>
> My idea is that returning "no value" at Level 1 should by default imply returning NaN at Level 2 for a numeric return-type, and a suitably decorated interval result (that I persist in thinking of as NaI though there may be several kinds of it) for an interval return-type. "By default" means that any other behavior must be decided explicitly by the group, by passing a motion.
>
>> I am also reticent to approve use of NaI unless better mechanisms are
>> impossible to use (e.g. constructors that throw exceptions, which will
>> never cause "invalid" intervals to be constructed, which eliminates the
>> need to check for NaI everywhere else in code, which is a potentially
>> large savings in code complexity and performance.)
>
>
> I find such arguments puzzling. If floating point standardizers had followed them they would never have invented NaN, whose benefits, despite Dan Zuras' criticisms, far outweigh its disadvantages IMO. We should be envisaging hardware, not software, implementations of the five basic interval operations (at least) -- for which "checking for NaI" carries negligible overhead. But there are wiser people than I to argue the pros and cons of this.
>
> Regards
>
> John Pryce
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail