Motion P1788/M0016.01:InfSupAndMidRad: PASSES
P1788,
Motion P1788/M0016.01:InfSupAndMidRad passes
Yes - 30; No - 10; Quorum: 37 (1/2 of Voting Members)
Proposer: Dan Zuras (from Arnold Neumaier)
Second: Vladik Kreinovich
Motion:
-------
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.
===============================================
I collect reasons for NO votes and other comments during the voting period, hoping to facilitate greater consensus as our work continues.
Begin forwarded message:
> From: John Pryce <prycejd1@xxxxxxxxxxxxx>
> Date: June 8, 2010 12:12:38 AM CDT
> To: P1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Motion P1788/M0016.01:InfSupAndMidRad: Yes
>
> I vote Yes.
>
> It seems strange that this motion has had little or no comment during the discussion period, but to me it seems well expressed and I agree with it.
>
> Except "conversions to and from that type and any other type" is bad grammar and might be changed to "conversions between that type and any other type".
Begin forwarded message:
> From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> Date: June 10, 2010 11:48:20 AM CDT
> To: P-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Motion P1788/M0016.01: No
> Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
>
> 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
> Begin forwarded message:
>
>> From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
>> Date: June 11, 2010 10:14:00 AM CDT
>> To: Marco Nehmeier <nehmeier@xxxxxxxxxxxxxxxxxxxxxxxxxxx>, <stds-1788@xxxxxxxx>
>> Subject: Re: Motion P1788/M0016.01: No
>> Reply-To: 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
>
Begin forwarded message:
> From: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Date: June 11, 2010 11:38:13 AM CDT
> To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> Cc: <stds-1788@xxxxxxxxxxxxxxxxx>, Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Subject: Re: Motion P1788/M0016.01: No
> Reply-To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
>
>> 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
Begin forwarded message:
> From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> Date: June 11, 2010 3:40:32 PM CDT
> To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Cc: <stds-1788@xxxxxxxxxxxxxxxxx>, Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Subject: Re: Motion P1788/M0016.01: No
> Reply-To: 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
Begin forwarded message:
> From: Marco Nehmeier <nehmeier@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Date: June 25, 2010 3:49:44 AM CDT
> To: <stds-1788@xxxxxxxx>
> Subject: Motion P1788/M0016.01: No
>
> My vote is also NO - for the same reasons that Nate stated.
>
> Best regards
> Marco
Begin forwarded message:
> From: <vaccaro@xxxxxxxxxxxx>
> Date: June 25, 2010 4:46:47 AM CDT
> To: <stds-1788@xxxxxxxx>
> Subject: Motion P1788/M0016.01: Yes
>
> My vote is No according to the argumentations expressed during the motion
> discussions.
> Alfredo Vaccaro
Begin forwarded message:
> From: Dominique Lohez <dominique.lohez@xxxxxxx>
> Date: June 25, 2010 9:23:29 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>, "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
> Subject: P1788 Motion16.01 NO
>
> My vote is no
> The reasons are the same as already evoked by Nate Hayes
> My vote would be yes if
> 1) the word 'implemented' is replaced by 'provided' everywhere it appears
> 2) the word 'implementation' is replaced by 'distribution'
>
> Sincerely,
>
> Dominique LOHEZ
Begin forwarded message:
> From: Svetoslav Markov <smarkov@xxxxxxxxxx>
> Date: June 27, 2010 7:47:20 AM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: P1788 Motion16.01 NO
>
> My vote is no
>
> My vote would be yes if:
> 1) no different conditions are imposed on inf-sup and mid-rad ;
> 2) nothing is mentioned about mid-rad1-rad2 as no arithmetic is
> known to me for such a presentation
>
> Sincerely,
>
> S Markov
Begin forwarded message:
> From: Michel Hack <hack@xxxxxxxxxxxxxx>
> Date: June 27, 2010 10:00:02 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: inf-sub vs mid-rad and Motion 16
>
> Svetoslav Markov wrote:
>> My vote would be yes if:
>> 1) no different conditions are imposed on inf-sup and mid-rad ;
>
> Can't do, unless we revise our basic assumptions and drop support for
> semibounded inf-sup intervals.
>
> Let's face it: inf-sup and mid-rad have different application domains
> and different properties. There *is* a large common ground, namely
> reasonably narrow intervals (neither too wide, which only inf-sup handles
> well, nor too narrow, which only mid-rad can represent). I'm thinking of
> basic formats here, not the various triplex forms that can do more.
>
> Motion 16 presents the issue in a manner that permits exploitation of
> that common ground, as INTLAB seems to be doing rather nicely.
>
> Michel.
Begin forwarded message:
> From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> Date: June 27, 2010 10:56:02 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>, Michel Hack <hack@xxxxxxxxxxxxxx>
> Subject: Is Intlab conforming?
> Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
>
> Michel, P1788,
>
> On a slightly different topic:
>
> Michel Hack wrote:
>> Motion 16 presents the issue in a manner that permits exploitation of
>> that common ground, as INTLAB seems to be doing rather nicely.
>
> I agree INTLAB exploits this common ground nicely. However, particularly by
> Dan's interpretation of Motion 16, it seems obvious to me Siegfried's
> implementation isn't conforming.
>
> Since I'm sure this isn't the intent of Motion 16 (or Motion 14, either), I
> think this needs clarification.
>
> Nate
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Date: June 27, 2010 7:24:29 PM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Motion P1788/M0016.01: No
>
> I vote NO on Motion 16.
>
> "the tightest representable interval in the target type" is not
> defined in case of mid-rad and mid-rad1-rad2.
>
> --
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
Begin forwarded message:
> From: Michel Hack <hack@xxxxxxxxxxxxxx>
> Date: June 27, 2010 8:54:23 PM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Tightest representable interval in mid-rad (cf. Motion 16)
>
> Vincent Lefèvre wrote:
>> "the tightest representable interval in the target type"
>> is not defined in case of mid-rad and mid-rad1-rad2.
>
> Is there a problem in defining a tie-breaking rule? The cases where
> it applies are pretty rare (intervals of width 1 ulp), and one could
> decide that the midpoint have an even significand, for example. Or
> there could be a formula, e.g. as provided in the Vienna proposal,
> where the rounding applied to the division by two would decide.
>
> (Actually, an odd significand might be better, because in the case of
> the inf-sup interval [0, MinSubnormal] the sign could be preserved.)
>
> For mid-rad1-rad2 we don't have a precise definition on the table, so
> that point is moot. Motion 16 simply says what properties are needed.
>
> We will eventually have to settle these details, but I don't think that
> was the intent of Motion 16.
>
> Michel.
Begin forwarded message:
> From: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Date: June 27, 2010 8:42:30 PM CDT
> To: Michel Hack <hack@xxxxxxxxxxxxxx>
> Cc: <stds-1788@xxxxxxxxxxxxxxxxx>, Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Subject: Re: Tightest representable interval in mid-rad (cf. Motion 16)
> Reply-To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
>
>> Date: Sun, 27 Jun 2010 20:54:23 -2000
>> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>> From: Michel Hack <hack@xxxxxxxxxxxxxx>
>> Subject: Tightest representable interval in mid-rad (cf. Motion 16)
>>
>> Vincent Lefèvre wrote:
>>> "the tightest representable interval in the target type"
>>> is not defined in case of mid-rad and mid-rad1-rad2.
>>
>> Is there a problem in defining a tie-breaking rule? The cases where
>> it applies are pretty rare (intervals of width 1 ulp), and one could
>> decide that the midpoint have an even significand, for example. Or
>> there could be a formula, e.g. as provided in the Vienna proposal,
>> where the rounding applied to the division by two would decide.
>>
>> (Actually, an odd significand might be better, because in the case of
>> the inf-sup interval [0, MinSubnormal] the sign could be preserved.)
>>
>> For mid-rad1-rad2 we don't have a precise definition on the table, so
>> that point is moot. Motion 16 simply says what properties are needed.
>>
>> We will eventually have to settle these details, but I don't think that
>> was the intent of Motion 16.
>>
>> Michel.
>> ---Sent: 2010-06-28 01:07:28 UTC
>
> Gentlemen,
>
> Yes, any reasonable tie-breaking rule will work here.
>
> But it is not the issue.
>
> Narrow intervals play into the strengths of both inf-sup
> & mid-rad methods. The problem lies in their weaknesses.
> Wide intervals are poorly represented in mid-rad & semi-
> infinite intervals not at all.
>
> While there is a diverse group of applications which
> ONLY use narrow intervals, as a standards body we cannot
> assume we know what the user is doing or why.
>
> Providing correct (i.e. containing) arithmetic is not
> enough. The user must KNOW it is correct. It must be
> provable to the satisfaction of others. Therefore, it
> must be testable & reproducable from machine to machine.
>
> Any 'standard' vague enough to admit both methods as if
> they were identical will permit results that, while
> formally correct, are incapable of being independently
> verified.
>
> Users will not believe in such a standard.
>
> And if they don't believe they won't use it.
>
> And if they won't use it we might as well not write it.
>
> If we don't believe in the need for a standard I'm sure
> we all have better things to do with our lives.
>
> I know I do. :-)
>
> Dan
Begin forwarded message:
> From: Alan Eliasen <eliasen@xxxxxxxxxxxxxx>
> Date: June 28, 2010 1:33:38 AM CDT
> To: P-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Motion P1788/M0016.01: No
>
> I vote NO on Motion P1788/M0016.01.
>
> My reasons are similar to those stated by Nate Hayes: the
> implications are that an internal format must be the same as an
> interchange format. John Pryce's clarifications on this matter did not
> dispel these concerns, and I think the wording of the motion needs to be
> changed to not have implications that affect internal representation.
>
> I also believe that undecorated mid-rad representations may not be
> able to represent infinite-in-one direction values properly without a
> previous definition of this representation. For example, if we have an
> interval with a [-3, 10, +oo] or [-oo, -999, 10] it would appear to be
> impossible to represent this with a mid-value and a single radius,
> without previously defining our representation, which we haven't yet done.
>
> --
> Alan Eliasen
Begin forwarded message:
> From: Svetoslav Markov <smarkov@xxxxxxxxxx>
> Date: June 28, 2010 1:47:11 AM CDT
> To: Michel Hack <hack@xxxxxxxxxxxxxx>, <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: inf-sub vs mid-rad and Motion 16
>
> Dear Michel,
>
> thank you, it seems that I did not express myself well.
> I should better say:
>
> "1) symmetric conditions have to be imposed
> on inf-sup and mid-rad ;"
>
> I am convinced that no one of the two representations should
> be given priority. Implementors should have the right to
> decide which one to use.
>
> On level one interval arithmetic is independent on
> both presentations. All operations, all relations,
> all algebraic stuctures are the same. Interval addition
> is associative independently of any presentation.
> Multiplication is inclusion isotone. Etc, etc.
>
> Any problem can be solved in both presentations,
> I beleive. And (when the standard is ready) it will be
> interesting to find out the differences, if any.
>
> Mid-rad seems to be a better presentation for computing with
> narrow intervals, while inf-sup is better for computing
> with wide intervals. There are probably many other pluses and
> minuses. In particular, inf-sup allows presentation of
> infinite intervals, which I beleive is important for "wide"
> computations, however infinite intervals are of no use for
> "tight" computations. In contrast, mid-rad allows very
> tight intervals, which are important for control of round-off
> errors, and not important for solving problems with
> wide input intervals.
>
> There is a nice symmetry between the two presentations.
> Each one has some advantages and disadvantages.
> That is why both representations should be treated
> with equal respect. To no one should be given priority.
> This is what I wanted to say.
>
> If the standard provides support for infinite intervals,
> it will be reasonable to provide support for narrow
> intervals as well. The standard should be equally kind
> to both presentations, I think.
>
> Svetoslav
>
>
> On 27 Jun 2010 at 11:00, Michel Hack wrote:
>
> Date sent: Sun, 27 Jun 2010 11:00:02 -0400
> To: stds-1788 <stds-
> 1788@xxxxxxxxxxxxxxxxx>
> From: Michel Hack
> <hack@xxxxxxxxxxxxxx>
> Subject: inf-sub vs mid-rad and Motion 16
>
>> Svetoslav Markov wrote:
>>> My vote would be yes if:
>>> 1) no different conditions are imposed on inf-sup and mid-rad ;
>>
>> Can't do, unless we revise our basic assumptions and drop support for
>> semibounded inf-sup intervals.
>>
>> Let's face it: inf-sup and mid-rad have different application domains
>> and different properties. There *is* a large common ground, namely
>> reasonably narrow intervals (neither too wide, which only inf-sup handles
>> well, nor too narrow, which only mid-rad can represent). I'm thinking of
>> basic formats here, not the various triplex forms that can do more.
>>
>> Motion 16 presents the issue in a manner that permits exploitation of
>> that common ground, as INTLAB seems to be doing rather nicely.
>>
>> Michel.
Begin forwarded message:
> From: Jean-Michel Muller <Jean-Michel.Muller@xxxxxxxxxxx>
> Date: June 28, 2010 2:22:30 AM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Motion P1788/M0016.01: No
>
> I vote NO on Motion 16, for the reason given by Vincent Lefèvre.
>
> JM
> --
> Jean-Michel Muller, directeur de recherches CNRS