Re: Motion P1788/M0015.01: Definition_of_decorations: Up for discussion
> Date: Wed, 05 May 2010 21:05:32 +0200
> From: Christian Keil <c.keil@xxxxxxxxxxxxx>
> To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> CC: John Pryce <j.d.pryce@xxxxxxxxxxxx>, stds-1788@xxxxxxxxxxxxxxxxx
> Subject: Re: Motion P1788/M0015.01: Definition_of_decorations: Up for discussion
>
> On 28.04.2010 16:40, Dan Zuras Intervals wrote:
> > And, if bigEnough is big enough to have tanh(bigEnough) = 1
> > in our working precision we have that:
> >
> > tanh(Entire) = {[-1,1],{boundedTrue,boundedSticky}}
> >
> > tanh(mostOfIt) = {[-1,1],{boundedTrue}}
> >
> > So, like I said, it kind of depends on how you got there.
> >
> > Both are obviously bounded final results but one used an
> > unbounded interval to get there.
> >
> > And boundedSticky records that.
> >
> > Nothing ominous in this case. But telling you that it
> > happened is the sticky's job.
>
> I'm not sure on this one. I cannot construct an example where this fails
> out of my head, but my problems are along the following line.
>
> The idea of the sticky part is to tell us after a series of operations
> that we encountered difficulties and that our result might be incorrect.
>
> In the above example tanh(Entire) we know that the result of tanh is
> bounded irrelevant of what happened before. We keep the sticky part set
> and continue computations with ([-1,1],(boundedTrue, boundedSticky)).
> Even if we don't set boundedFalse again we'll arrive at some result with
> boundedSticky set. This says "look out, you cannot trust this result if
> you need boundedness". But in reality everything is fine since the tanh
> sort of got rid of the unbounded points (points for which boundedFalse
> is true). Aren't we throwing away good results this way?
>
> I have the feeling that the somethingSticky property of an operation
> depends on the operation itself and shouldn't be set to
>
> > 'thingy'Sticky =
> > 'thingy'False(xx) \or 'thingy'Sticky(xx) \or
> > 'thingy'False(yy) \or 'thingy'Sticky(yy)
>
> in all cases.
>
> Christian
Christian,
These are all post motion 15 issues that I have yet to
address in any coherent way. Still, motion 15 seems
to bring all this out in people so...
First, I interpret sticky decorations a bit differently.
The appearance of something like continuousSticky or
domainSticky (aka definedSticky) or, in this case,
boundedSticky (aka finiteSticky) does not tell me that
I cannot trust the result. It WARNS me that I MIGHT not
be able to trust the result. Something funky happened
in computing this result &, rather than set some global
flag, we decorate the result with a sticky indicator to
allow it to be remembered. Its appearance may or may not
indicate trouble but it should be considered rather than
forgotten.
Next, since I posted this fragment, John has cautioned
me that I should not be using the word 'bounded' to
describe this potential decoration. And I have come to
agree with him. The name should be closer to 'finite'
but that still does not quite get the intent. Perhaps
'range' is better.
The intent is to track whether or not an interval could
be accurately computed with finite endpoints at each
step in the course of a calculation. John also points
out that this is an entirely unnecessary decoration if
the intent is to know whether or not the result was
finite. After all, one could merely look at the
endpoints or apply a predicate like isFinite() to
it if that was all that is of interest.
But that is not all I have in mind. And this is much of
the reason why I postponed any discussion of specific
decorations until after motion 15.
You see, this is all wrapped up in a larger notion I
have in mind about tracking the accuracy of a computed
result. Both excessive roundoff error & overflow may
be thought of as special cases of loss of accuracy.
The former is due to representing numbers with a finite
significand field (insufficient precision) & the latter
with a finite exponent field (insufficient range).
So the appearance of finiteSticky (or rangeSticky or
whateverSticky) is intended to warn that your underlying
floating-point system had insufficient range to accurately
represent the result. That may be OK, in the case of
tanh(Entire) versus tanh(mostOfIt), or it may be necessary
to repeat the calculation in some larger floating-point
system with wider range to accurately compute the interval.
That is my intent.
But it is what motion 15 is LEADING TO not part of
motion 15 itself.
You see, at the time I wrote motion 15 there were 2
issues extant: (1) could we define, manage, & propagate
decorations in a uniform manner & (2) what are those
decorations. I thought I had solved the former in a
relatively non-controversial manner. And I am still
working on the latter. So I proposed the former &
withheld the latter. Perhaps I should have waited.
But I still think these are separable issues so I'd
like to go ahead with motion 15 before I start a
discussion of specific decorations.
After all, if motion 15 does NOT pass, any work on
specific decorations is likely wasted.
I hope not... :-)
Dan