Re: Motion P1788/M0016.01: No

["Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>]

Dan, Folks,

I like gravy.

As I've mentioned before in this forum, much of what I've heard in the 
discussions surrounding this topic I support and agree with. But I do not 
yet see it is all captured clearly in the particular wording of the motion. 
For this reason, I feel I do not know exactly what I will be voting "yes" 
for. This is why I vote "no" and provide a rationale (instead of just not 
voting at all). Others may disagree and that is fine, but in my opinion 
already there has been some expression of conflicting interpretations of the 
wording in Motion 16, so I think this is an example it needs further 
clarification. That's all.

Nate


----- Original Message ----- 
From: "Dan Zuras Intervals" <intervals08@xxxxxxxxxxxxxx>
To: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
Cc: <stds-1788@xxxxxxxxxxxxxxxxx>; "Dan Zuras Intervals" 
<intervals08@xxxxxxxxxxxxxx>
Sent: Friday, June 11, 2010 11:38 AM
Subject: Re: Motion P1788/M0016.01: No


> > From: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
> > To: "Marco Nehmeier" <nehmeier@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
> >  <stds-1788@xxxxxxxx>
> > Subject: Re: Motion P1788/M0016.01: No
> > Date: Fri, 11 Jun 2010 10:14:00 -0500
> >
> > Dear Marco, P1788,
> >
> > The motion says:
> >
> > "An interval type is said to be _supported_ if all required operations 
> > are
> > implemented..."
> >
> > To me, this implies a "supported" type is an "internal format," since
> > operations are implemented on internal formats.
> >
> > What I hear you saying about Intlab agrees with my understanding: that an
> > input in the form of an inf-sup interchange format is provided, converted 
> > to
> > some internal format (mid-rad, in this case), and then operations are
> > implemented on the internal format.
> >
> > So I think all that is required in Motion 16 is to say all available
> > (interchange) types must be convertible to and from some internal format. 
> > I
> > don't see how the distinction between "supported" and "available" should 
> > be
> > relevant in this case.
> >
> > Nate
>
> Nate, motion 16 is short & simple.  I quote the original
> text (which I think has been reworded a bit since):
>
> > An interval type is said to be <b> supported </b> if all
> > required operations are implemented as well as conversions to
> > and from that type and any other type and import from and export
> > to text strings.
> >
> > An interval type is said to be <b> available </b> if conversions
> > to and from that type and any other type are implemented as well
> > as import from and export to text strings.
> >
> > A conforming implementation shall support at least one inf-sup
> > type and make available at least one mid-rad and one mid-rad1-rad2
> > type.
> >
> > All conversions shall preserve containment and return the tightest
> > representable interval in the target type.
> >
> > All imports shall preserve containment and return the tightest
> > representable interval in the target type.  All exports shall
> > preserve containment and return the tightest representable text
> > string in the specified format.
> >
> > NOTE --- This standard is silent on the matter of other
> > operations implemented for types that are available but not
> > supported.
>
> While I'm not quite sure what you mean by 'internal format',
> neither that nor 'interchange format' are used in this motion
> or intended.
>
> Neither supported formats nor available formats need be
> interchange formats.
>
> Nor is it intended that arithmetic in an inf-sup format be
> able to be 'simulated' by a mid-rad format or vice versa,
> internally or otherwise.
>
> Therefore the motion acknowledges that there *IS* a distinction
> between inf-sup & mid-rad formats.  The motion says you must
> have at least one inf-sup to do arithmetic in & you must be
> able to convert to/from at least one mid-rad whether you choose
> to do arithmetic in it or not.
>
> That's all.
>
> Everything else is gravy.
>
> At least that was *MY* intent when I was asked to write those
> words.
>
>
>    Dan