Re: Do I have a second? (Motion to not support mid-rad
> Date: Tue, 14 Sep 2010 20:36:19 +0200
> From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
> To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Subject: Re: Do I have a second? (Motion to not support mid-rad
>
> Dan Zuras Intervals wrote:
>
> >> From: "Ralph Baker Kearfott" <rbk@xxxxxxxxxxxx>
>
> >>> Arnold Neumaier and Dan Zuras have jointly put forward the
> >>> following motion:
> >>>
> >>> The standard shall not support a midrad interval format or
> >>>> nonstandard intervals, beyond providing conversion support,
> >>>> approximately to the extent specified in the Vienna Proposal.
Arnold, this is quoted from your email directly.
> >>>>
> >>> Do I have a second?
> >>>
> >>> Baker
> >>>
> >>> P.S. I'm wondering precisely what "support" means here. Perhaps,
> >>> if the motion is seconded, that could be clarified during the
> >>> discussion. (I'm assuming it means explicitly specifying the
> >>> behavior of mid/rad operations.)
> >>>
> > I believe you are both correct. The notion of 'support'
> > here is ambiguous.
> >
> > The motion itself is unusual but not without precedent.
> > The motion states that a conforming implementation
> > shall NOT do something in order to conform.
>
> You proposed the motion and can give it any meaning you like.
So, if by quoting you directly I made a motion that
was not what you had in mind, I apologise.
>
>
> . . .
>
>
> > Therefore, I would say that 'support' in this context
> > means providing the means to do ANYTHING with a
> > mid-rad value other than to convert to & from it.
>
> No.
>
> The motion is constructive only if ''supported'' is meant in the sense
> formally introduced in Motion 16.
>
> Thus, apart from conversion issues, specifications shall be provided
> by the standard only for inf-sup interval types, and only for
> standard intervals, i.e., those that represent closed and connected
> sets.
>
> On the other hand, nothing should prevent implementors from providing
> arbitrary functionality for midrad interval or nonstandard intervals,
> as long as the required conversion rules to all (and at least one)
> supported infsup datatype are respected.
>
>
> Arnold Neumaier
But I'm not sure what to do here. By this interpretation
of "The standard shall not support..." you seem to be
placing a restriction on US rather than on a conforming
implementation.
What meaning can it have for assured computing to restrict
us as a standards body from specifying mid-rad intervals
but allow the user to use them in something that we are
attempting to certify as correct?
Needless to say I am confused by all this.
Can you give me another description that involves some
sort of specification that we make in the standard which
restricts the behavior of implementations that we are
trying to certify as correct & conforming & is in
keeping with your wishes to 'not support mid-rads'?
I will accept it as a friendly amendment.
Well, if I understand it, that is.
Dan