Motion M00014.01 FAILS
P 1788,
Motion M00014.01 6.1_and_6.2_of_document FAILS
33 - Yes; 7 - No; Required to pass: 2/3 of 71 Voting Members
Personal opinion
Also pending discussions:
M0016.01 InfSupAndMidRad - Discussion ends 2010-06-04
M0017.01 IO - Discussion ends 2010-06-05
M0018.01 Trits To Tetrits - Discussion ends 2010-06-16
Below, I append comments received. The intent is that by collecting all comments together, we may address at least some of them to arrive at a stronger standard.
Personal opinion: Six Voting Members have never voted on ANY motion, and several others who have voted rarely. Our Policies and Procedures specify that Voting Members not voting on two consecutive motions of standard wording (of which Motion 14.01 is our first) are automatically removed from the roster of Voting Members. They are reinstated immediately on request.
If we shortly re-introduce Motion 14 (possibly with revisions), it may not pass on the second attempt, but we will prune the list, and it MIGHT pass on a third attempt. If you are offended that I suggest manipulating the process, using the rules to advantage, I encourage you to VOTE on subsequent motions! The legislature/parliament/congress of my country is far more flagrant than that at using the rules strategically, and I suspect yours is, too.
George Corliss,
Voting Tabulator
From: Dominique Lohez <dominique.lohez@xxxxxxx>
Date: May 31, 2010 4:59:29 AM CDT
To: <stds-1788@xxxxxxxxxxxxxxxxx>, "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
Subject: P1788/M0014.01: NO
My vote is NO
My vote would be YES if the sentence
The empty set may be represented by (NaN, NaN)
were removed
Rationales
1) There is no general agreement on that statement
2) There are conceptual ( Level 1 reasons ) to reject such a statement
From: Frédéric Goualard <Frederic.Goualard@xxxxxxxxxxxxxx>
Date: May 31, 2010 6:53:17 AM CDT
To: stds-1788 IEEE <stds-1788@xxxxxxxx>
Subject: Motion P1788/M0014.01 NO
Hash: SHA1
Dear all,
On second thought, I agree with Dr. Lohez's remark about the
representation of the empty set, even though I do not see any
alternative at the moment.
As a consequence, I change my vote to NO with the same condition on my
voting YES as Dr Lohez.
From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
Date: May 31, 2010 7:59:09 AM CDT
To: P1788 <stds-1788@xxxxxxxxxxxxxxxxx>
Subject: Re: P1788/M0014.01: NO
All
Now that two people have objected to the sentence "The empty set may be represented by (NaN, NaN)", I feel I should say I am perfectly happy to remove it if many people favour that.
However, as I wrote to Dominique,
But that's only in a Note, so it's not normative. And it even says "may be represented", not "is represented". Aren't you being a bit strict?
John Pryce
From: Ian McIntosh <ianm@xxxxxxxxxx>
Date: May 31, 2010 9:40:30 AM CDT
To: <stds-1788@xxxxxxxxxxxxxxxxx>
Subject: Motion P1788/M0014.01: 6.1_and_6.2_of_document: NO
I vote NO on motion 14. I would vote yes if:
1. The empty set representation was defined.
It's necessary for a receiver can know when a set is empty.
2. The empty set representation is some form other than (NaN, NaN).
Implementing this using 754 hardware is too expensive. A special case like empty should be detectable by a single compare and branch, and that is not possible with NaN.
Also, "NaN" does not specify whether it is Quiet or Signaling, and other parts of the text allow Signaling. Doing a standard compare on a Signaling NaN raises an Invalid exception, and on most systems if exceptions are enabled that will trap. Other ways of checking for a Signaling NaN are too expensive.
Since we have not imposed the requirement that the floating point representation be IEEE 754, we shouldn't do it by the back door by requiring the use of NaN. (Yes, I've argued allowing (-oo, +oo) and will continue to. There's a difference between allowing and requiring. Maybe the intent of the motion was to allow not require NaN, but if "When x is the empty set, x and x are taken as NaN. Whether qNaN or sNaN is used, and any payload, ar!
e implementation-defined." isn't intended to require the use of NaN, it needs to be reworded.
3. The requirement that 0 be represented as +0 be removed.
There's no need for this, and it forces unnecessary overhead. That overhead is not just when the data will be interchanged - often that is unknown when it is calculated, so the overhead will almost always occur for no benefit. Whether the sign of a zero can convey information relevant to intervals isn't the issue - imposing unnecessary costs is.
4. The Decimal description is improved.
Eg, does the requirement that 0 be represented as +0 and making the choice of which cohort of a value be implementation defined mean that all but one of the many precisions of zero (0., 0.0, 0.00, etc) are prohibited? Which one would be allowed?
I think the intent is likely right, but the wording needs clarification.
- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development
From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
Date: May 31, 2010 9:57:44 AM CDT
To: Ian McIntosh <ianm@xxxxxxxxxx>
Cc: <stds-1788@xxxxxxxxxxxxxxxxx>
Subject: Re: Motion P1788/M0014.01: 6.1_and_6.2_of_document: NO
Ian
We are voting on 6.1 and 6.2.
Your comments relate to 6.3 which is about interchange format and is not the subject of this motion. Yes, your points are serious and worth discussing, and it is time we had this discussion, but that is for another day.
From: Michel Hack <hack@xxxxxxxxxxxxxx>
Date: May 31, 2010 12:21:58 PM CDT
To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
Subject: Ian's comments on P1788-MAIN 6.3 (*not* M0014)
Ian McIntosh wrote:
1. The empty set representation was defined.:
It's necessary for a receiver can know when a set is empty.
It's only necessary for the *interchange* format. Programs would use
the isEmpty() operation to determine the case.
3. The requirement that 0 be represented as +0 be removed.
Again, this does not affect internal representations. Whether
it is important to have a canonical representation of zero for
interchange formats is worthy of discussion. In my opinion it
is not essential (unlike the situation for encoding Empty), but
it might be useful because it would permit bit-level equality
testing at the interchange level.
This includes the case of the many many decimal zeros -- as well
as the choice of a canonical cohort (above and beyond canonical
representation thereof*). A logical canonical cohort would be
the one with the smallest exponent (i.e. normalized), though that
may feel unnatural for integral bounds. It would however lead to
a zero that looks like a zero (all bits zero), which is good.
Michel.
(*) IEEE 754-2008 requires that computational operations produce
canonical results, but appears to be silent on whether it is
conforming to export non-canonical interchange representations.
Since all operations must accept non-canonical representations
on input, my guess is that non-canonical forms ARE permitted.
P1788 might want to be more strict -- but would we want to pay
the cost of verifying canonicity? And if we don't enforce the
constraint, should there be one? Note that the only way for a
non-canonical output to appear is if it is a non-canonical input
that was propagated without ever participating in arithmetic, or
even min/max filtering.
From: Gabriel Dos Reis <gdr@xxxxxxxxxxxxxxxxxxxxxxxx>
Date: June 1, 2010 5:48:28 PM CDT
To: John Pryce <j.d.pryce@xxxxxxxxxxxx>
Cc: P1788 <stds-1788@xxxxxxxxxxxxxxxxx>
Subject: Re: P1788/M0014.01: NO
On Mon, May 31, 2010 at 7:59 AM, John Pryce <j.d.pryce@xxxxxxxxxxxx> wrote:
All
Now that two people have objected to the sentence "The empty set may be represented by (NaN, NaN)", I feel I should say I am perfectly happy to remove it if many people favour that.
However, as I wrote to Dominique,
But that's only in a Note, so it's not normative. And it even says "may be represented", not "is represented".
that is more reason to remove it.
Aren't you being a bit strict?
I would suggest we don't put statements in the standard we know are controversial, even if it is just a "note". You would be surprised by what people gather from "notes" :-)
-- Gaby
From: "G. William (Bill) Walster" <bill@xxxxxxxxxxx>
Date: June 1, 2010 12:29:31 PM CDT
To: <stds-1788@xxxxxxxxxxxxxxxxx>
Subject: Re: P1788/M0014.01: NO
My vote is NO.
The internal representation of intervals is a quality of implementation issue, which should be left up to implementers. The one and only requirement in any interval standard should be containment. Everything else is a quality of implementation issue.
From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
Date: June 2, 2010 2:16:46 PM CDT
To: P-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
Subject: P1788/M0014.01: NO
I vote no.
I am concerned the current wording is too restrictive and may unnecessarily
limit the adoption or acceptance of 1788 into environments that would
otherwise be conforming.
Exact inf-sup, mid-rad, or mid-rad1-rad2 representations in the various
interchange formats (ala Motion 16) I can see is useful. But I think the
standard should otherwise be silent on the internal format used by an
implementation, except that inclusion isotonicity must be preserved. This
gives the widest latitude to implementers for innovation.
Nate Hayes
Sunfish Studio, LLC
From: "Hanek, Bob" <bob.hanek@xxxxxxxxx>
Date: June 3, 2010 9:40:36 AM CDT
To: "stds-1788@xxxxxxxx" <stds-1788@xxxxxxxx>
Subject: P1788/M0014.01: NO
I vote NO.
My reasons have be adequately expressed by previous ‘no’ votes.
From: Svetoslav Markov <smarkov@xxxxxxxxxx>
Date: June 3, 2010 12:23:28 AM CDT
To: P-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
Subject: P1788/M0014.01: NO
I vote no by reasons similar to those pointed out by Nate Hayes and Bill Walster. In particular, I do not find it reasonable that an implementor who decided for mid-rad internal presentation should be forced to implement internaly the inf-sup form as well.
S Markov
From: Alan Eliasen <eliasen@xxxxxxxxxxxxxx>
Date: June 3, 2010 9:44:55 PM CDT
To: "stds-1788@xxxxxxxx" <stds-1788@xxxxxxxx>
Subject: Re: P1788/M0014.01: NO
My vote is NO.
The wording of section 6.1 is unclear, and makes requirements that
are not properly defined, and not possible to implement.
For example, it requires that "it shall be possible to retrieve the
bounds of x exactly." The implications of the word "exactly" here is
ambiguous and perhaps impossible. For example, the interval
implementation in my programming language "Frink"* can use a rational
number to represent the infimum or supremum of an interval. It may also
use arbitrary-precision floating-point numbers or arbitrary-size
integers, or, soon, even transcendental numbers represented
symbolically. (e.g. the exact expression sqrt[2]). This is necessary for
getting the sharpest possible bounds, such as when storing the exact
rational value 1/3, or even 1/10, neither of which can be represented
exactly in common binary representations, including IEEE-754! (Frink
*can* exactly represent the number 0.1 also.)
Thus, only if the receiver of the function can handle exact rational
numbers can I fulfil the requirements of section 6.1 to return my bounds
"exactly," *even though my internal representation may be sharper and
more exact.* A very good, sharp implementation probably can't fulfil
the requirements of this section because if the receiver requests my
bounds, I probably cannot return them "exactly" as required by this
section, but must potentially coerce and round them into some sort of
less-accurate interchange format, like IEEE-754, or something with
finite precision, losing precision in the process, and failing to comply
with the requirements of section 6.1.
It's unclear what was intended by this section as written, other than
to be a lead-up to defining an interchange format. It will fail to be
able to do this as written. The conflicting goals of allowing any
implementation but then requiring that the bounds that this arbitrary
implementation stores have to be retrieved "exactly" are apparently
impossible to reconcile. This motion needs another attempt to be possible.
To see if the next version of this motion succeeds better, here are
some tests. See if it's possible to meet the criteria if your
implementation stores exact rational numbers like 1/3 or 1/10,
arbitrary-size integers, arbitrary-precision floating-point numbers, or
exact symbolic constants like sin[1].
In addition, for the next pass, I would strike the entire section of
6.1 that begins with "This is captured by the following definition" and
deleting to the end of 6.1. This section on concrete interval format
unnecessarily confuses the issue, as the "implementation may choose any
means" section allows any implementation, and randomly listing a couple
of them is not necessary.
* http://futureboy.us/frinkdocs/
--
Alan Eliasen
eliasen@xxxxxxxxxxxxxx
http://futureboy.us/
From: John Pryce <prycejd1@xxxxxxxxxxxxx>
Date: June 4, 2010 3:51:29 AM CDT
To: P1788 <stds-1788@xxxxxxxxxxxxxxxxx>
Subject: Re: P1788/M0014.01: NO
Alan
You are creating difficulties that simply are not there, IMO. I see two points to distinguish:
(a) Being 754-conforming means supporting 754 binary64 interval format, etc.
I assume 754 FP numbers are among the kinds of number Frink supports. If so, you can do it. If you don't, or prefer not to -- well then, be a conforming implementation of P1788 but not a 754-conforming one.
(b) You write
To see if the next version of this motion succeeds better, here are
some tests. See if it's possible to meet the criteria if your
implementation stores exact rational numbers like 1/3 or 1/10,
arbitrary-size integers, arbitrary-precision floating-point numbers, or
exact symbolic constants like sin[1].
An n-format is any subset F of R* containing +-oo. The numbers Frink supports, call them frinks, are such a subset. That defines an interval format such as P1788 requires. A nonempty interval xx in that format is represented at level 3 by an object holding a pair of frinks, the endpoints of xx. From that object the endpoints are retrieved exactly. Presumably Frink can work with such objects.
You're a lucky guy, you can represent and manipulate xx = [pi/3, sin(sqrt(2))] exactly in your system.
Where's the problem?
John
On 4 Jun 2010, at 03:44, Alan Eliasen wrote:
The wording of section 6.1 is unclear, and makes requirements that
are not properly defined, and not possible to implement.
From: Vincent Lefevre <vincent@xxxxxxxxxx>
Date: June 3, 2010 11:03:04 AM CDT
To: <stds-1788@xxxxxxxxxxxxxxxxx>
Subject: P1788/M0014.01 YES
My vote is YES on Motion 14.
I think that if other formats such as midrad need to be supported,
then Level 3 description should be made optional entirely (an
implementation would just provides means for interval interchange,
with a possibly inexact conversion).
--
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 / Arénaire project (LIP, ENS-Lyon)