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