Re: about emp (was: Motion 42: NO)
Le mardi 12 février 2013 à 08:13 +0000, John Pryce a écrit :
> 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].
I think it is important to keep the propagation rule, as it is concise
and covers all the case of arithmetic expressions. However, it could
perhaps be generalized a bit. For instance, rather than taking the
minimum of the decoration of all the inputs, one could instead take into
account only the inputs that have an actual influence on the output.
As a consequence, since the result of case(cc,gg,hh) with cc<0 does not
depend on hh (for cc and gg fixed), the result would not take its
decoration into account. The situation is similar for [0,0]*hh.
This is just a suggestion on how to adapt the current scheme to your
proposal; I am not advocating it (nor against it).
Best regards,
Guillaume