[std-interval] Draft standard based on csets

[George Corliss]

Sylvain,

Thank you for your response.  The ISL team is meeting this week in
Milwaukee.  We will be working on further clarifications  One of the
suggestions of Lee Winter is that we construct a model which is subset-able
in the sense that by omitting certain features, you get recognizable, valid
systems for interval arithmetic.  For example, one subset of the theory
might be "simple," and one might be "cset."  We are working on such a
unification, so far without complete success.  We even think there is some
hope that the unified theory might be simpler in the sense that it is more
general.  Work continues.

George Corliss

> Dear George and the ISL team,
> 
> I have read through your modified proposal as well as your cset paper.
> They contain interesting ideas, and many should be integrated in
> the final proposal.  As far as I understood them, it seems that many
> of these ideas are orthogonal to csets, so, for the purpose of
> discussion here, it would be nice to consider them separately.
> In this mail, I will focus on the cset model itself.
> 
> As far as I understood, the cset approach is mostly motivated by
> the needs to handle :
> 1- discontinuity of functions (e.g. division by zero)
> 2- construction from floating-point infinity
> 3- re-association capabilities
> (am I missing other important ones ?)
> 
> In practice, the cset model implies that intervals are enlarged so
> as to verify new properties.  To define the cset functions, you have
> to look at how the function is defined outside the input intervals,
> and take all possible limits of values of the function outside the
> intervals. (forgive the short imprecise summary).
> 
> This produces "strange" effects, like :
> - [0;+inf]*[0;+inf] returns [-inf;+inf], whereas "the simple" model
>    can simply return the more "natural" [0;+inf].
> - 1/[0;1] returns [-inf;+inf]  ([1;+inf] for the "simple" case)
> - sign([0;5]) returns [-1;1] ([0;1] for the "simple" case)
> You mention these effects in your paper, although you do not really
> propose a way to take care of this.
> 
> I understand that the cset model brings in some consistency, which
> is a most definitely desired feature.  But it does not come without
> constraints.  I am also not convinced that the same kind of consistency
> cannot be achieved using a non-cset model.
> 
> The main question I have is that I do not find convincing arguments,
> in practice, to justify the cset model.  For example, the wrap-around
> model is nicely motivated by functions like : f(a,b) = 1/(1/a+1/b).
> I miss the equivalent for csets.  I believe that, in the 3 main
> reasons listed above, 1- and 3- can be specified in a non-cset model
> as well (by a non-cset or "simple" model, I mean a model which does
> not have to take into account values of functions outside the input
> intervals, this is the most distinctive feature of cset, and the most
> problematic to me).
> For 2-, I am not sure yet what to think, but I hardly see this as a
> reason to justify the cset cost anyway.  I see this cost as :
> - larger intervals
> - slightly slower implementation
> - more complicated definition/specification
> 
> 
> As far as the proposal is concerned, we can still propose several
> models.  The std::interval could have a policy parameter specifying
> the model.  If we do that, we add a lot of complexity to the proposal,
> which really needs to be motivated.  We are already not considering
> the integration of a wrap-around model or Kaucher model (is it a
> mistake ?).  I believe that most people care about speed and tightness
> of the intervals, so if we need to choose one model, my current
> personnal opinion is that a (well-defined of course) non-cset is
> the best choice.
> 
> 
> I would be more than happy to read opinions of interval experts on
> this issue.  Concrete use-cases requiring csets would be a must.