Re: More on trits & tetrits... (long)
Michel and P1788
On 22 Apr 2010, at 15:51, Michel Hack wrote:
> Dan Zuras, Vincent Lefèvre, Dan Zuras:
>>>> We do not know whether or not an actual pole was encountered.
>>> That's the problem.
>>
>> In essence, your definition is adding one bit to the range
>> just as decorating this problem with 'exact' or 'inexact'
>> would add one bit to the precision.
>
> Actually, "Exact" adds infinitely many bits of precision. The
> Exact vs Inexact distinction also applies to Inf-as-Pole (Exact)
> and Inf-as-Overflow (Inexact).
>
> The question then becomes whether this distinction can be carried
> over from 754 to 1788 by means of decorations. This is a tall order,
> because even in 754 the distinction is not carried forward by the
> normal rules of arithmetic. For example, Inf(exact) - Inf(overflow)
> or Inf(exact)/Inf(overflow) should be Inf(exact) and not NaN -- but
> the only way to do that is to attach the Inexact flag to the datum,
> i.e. to use decorated floats -- a topic that was never addressed.
Good point.
> The float result of an operation would however depend on both the
> input floats and the input decorations.
>
> So the question becomes whether the deliberate separation...(*)
> of
> bare interval results and decorations is good or bad.
Good, say I. It was the intention of Hayes-Neumaier position paper for Motion 8 as I understand it.
Write xx.I, xx.D for the interval and decoration parts of a decorated interval. Then (*), if I understand Michel's intent, means that for ANY decorated-interval operation ff, if
zz = ff(aa,bb,...)
then this can be written the form
zz.I = ffI(aa.I,bb.I,...) I output depends only on I inputs
zz.D = ffD(aa.I,bb.I,...,
aa.D,bb.D,...) D output depends on both I & D inputs
This coupling from I to D only, not from D to I, makes correctness-proving HUGELY simpler than in the fully coupled case where I output depends on both I & D inputs.
If there exists even one fully coupled operation fc() in our whole system, then this contagion spreads across any code that uses fc(). This is why I want to get rid of the "bounded" trit, because it makes most arithmetic operations fully coupled.
Dan proposes a "bounded" with different semantics, but I wonder if it is of practical use?
John