Re: The definition of cancel_minus
Walter and all,
> What is the rational behind the standard's choice?
I suppose that the reason has been: all operations defined by the
Standard are outwardly rounded.
> In which (practical) use cases this difference
> in Definitions I and II would be relevant?
Both outwardly rounded and inwardly rounded operations are used in the
applications.
In general, these operations have the property that inwardly rounded
result can be obtained by outwardly rounded operations (and vise versa)
in a particular way (see doi:10.1016/j.cam.2005.08.048 formulae (8), (9)).
The problem is that the cancelPlus/Minus operations defined by the
Standard are half of the actual “inner” operations defined in Motion 12
“Inner Addition and Subtraction” (see
http://grouper.ieee.org/groups/1788/private/Motions/Motion12.02.pdf)
which was the background of these operations. This hampers the
applications (as discussed in a recent paper DOI:
10.1007/s00419-016-1180-2).
I use the present discussion to announce the latter recent paper DOI:
10.1007/s00419-016-1180-2 (free access at http://rdcu.be/kofz) which was
motivated and clarifies the discussion raised by Mazandarani,M.: IEEE
standard 1788–2015 vs.multidimensional RDM interval arithmetic, in this
working group in Sept./Oct. 2015, see
http://grouper.ieee.org/groups/1788/email/msg08439.html.
Best regards,
Evgenija Popova
>
> Dear colleagues,
>
> I am implementing the function cancel_minus
> and I do not understand the rational behind
> its definition in the standard. In the "normal case"
> (ie. non empty and bounded intervals) section
> 10.5.6 of the standard states that
>
> Definition I: cancel_minus(sum, parcel) = tightest interval c
> such that parcel + c contains sum.
>
> In my opinion, the definition should be
>
> Definition II: cancel_minus(sum, parcel) =
> (the convex hull of) the union of all intervals c
> such that parcel + c is contained in sum.
>
> Definition (II) is what we need if we want
> to recover the interval c when are only given
> a computed sum and a parcel, as in
> the example mentioned in the standard:
> we are given a computed sum = SUM_{k=1}^n a_k
> and a_j and want to recover SUM_{k != j} a_k.
>
> In practice, given only the parcel and the sum,
> we only know that a candidate c to
> cancel_minus(sum, parcel) satisfies
> "parcel + c is contained in sum",
> because, in practice, sum will be slightly
> larger than the exact sum, and this is what
> I would want cancel_minus to model in theory.
>
> Therefore, it would be natural to take
> cancel_minus(sum, parcel) as the union of all
> such c (and take the convex hull just in case
> this beast is not convex,) Both in theory
> and in practice the actual c used
> to generate the sum is certainly contained in
> cancel_minus(sum,parcel) in Definition II.
>
> Definition II has the advantage that, at level 1,
> the resulting cancel_plus is always well defined,
> because the empty interval e satisfies
> "parcel + e is contained in sum" and the
> union of intervals in this definition is taken over
> a non empty family of intervals.
>
> Definition II differs significantly from Definition I
> when sum is shorter than parcel, and they are both
> not empty. In this case, at level 2, Definition II
> leads to an empty cancel_minus whereas the item
> 12.12.5 in the standard yields cancel_minus = entire.
> What is the rational behind the standard's choice?
> In which (practical) use cases this difference
> in Definitions I and II would be relevant?
>
> Following Definition II we could derive
> the results in non normal cases. For
> instance, we would obtain, at level 1,
> that cancel_minus(entire, parcel) = entire. This
> result is natural but in conflict with what is
> described in item 10.5.6 of the standard,
> but this time the results match at level 2.
>
> With Definition II we can also handle
> meaningfully half infinite intervals, as in
> cancel_minus([0,+oo], [0,1]) = [0,+oo],
> whereas the standard leads to
> the less desirable result
> cancel_minus([0,+oo], [0,1]) = entire
> at level 2.
>
> What points am I missing?
>
> regards,
>
> walter.
>
>