[std-interval] cset theory as fundamental

[first.i.last at comcast.net]

 -------------- Original message ----------------------
From: "R. Baker Kearfott" <rbk at louisiana.edu>
> Guillaume, Lee,
> 

[...]

> I quote from the "Example Specifications for Interval Verions
> (sic) of <cmath> Functions:"
> 
> "A more aggressive interpretation of the compatibility
> requirement is that the result of an interval version
> of a <cmath> function is the hull of all  of the results
> that would be generated by the non-interval version
> of the function if it were fed every combination of
> non-interval arguments implied by the argument intervals."
> 
> I agree with the above as a guide for specification of interval
> functions.   More precisely, John Pryce's cset theory clarifies
> this statement in limiting cases. 

As I understand the cset theory it contains only the numeric function results (including +/-inf) and does not address the issue of a function whose return values could be NaN.

In addition the cset theory appears to apply to the mathemetically correct value is if computed with arbitrary precision, while the above was intended to propose the inclusion of the result computed by the coresponding finite precision floating point implementation.  The mathematically correct result and the floating point result are usually not identical.
 
> 
> Also, I suggest the the modification, "contains the hull," rather
> than "is the hull."  To demand that it be exactly the hull may be
> too difficult in some cases.

I understand the issue, but stand by the proposed criteria in the sense that it sets the desired standard.  IFF there are cases that are too hard/slow they should be described in some way as exceptions from the normal/general expectations.  Those exceptions should be implementation defined.

The rationale we used for propsing that standard is that "contains the hull" (of the floating point implementation) is quite a general permission for bluntness.  The existence of that permission tends to erode the confidence of new users.  Like maintaining a public bug list demonstrates the confidence of software develpers and builds confidence in the sofware users (that they will not be blind-sided), so too do explicit bluntness specs demonstrate the confidence of the implementors and build confidence in the interval users that they will not get useless results.

This may be more of a sales issue than a correctness issue.  But there are a very large number of users who need to be convinced that intervals are worth considering as a replacement for floating point.

> In your parlance, "white lies" (meaning
> that the returned result isn't the exact range to within roundout,
> but merely contains it) are less destructive from a logical point
> of view than "outright lies" (where there are values in the range
> that are outside the returned result).  The coiners of the idea
> "thou shalt not lie" in conjunction with interval arithmetic meant
> that the returned result contain the mathematically correct result.
> In limiting cases, what is the mathematically correct result is
> specified, at least partially, by cset theory.  (There are also
> other considerations, such as extending acos to acos_rel, as 
> Guillaume suggests.)

Understood.  My version of the proposal is clearly out of date with respect to relational extensions (2005-08-01).

> 
> If I understand "twin," you envision it to hold two results,
> such as returning [-\infty,-1] .union. [1,\infty] as the result
> of [1,2] / [-1,1].  I can see a use for that.  However, there is a
> "twin arithmetic" in the interval literature that is something else,
> so I would recommend using a word other than "twin" in this context. 

OK.  Good point.

> I also recommend, if we go this route, that the actual
> results returned be set based on the cset theory.

What is it about disjoint results in particular that recommends the cset theory over the alternative classical interval theories?

-- Lee Winter