Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Re-revised interval flavors motion (36.03 !!)



Vincent & P1788

On 31 Jul 2012, at 14:49, Vincent Lefevre wrote:

> On 2012-07-30 19:10:13 +0100, John Pryce wrote:
>> My conclusion is that to make flavors work, 1788 should specify a common 
>> set of intervals, and a common set of opinsts, and require all flavors to 
>> agree on these. But not make requirements beyond this. 
> 
> I disagree (this is not what was decided at the end of the discussion).
> 
> The problem with this choice is the following: the standard needs to
> specify requirements and recommendations for arbitrary functions (as
> interval extensions of math functions) provided by an implementation
> as part of the library (a bit like what IEEE 754-2008 does in its
> section 9.1, about conforming language- and implementation-defined
> functions).
> 
> For instance, a requirement would be the containment property. There
> would also be requirements and recommendations concerning the accuracy.
> And requirements about flavors are needed too. Thus instead of listing
> a set of opinsts that would be specific for each function, the standard
> needs to give a rule from which one would deduce the set of opinsts.
> The rule you gave at the end of the discussion was: "the operation is
> defined and continuous at each point of its input box". And the rule
> should be simple enough so that the standard makes easy to implement
> new functions from a minimal library.

I take your point. I was trying to state a general principle about flavors, before giving an explicit definition of the common sets of intervals and opinsts. However, "But not make requirements beyond this" is too vague, and doesn't express the very limited scope of "not making requirements" that I was intending.

Yes, it is *essential* to state a rule from which the correct set of opinsts can be deduced for each new point arithmetic operation that may be put in the library. And such a rule must ensure containment and the FTIA. The rule that I gave (about continuous on the input box, and exact range) does both of these. More precisely, it ensures the FTIA holds for an arithmetic expression-evaluation that only involves common opinsts.

Should the motion say explicitly that each flavor shall ensure a version of the FTIA holds, which is appropriate for its kind of interval and reduces to the classical FTIA (of Moore) in the "only common opinsts" case?

> Also, this was not discussed, but I think that an operation that is
> not an interval extension of some math function shall not depend on
> the flavor (at least if the result is in the common set).

I take it you mean an operation that takes interval(s) to an interval. And you mean intersection and convexHull. Yes but... There's no way to state that as a *requirement* in the abstract, without implicitly making one flavor the "daddy" that others must conform to -- which I'm trying to avoid. So I think it's better to define them explicitly on the set of common intervals.

> I wonder
> what the intersection of X=[0,1] and Y=[2,3] should be in the modal
> flavor...

It's [max(xlo,ylo), min(xhi,yhi)] = [2,1], I believe.

Waiting for Vincent's and anyone else's response, and I will rewrite the affected paragraphs.

John