Re: Motion P1788/M0016.01: No

["Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>]

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



----- Original Message ----- 
From: "Marco Nehmeier" <nehmeier@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
To: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>; <stds-1788@xxxxxxxx>
Sent: Friday, June 11, 2010 4:59 AM
Subject: Re: Motion P1788/M0016.01: No


> Am 10.06.2010 18:48, schrieb Nate Hayes:
> > I vote no.
> >
> > The motion implies an internal format must be the same as a supported
> > interchange format. For example, if the interchange format is comprised 
> > of
> > two IEEE 754 values, then any implementation using extended precision,
> > multi-precision, or exact (symbolic) precision as an internal format 
> > would
> > be non-conforming.
> >
> > Perhaps this is not the intention of the motion. But in that case, the
> > distinction between "supported" and "available" interchange types is
> > irrelevant. I would vote yes if all references to this distinction were
> > removed, leaving the standard silent on the internal format except to say
> > that all conversions preserve inclusion isotonicity.
> >
> > Of course, an implementer may choose an internal format that is the same 
> > as
> > the interchange format. In this case, conversions are exact. However, I
> > think it is unreasonable to require this for all conforming
> > implementations.
> >
> > Nate Hayes
> > Sunfish Studio, LLC
>
>
> Dear Nate, P1788,
>
>
> We think you are wrong. In our opinion Motion 16 does not say any word on 
> internal formats.
>
> It is possible to implement a supporting type in any thinkable internal 
> representation. For example the implementation in Intlab uses a internal 
> mid-rad representation for some operations but the interface  is still 
> inf-sup (see mail from Arnold Neumaier 10.05.2010 15:26)
>
> Jürgen & Marco
>
>
> --
>      o           Marco Nehmeier, Lehrstuhl fuer Informatik II
>     / \          Universitaet Wuerzburg, Am Hubland, D-97074 Wuerzburg
> InfoII o         Tel.: +49 931 / 31 88684
>   / \  Uni       E-Mail: nehmeier@xxxxxxxxxxxxxxxxxxxxxxxxxxx
>  o   o Wuerzburg