Re: about emp, mult by zero, exact results, exact endpoints.
what would sin( [NaN,NaN; ill]) be? [-1,1; what decoration???]
what would sin([NaN,NaN, emp) be? [NaN,NaN; emp] ???
From a programming standpoint, at least one way of implementing
multiplication
would not work the way you suggest. If one does not have directed rounding
per 754 but has to bump up and down, the results of rounding to nearest,
0*gg rounded up and 0*gg rounded down will differ and the result will
not be [0,0],
but [-eps,eps] for eps=smallest non-zero value in the chosen type (e.g.
2,2..*10^-308 for double).
On the other hand, multiplication by a SCALAR INTEGER 0
or by a SCALAR float 0.0 could arguably result in something else.
For example, 0* [a,b] could result in a SCALAR INTEGER 0, 0.0d0*[a,b] could
result in a scalar double-float 0.0d0. These would presumably not be
decorated.
I know that some computer programming languages do not allow the type of
returned
result to vary in this way, so perhaps the interval concept should be
strengthened
to allow for intervals of the form [a,a;EXACT].
This would allow the representation of any "small enough" integer
as well as any rational number of the form r/2^s for "small enough r
and s.
In those languages that allow exact rationals of arbitrary size, an
operation that results in rational
endpoints is not widened by bumping up or down; they are EXACT. I am
personally unconvinced
of the utility of having rational numbers of arbitrary precision as
interval endpoints, but it makes
sense mathematically.
This could be extended for those systems that provide access to the IEEE
754 INEXACT
flag. That is, if there is no INEXACT operation (i.e. no rounding) in
an interval arithmetic
operation, the results are again EXACT.
I don't know if [a,b,EXACT] where a and b differ is especially more
useful than [a,b,;DAC].
Again, I don't know if this has been discussed previously. apologies for
possibly making a
complicated system more complicated.
Richard Fateman
On 2/12/2013 12:13 AM, John Pryce wrote:
Guillaume
On 8 Feb 2013, at 06:05, Guillaume Melquiond wrote:
Let me quote you the relevant parts of 8.8.6:
"w_dw = phi(v_dv)" where v_dv is a box "v_dv_1, ..., v_dv_k"
"w \subseteq Rge(phi | v)" (23)
"p_dv_0(phi,v)" (24)
"dw = min(dv_0,dv_1,...,dv_k)" (25)
"where the minimum is taken with respect to the propagation order dac >
def > trv > emp > ill" (26)
As you can see from (25) above, the decoration dw of the output can
never be improved so that it becomes higher than the decorations
dv_0, ..., dv_k of the inputs.
Yes, that is true according to the current text. I have held to that principle for some time, partly for conceptual simplicity, partly because Nate strongly supported it.
But I think we should allow it to be varied. The simplest example is multiplying by a known zero, somewhere in an expression, so
f(x) = c*g(x) where c=0
Interval evaluation will do
ff = [0,0]*gg
and if gg has a better decoration than trv, surely ff should be given the best decoration, so com if supported? So def or dac can -> com.
Another IMPORTANT situation is the case(c,g,h) function where Dmitry has pointed out the 8.8.6 rules are incompatible with the intention that one can "streamline" case(cc,gg,hh) by not evaluating hh [resp. gg] if cc<0 [resp. cc>=0].
John Pryce