P1788: M0019.02 PASSES
P1788:
On recounting, Motion 19.02 passes, 35 - 5, with 37 voters required for a quorum.
Observe that under our rules, had the "No" voters not voted, the motion would have failed for lack of a quorum.
Most of the discussion specific to this motion that occurred during the voting is appended below.
Dr. George F. Corliss
Electrical and Computer Engineering
Marquette University
P.O. Box 1881
1515 W. Wisconsin Ave
Milwaukee WI 53201-1881 USA
414-288-6599; GasDay: 288-4400; Fax 288-5579
George.Corliss@xxxxxxxxxxxxx
www.eng.mu.edu/corlissg
Begin forwarded message:
> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> Date: October 26, 2010 10:31:52 AM CDT
> Subject: Re: P-1788 officers: what next?
>
>
> That motion 19 may not get a quorum is a bit of a blow. I was hoping to abstain but I guess I'll have to put in a yes vote. (
> George: that's a vote, in case I forget to send a separate one.)
> If it passes, a large change to the level 2 text is needed. If not, I propose to change (level 2) "interval format" to "interval datatype" but otherwise leave much as in current draft V02.2.
>
> John
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Date: October 28, 2010 11:07:09 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: M00019.02 - YES
>
> I vote YES for M00019.02.
>
> However I don't think the unique definition of a hull is necessary
> for implicit i-datatypes:
> 1. It will not ensure reproducibility across platforms (because the
> definitions and implementations may be different).
> 2. The valid mode will typically be used, so that the notion of
> unique hull will not be used.
> 3. The tightest mode is better suited to inf-sup.
>
> Concerning the rationale and the comparison with IEEE 754, let's
> recall that IEEE 754 doesn't ensure reproducibility, and it is
> even rather difficult to have reproducibility in practice (due
> to both languages and their practical implementations).
>
> --
> 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)
Begin forwarded message:
> From: Frédéric Goualard <Frederic.Goualard@xxxxxxxxxxxxxx>
> Date: October 29, 2010 3:11:01 AM CDT
> To: P-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Motion 0019.02: NO
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I vote NO on Motion 19.02.
>
> I believe that Motion 19.02 leads to deviation from the KISS principle
> advocated several times on this list.
>
> Regards,
>
> 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://frederic.goualard.net/ F-44322 NANTES CEDEX 3
Begin forwarded message:
> From: Jürgen Wolff von Gudenberg <wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Date: October 29, 2010 5:10:57 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Motion 19.02 YES
>
> Although I do not like every detail of the motion (3.4(1),e.g) ,I consider the contents as a tool to finally write down the standard text.
> Hence, I finally vote YES
> Juergen
>
> --
> -
> o Prof. Dr. J. Wolff v. Gudenberg, Informatik II
> / \ Universitaet Wuerzburg, Am Hubland, D-97074 Wuerzburg
> InfoII o Tel.: +49 931 / 31 86602
> / \ Uni E-Mail: wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx
> o o Wuerzburg
Begin forwarded message:
> From: Alexandru Amaricai <amaricai@xxxxxxxxx>
> Date: October 30, 2010 10:53:23 AM CDT
> To: <stds-1788@xxxxxxxx>
> Subject: Motion 19
>
> I vote NO. As said previously, we should stick to the KISS principle in the development of our standard.
>
> Alexandru Amaricai
Begin forwarded message:
> From: Michel Hack <hack@xxxxxxxxxxxxxx>
> Date: October 31, 2010 12:41:48 PM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Motion 19.02 -- explicit refusal to vote
>
> There is more at stake here than the KISS principle, which other NO
> voters have stated. I disagree with the premise that "All interval
> datatypes are equal", even if some are more equal than others. The
> inability to express semibounded ranges is a crucial difference, of
> a different nature than the inability to define an unambiguous hull.
>
> There are also some important corrections which have not been applied.
> Perhaps I did not realise (when I proposed those corrections on 23 Sept)
> that I had to submit a "friendly amendment" to get them dealt with.
>
> The motion also proposes to change the TEXT of the current draft. Does
> that not raise its status above that of a position paper?
>
> Michel.
>
> P.S. Here we are, pretending to do math -- but we did not even realise
> that our voting rules were broken, until Arnold alerted us!
>
> With the current rules, as soon as members/2 YES votes have been
> received, ANY vote -- including NO votes -- counts as a YES vote,
> albeit one that is accompanied with comments explaining why the
> voter actually disagrees.
> ---Sent: 2010-10-31 17:58:34 UTC
Begin forwarded message:
> From: Michel Hack <hack@xxxxxxxxxxxxxx>
> Date: October 31, 2010 1:04:58 PM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Motion 19.02 -- explicit refusal to vote
>
> Actually, my math (in the P.S. of my non-vote) was flaky too: As soon
> as members/4 (NOT members/2) have voted YES, subsequent NO votes risk
> being counted as YES when the voting deadline approaches, UNLESS the
> number of NO votes manages to overtake the YES votes before the deadline.
>
> (If 1+members/2 YES votes have been received the issue is decided, for
> votes on position papers... except for the fact that we allow votes to
> be changed before the deadline!)
>
> Michel.
More on that thread omitted ...
Begin forwarded message:
> From: Svetoslav Markov <smarkov@xxxxxxxxxx>
> Date: November 1, 2010 3:10:29 AM CDT
> To: <stds-1788@xxxxxxxx>
> Subject: Motion 19.02 NO
>
>
> My vote to motion 19.02 is "no".
>
> I would vote "yes" if either:
>
> a) the motion is modified so that an implementation
> that supports only an implicit type is also conforming
>
> b) the name of the interval arithmetic standard is
> modified accordingly.
>
> Svetoslav Markov, IMI-BAS
>
> PS. Motion 19.02 makes a significant step towards the
> recognition of the "mid-rad" implementations as auxiliary to
> "inf-sup". However, I think that "mid-rad only" arithmetic
> should also be conforming. Let me recall the two main
> mathermatical arguments against "mid-rad only" support:
>
> 1. infinite intervals are not representable in mid-rad, and
>
> 2. when the midpoint of a (real) interval is exactly in the middle
> between two machine numbers, then mid-rad presentation is not unique.
>
> I do not find these arguments sufficiently serious.
>
Begin forwarded message:
> From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
> Date: November 1, 2010 1:17:13 PM CDT
> To: Svetoslav Markov <smarkov@xxxxxxxxxx>, 1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Motion 19.02 NO
>
> Svetoslav Markov wrote:
>> My vote to motion 19.02 is "no".
>> I would vote "yes" if either:
>> a) the motion is modified so that an implementation that supports only an implicit type is also conforming
>> b) the name of the interval arithmetic standard is modified accordingly.
>> Svetoslav Markov, IMI-BAS
>> PS. Motion 19.02 makes a significant step towards the
>> recognition of the "mid-rad" implementations as auxiliary to
>> "inf-sup". However, I think that "mid-rad only" arithmetic
>> should also be conforming. Let me recall the two main mathematical arguments against "mid-rad only" support:
>> 1. infinite intervals are not representable in mid-rad, and
>> 2. when the midpoint of a (real) interval is exactly in the middle
>> between two machine numbers, then mid-rad presentation is not unique.
>> I do not find these arguments sufficiently serious.
>
> You grossly distort the argumentation against a mid-rad datatype.
>
> The main argument against it is that there has been _extremely_ little
> past use of mid-rad arithmetic on single intervals. (The only serious
> use of mid-rad is for vectorized matrix-vector and matrix-matrix
> multiply, and this application doesn't make use of a mid-rad interval
> format, but does all computations by means of a midpoint matrix and a
> radius matrix. So a standard on midrad intwervals would have no bearing
> on this.
Begin forwarded message:
> From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
> Date: November 2, 2010 3:28:10 AM CDT
> To: Svetoslav Markov <smarkov@xxxxxxxxxx>
> Cc: 1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Motion 19.02 NO - distorted arguments
>
> Svetoslav Markov wrote:
>> On 1 Nov 2010 at 19:17, Arnold Neumaier wrote:
>> Date sent: Mon, 01 Nov 2010 19:17:13 +0100
>> From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
>> Organization: University of Vienna
>> To: Svetoslav Markov <smarkov@xxxxxxxxxx>, 1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>> Subject: Re: Motion 19.02 NO
>>> Svetoslav Markov wrote:
>>>> My vote to motion 19.02 is "no".
>>>> I would vote "yes" if either:
>>>> a) the motion is modified so that an implementation that supports only an implicit type is also conforming
>>>>
>>>> b) the name of the interval arithmetic standard is modified accordingly.
>>>>
>>>> Svetoslav Markov, IMI-BAS
>>>> PS. Motion 19.02 makes a significant step towards the
>>>> recognition of the "mid-rad" implementations as auxiliary to
>>>> "inf-sup". However, I think that "mid-rad only" arithmetic
>>>> should also be conforming. Let me recall the two main mathematical arguments against "mid-rad only" support:
>>>> 1. infinite intervals are not representable in mid-rad, and
>>>> 2. when the midpoint of a (real) interval is exactly in the middle
>>>> between two machine numbers, then mid-rad presentation is not unique.
>>>>
>>>> I do not find these arguments sufficiently serious.
>>> You grossly distort the argumentation against a mid-rad datatype.
>>>
>>> The main argument against it is that there has been _extremely_ little
>>> past use of mid-rad arithmetic on single intervals. (The only serious
>>> use of mid-rad is for vectorized matrix-vector and matrix-matrix
>>> multiply, and this application doesn't make use of a mid-rad interval
>>> format, but does all computations by means of a midpoint matrix and a
>>> radius matrix. So a standard on midrad intwervals would have no bearing
>>> on this.
>>>
>> I said _mathematical_arguments_ .
>> I tried to summarize the main _mathematical_arguments_ against mid-rad.
>> I agree that there has not been too many applications related to mid-rad. But I do not think that such arguments are of _mathematical_ nature.
>> Do I distort any _mathematical_ arguments?.
>
> Mathematical arguments don't decide about standardization issues.
> Mathematical consistency is only a necessary condition.
>
> It has no force at all for supporting a mid-rad only implementation.
>
> A mid-rad only implementation could not even implement Rump's algorithm
> for fast matrix-vector multiply, excwept by making no use at all of the
> implementation!!