P1788: M0006.04_Level_2_Multi-format PASSED
P1788,
M0006.04 Level_2_Multi-format is PASSED
Yes: 48, No: 4, of 71 registered Voting Members
Quorum is half the voting members
Passage is by half those voting
PLEASE VOTE ON MOTION 7. Current tally:
Yes: 13, No: 14, of 71 voting members (ends 21 Sept.)
George Corliss, P1788 Voting Tabulator
The motion text is as follows:
===============================================================
P1788 members (from John Pryce)
As requested I circulate herewith version 4 (hopefully final) of
Position Paper 13, "TEXT AND RATIONALE FOR MOTION 6: MULTI-FORMAT
SUPPORT", on which the vote will be conducted.
Also as requested by the Chair, here is a brief change-history.
2009 April 21. Original version of motion 6 circulated in plain text
form.
June 9. Following extended criticism and discussion, version 2 of
plain text has a clearer statement of the motion, new "Overall aims"
section, improved Definitions, and introduces the SRSF, SRMF, MRMF
concepts.
June 29. Typeset version produced as a Position Paper, mostly similar
to previous plain text.
July 14. Typeset version, revised, circulated as Position Paper PP013
and motion 6 formally re-submitted. Revisions with help from Arnold
Neumaier, Ulrich Kulisch and others improve notation and make it
consistent with Motion 5. Statement of motion simplified and made
more precise.
July 14 - August 11. Meaning of "interval mapping", "interval
function" clarified. After comment by Vincent Lefevre, abstract/
concrete "floating-point format" renamed "number format" (so af-
format, cf-format become an-format, cn-format). Other minor
corrections. Vincent also proposes support for MRMF in "valid" mode
be included in motion.
Today Aug 11. In this final version I have modified what is said
about MRMF support in the rationale, but have not included Vincent's
proposed words in the motion. Instead, the Chair has suggested
Vincent proposes a separate motion covering MRMF support.
Best wishes
John Pryce
================================================================
For the record, NO votes and comments. Technical Editors may consider these
when framing subsequent motions:
From: Maarten van Emden <vanemden@xxxxxxxxxx>
To: <stds-1788@xxxxxxxxxxxxxxxxx>
Conversation: Motion 6
My vote is NO.
Rationale: Motion 6 addresses an issue at level(s) below level
1 of the document accepted as per Motion 2, while there are
unresolved issues at level 1. One of these issues is the definition
of relational operations (at level 1, of course).
From: Frédéric Goualard <Frederic.Goualard@xxxxxxxxxxxxxx>
To: <stds-1788@xxxxxxxxxxxxxxxxx>
Conversation: Motion P1788/M0006.04_Level_2_Multi-format NO
My vote is NO because the associated position paper definitely
assumes---even if peripherally---the implicit (e.g., [-oo, -oo] and
[+oo, +oo] have no meaning, which should make them NaIs, whatever that
object is) or explicit existence of NaIs, a concept I am not in favour of.
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
From: Dominique Lohez <dominique.lohez@xxxxxxx>
To: George Corliss <George.Corliss@xxxxxxxxxxxxx>
Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
Conversation: [IEEE P1788] P1788/M0006.04_Level_2_Multi-format NO
My vote is NO
Dominique LOHEZ
I would vote YES if the following changes were done
1) The subsection 3.5.2 is removed
2) In subsection 3.5.4 the statement
1. Here, f is a mapping, not an expression.
should be completed by explaining what is an expression
and why the difference is important in interval arithmetic.
3) In subsection 3.6.1 the reference to R* should be avoided.
This can be achieved by considering a lattice with a
finite number of elements and a linear order relation.
Such a lattice has a minimum which can be labeled -Infinity
Such a lattice has a maximum which can be labeled +Infinity
the other elements are an embedment of the
appropriate finite subset of R
Rationale
1) Since the author's intent of is that the text is used as it in
the standard. All the wordings and statements must be checked carefully.
2) Concerning the change 1
-Either the decision has been taken when the Motion was
approved. And the meaning should have been explained as an annex of this
motion.
( It is my own opinion)
- Either there a new choice concerning (-Infinity ,
- Infnity) ... and this choice should not be dealt as a side effect
of a motion devoted to
a completely different subject.
3) The standard must be readable to new comers in Interval
arithmetic (Change 2)
4) I cannot prevent myself from thinking when I encounter a
reference to R* to a surreptitious come back of what was rejected in
Motion 3 .
And a simple alternative is available here.
--
Dr Dominique LOHEZ
ISEN
41, Bd Vauban
F59046 LILLE
France
Phone : +33 (0)3 20 30 40 71
Email: Dominique.Lohez@xxxxxxx
From: G. William (Bill) Walster <bill@xxxxxxxxxxx>
Reply-To: <bill@xxxxxxxxxxx>
To: <stds-1788@xxxxxxxxxxxxxxxxx>
Conversation: Motion 6
I vote NO on Motion 6.
There are good reasons for interval data types to be opaque. This means
that the internal representation of an interval should only be
accessible through intrinsic functions supplied with the given language
support for interval data types.
The advantage is that hardware manufacturers are thereby free to choose
an internal representation that best suits their machine architecture.
It also means that any "standard" internal representation cannot act as
an roadblock to mathematical and implementation innovations that produce
superior quality results in terms of speed and width.
Ideally, this leaves only one thing to be done in an interval standard:
Define the set of values that any compliant interval implementation must
contain. How such a standard is implemented can then be totally left up
to the imagination and creativity of different implementers.
As far as I can tell, this most important definition does not yet exist.