Re: Draft: P1788.1 Standard for Interval Arithmetic (Simplified)
On 07.09.2015 21:37, Walter Mascarenhas wrote:
Dear Colleagues,
I am implementing the content of the P1788_1_MAIN.pdf file
posted by Ned and I have a couple of questions:
1) What should be returned by the interval version of the function
sign? For instance, what should be returned by sign( [-1,1] )?
Walter,
the interval version is an interval extension of the point function
(https://en.wikipedia.org/wiki/Sign_function). sign( [-1,1] ) will be
hull( {-1, 0, 1} ) = [-1, 1].
2) Regarding decorations, suppose f: R -> R is a continuous function
such that, due to rounding, f([0,1]) (without decoration) returns
[-oo,+oo] (= entire). In my reading, in this case the standard requires
that the decorated version returns [-oo,+oo]_dac.
Yes, assuming that you use the decorated textToInterval constructor on
the interval literal [0, 1] (thus making it [0, 1]_com).
Then f( [0, 1]_com ) should be [-∞, +∞]_dac.
If the restriction of f to [0, 1] was not continuous somewhere (cf. sign
function), it should be [-∞, +∞]_def instead.
If f was undefined somewhere between 0 and 1, it should be [-∞, +∞]_trv
instead.
Consider now g(x) = 2 * arctan(x) / pi. Again, I believe that
the standard requires that g( [-oo,+oo]_dac ) should return [-1,1]_dac,
Yes.
but this implies that g( f([0,1]) ) returns [-1,1] dac, and I find
this odd because g(f(.)) is continuous and (numerically) bounded
in [0,1], and due to the unboundedness of the numerical f(I)
we loose the information that I is bounded.
You could implement a function h = g ∘ f, which respects this property.
Then a user could use optimized h and everything would be fine. If g and
f are implemented separately, they must (each) strictly follow the rules.
You have this kind of errors everywhere where specialized functions can
provide better information than combined functions. For example the full
standard recommends functions like logp1: log(x + 1) because log(add(x,
1)) would be less accurate.
Please note that the difference between _com and _dac can be more than
just boundedness. With the result being _com the function must be
continuous in every point. With the result being _dac only the functions
restriction to the input range must be continuous.
For example: ceil( [0.5, 1]_com ) = [1, 1]_dac, because ceil is not
continuous in 0.5, but the restriction of ceil is.
> …
Wouldn't things be simpler if the decorations
propagated only information regarding the
relation of x and the domain of f or the set
in which f is continuous?
For instance, by removing the requirement that the
computed f(x) is bounded from the definition of com
(or having a decoration com* without this
requirement) the evaluation of g( f(I) ) in the example
above would yield naturally a com (or com*) interval,
and the users interested in information regarding
the boundedness of g( f(I) ) could obtain it by
inspecting g( f(I) ), as they will need to do
anyway under the current definition of com.
Am I missing something?
There probably has already been discussion on that behaviour. Maybe
others can provide pointers.
However, the behaviour has already been defined in IEEE Std 1788-2015
and is certainly not going to change in the simplified standard.
Best regards,
Oliver