P1788: M0005.02_Table_of_operations is PASSED
P1788,
Motion 5 is PASSED by a vote of
43 Yes
8 No
of 71 registered Voting Members, a quorum of at least half the voting
members having been reached.
There are two additional Yes votes still under investigation (or whatever
other diplomatic term we should use for "We're still trying to sort things
out"), but they cannot alter the outcome.
The motion text is as follows:
===============================================================
I submit the document "Arithmetic operations for intervals" written
by Ulrich Kulisch as a formal motion (motion 5) to be voted upon.
The document gives the definition of the arithmetic operations for
intervals in a way that is simple to read, simple to understand, and
simple to implement. It is short and understandable and to the point.
It should be adopted as a basis for the future work of IEEE P1788.
The document is enclosed as a PDF document (4 pages) to facilitate its
reading.
===============================================================
VOTING ON MOTION 6 LEVEL 2 MULTI-FORMAT ENDS TOMORROW, 15 SEPTEMBER
Current tally:
Motion 6: 42 Yes, 3 No, of 71 Voting Members (Ends 15 Sept.)
Motion 7: 8 Yes, 12 No, of 71 Voting Members (Ends 15 Sept.)
Quorum is half the registered Voting Members.
A motion passes by majority of those voting.
PLEASE VOTE, if you have not done so.
Our Policies and Procedures permit voting more than once; only the LAST vote
counts. That way, you can change your mind if discussions during voting are
convincing.
Comments from people who voted NO on Motion 5:
Subject: Vote on Motion 5
Date: Wednesday, August 19, 2009 10:41 AM
From: Maarten van Emden <vanemden@xxxxxxxxxx>
To: <stds-1788@xxxxxxxxxxxxxxxxx>
Cc: <vanemden@xxxxxxxxx>
Conversation: Vote on Motion 5
My vote on Motion 5: NO
Inasmuch as
(1) section 3.11 of the Vienna proposal ("Vienna 3.11" from here
on) covers the same ground as the document proposed in Motion 5 and
is a small fraction of the size, and
(2) it is apparently considered time to vote on the content of
Vienna 3.11, my preferred version of Motion 5 is not to adopt the
document "Arithmetic operations for intervals" by Ulrich Kulisch
but instead to modify (for the need of this, see below) Vienna 3.11
as follows:
=========================================================
3.11 For each operation <circ> equal to +, *, min, max, and pow:
<circ>Hull(xx,yy,zz) = least floating-point interval containing the
set of z in zz such that
x <circ> y = z with x in xx and y in yy
<circ>Inv1(xx,yy,zz) = least floating-point interval containing the
set of z in zz such that
z <circ> y = x with x in xx and y in yy
<circ>Inv2(xx,yy,zz) = least floating-point interval containing the
set of z in zz such that
y <circ> z = x with x in xx and y in yy
The third argument of <circ>Hull, <circ>Inv1, and of <circ>Inv2 is
optional and is to be taken as Entire if absent.
If <circ> is commutative, then <circ>Inv1 and <circ>Inv2 are the same
and will be called <circ>Inv.
[There is no need to spell out in the standard the mathematical
proposition that translates the above specification into tables
with formulas for the end points.]
=========================================================
Notes:
Interval subtraction and division are obtained as inverses of +
and *. Thus this gives the interval versions of +, *, min, max, pow
as well as of their inverses (one of each except two in the case
of pow).
Rationale
---------
(0) To support the Vienna proposal as much as possible.
(1) See last, bracketed, paragraph of Vienna 3.11, of which I have
adopted the first sentence. This is useful in the context of Motion
5, and is to be discarded at the first opportunity.
(2) To ensure an unambiguous definition of interval division. Vienna
3.11 gives two definitions of interval division: one directly and
one as inverse of multiplication. These give different results for
[0,0]/[0,0], about which more below.
(3) Vienna 3.11 is not symmetric with respect to inverse operations.
As a result it needs qualifications, such as "defined" and "finite".
The above modification is symmetric and has no need of these
qualifications.
(4) The method of defining the inverse operations used here is
well-known and of long standing in the interval community, going
back at least as far as "On extended interval arithmetic and inclusion
isotonicity" by D. Ratz, Karlsruhe Technical Report, 1996.
(5) According to the above modification [0,0]/[0,0] is Entire, whereas
it is Empty according to the <circ>Hull definition of Vienna 3.11,
it is Entire according to the <circ>Inv1 and <circ>Inv2 definitions in
Vienna 3.11.
I have the followng argument for taking [0,0]/[0,0] to be Entire:
Consider the equation ax = b in x with a and b as real coefficients.
If a and b are uncertain reals with values in intervals aa and bb,
then the equation determines x to within the interval bb/aa.
According to what could be called the Correspondence Principle of
Interval Arithmetic, the interval bb/aa should revert to the possible
values for x in ax = b when aa = [a,a] and bb = [b,b]. Setting a = 0
and b = 0, ax = b leaves x indeterminate. The corresponding interval
bb/aa is (-oo, +oo). Ergo, [0,0]/[0,0] should equal Entire.
Subject: Motion P1788/M0005.02_Table_of_operations vote : NO
Date: Tuesday, September 1, 2009 7:17 AM
From: Dominique Lohez <dominique.lohez@xxxxxxx>
To: George Corliss <George.Corliss@xxxxxxxxxxxxx>
Cc: "R. Baker Kearfott" <rbk@xxxxxxxxxxxxx>, <rbk@xxxxxxxxxxxx>,
<stds-1788@xxxxxxxx>
Conversation: Motion P1788/M0005.02_Table_of_operations vote : NO
My vote is NO
I would vote YES if
1) In the denotation List of denotations
The reference to the empty set as an element of the
extended set of intervals is removed
2) In the division table for when 0 is an element of the
interval b
The second colun has the following content
header : The interval [0,0] is replaced
by any interval including 0
result: On must always be (-infinity,
+infinity)
Rationale
While the function f :R-> R f(x)=1/x is not defined for x =0 , and no
extension is possible
When working with intervals such extensions are possible leading to
the results indicated above
Dominique
Subject: Motion P1788/M0005.02_Table_of_operations NO
Date: Monday, September 7, 2009 1:49 AM
From: Frédéric Goualard <Frederic.Goualard@xxxxxxxxxxxxxx>
To: <stds-1788@xxxxxxxxxxxxxxxxx>
Conversation: Motion P1788/M0005.02_Table_of_operations NO
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I vote NO because:
I do not like the idea of providing "operational definitions" for
interval arithmetic. I would rather have "semantic definitions" as
already advocated by Prof. Neumaier. If we provide such kind of
definition for arithmetic operations, we should be bound to do the same
for all operations supported by the standard (which ones, BTW?), which,
IMHO, would greatly augment the complexity of the document.
FG.
- --
Frédéric Goualard LINA - UMR CNRS 6241
Tel.: +33 2 51 12 58 38 Univ. of Nantes - Ecole des Mines de Nantes
Fax.: +33 2 51 12 58 12 2, rue de la Houssinière - BP 92208
http://goualard.frederic.free.fr/ F-44322 NANTES CEDEX 3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFKpK0CEJvxJgN8HkgRAuGqAKCefnwpMRea2pmlTW+o9y/WdCmRPQCfaJ2v
spbe4Y+ALtZY6GM2rUeWsxE=
=gpiV
-----END PGP SIGNATURE-----
Subject: Motion P1788/M0005.02_Table_of_operations NO
Date: Sunday, September 6, 2009 8:32 PM
From: Vincent Lefevre <vincent@xxxxxxxxxx>
To: <stds-1788@xxxxxxxxxxxxxxxxx>
Conversation: Motion P1788/M0005.02_Table_of_operations NO
NO
(Note: I'm not really against this motion, but I find it rather useless.
Said otherwise, I abstain, but as this is equivalent to a NO vote...)
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Subject: Motion P1788/M0005.02_Table_of_operations NO
Date: Tuesday, September 8, 2009 11:10 AM
From: Alexandre Goldsztejn <alexandre.goldsztejn@xxxxxxxxx>
To: <stds-1788@xxxxxxxxxxxxxxxxx>
Conversation: Motion P1788/M0005.02_Table_of_operations NO
NO
I think the motion is too long. It would be enough and useful to
provide the mathematical definition of the extension to intervals
first. The explicit expressions of the operations are direct
consequences of this definition, so they could be provided in apendix
with not so much comments about the way they are derived (I am
thinking of the long discussion presented in the motion about the
division by zero containing intervals, which sounds useless to me).
On the other hand, I think directed rounding and the requested
accuracy of roundings are a central topic that should be discussed and
voted in a separate motion.
Kind regards,
Alexandre Goldsztejn
Subject: Motion P1788/M0005.02_Table_of_operations vote : NO
Date: Tuesday, September 8, 2009 3:13 PM
From: Michel Hack <hack@xxxxxxxxxxxxxx>
To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
Conversation: Motion P1788/M0005.02_Table_of_operations vote : NO
I vote NO on Motion 5 -- table of operations.
I believe with several others that a semantic definition of operations
in the style of the Vienna proposal is a better way to proceed.
I would welcome the explicit definitions in an appendix, if we can
away with that. (We had a similar discussion in P754R about the late
Dave James' tabular definitions.)
The problem with such explicit definitions as THE STANDARD is that
any small oversight, overspecification, or even typo, leaves nothing
to fall back on. They are however very useful as a checkout mechanism,
which is why I don't want to ignore them: they have their place, but
I feel it is as an extra and not as a principal.
Michel.
---Sent: 2009-09-08 20:22:32 UTC
Subject: Motion P1788/M0005.02_Table_of_operations NO
Date: Tuesday, September 8, 2009 5:09 PM
From: Christian Keil <c.keil@xxxxxxxxxxxxx>
To: "stds-1788@xxxxxxxxxxxxxxxxx" <stds-1788@xxxxxxxxxxxxxxxxx>
Conversation: Motion P1788/M0005.02_Table_of_operations NO
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NO.
Like several guys before me noted, I also prefer a definition like the
one in the Vienna proposal and possibly a more specific definition like
the one in the motion as a supplementary appendix.
Regards,
Christian
- --
/"\
Christian Keil \ / ASCII Ribbon Campaign
mail:c.keil@xxxxxxxxxxxxx X against HTML email & vCards
/ \
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkqm1ewACgkQnsZPgWGt3GP3jgCg1v52GidtrsEx4Nle7Aq6w90y
+4AAoMQma7z/JHO3/DhGWA+W92CBtGad
=WskQ
-----END PGP SIGNATURE-----
Subject: Re: VOTE on Motion 5
Date: Thursday, September 10, 2009 10:23 PM
From: Lee Winter <lee.j.i.winter@xxxxxxxxx>
To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
Conversation: VOTE on Motion 5
On Thu, Sep 10, 2009 at 6:32 AM, Corliss, George
<george.corliss@xxxxxxxxxxxxx> wrote:
> Today is the LAST DAY to vote on Motion 5.
I vote NO on motion 5. There are many reasons, the most significant
of thich is the limitednes of the conceptual underpinning of the
motion. That conceptual underpinning is inadequate for the purposes
of IEEE-1788. For example, the fist sentence of the circulated PDF is
false and that falisty is obvious by inspection.
Lee Winter
NP Engineering
Nashua, New Hampshire
---------- Forwarded message ----------
From: Dorina Lanza <dorinalanza@xxxxxxxxx>
To: stds-1788@xxxxxxxxxxxxxxxxx
Date: Thu, 10 Sep 2009 22:29:36 -0500
Subject: Motion 5: No
My vote is against Motion 5. The proposed arithmetic is useless for
real-world calculations.
--
Dorina Lanza
603-595-2608 [office]
617-633-0925 [cell]
http://dorinalanza.com
Subject: Motion P1788/M0005.02_Table_of_operations vote : YES
Date: Wednesday, September 9, 2009 5:32 AM
From: Dominique Lohez <dominique.lohez@xxxxxxx>
To: Ulrich Kulisch <Ulrich.Kulisch@xxxxxxxxxxx>, George Corliss
<George.Corliss@xxxxxxxxxxxxx>, <stds-1788@xxxxxxxx>
Conversation: Motion P1788/M0005.02_Table_of_operations vote : YES
I revoke my previous wote
My last vote is YES
Dominique LOHEZ
Rationale
1) While this does not correspond to my own understanding on some points
The results presented in this motion are consistent to the already
approved choices.
Namely the motion 3 and the point 3.5.5 of Motion 6.04 under
discussion
2) I understand that the detailed formulation of the operation may
appear to be superfluous if semantic description are provided.
I do not share this point of view , since some explicit
translations of general principles may be difficult.
Furthermore i note that the motion does not contain any
statement on the use of the results in the standard.
--
Dr Dominique LOHEZ
ISEN
41, Bd Vauban
F59046 LILLE
France
Phone : +33 (0)3 20 30 40 71
Email: Dominique.Lohez@xxxxxxx