Re: Revised version of Level 1 text (draft)
> From: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
> To: "John Pryce" <j.d.pryce@xxxxxxxxxxxx>
> Cc: "P-1788" <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Revised version of Level 1 text (draft)
> Date: Tue, 10 May 2011 18:35:48 -0500
>
> John Pryce wrote:
> > Nate
> >
> > Checking your quadratic convolution kernel example as best I can, I agree
> > that with xx=[1/5,1] you get h(xx) = ([-1/4,7/8],D3). The given h(x) has
> > continuous first derivative on the whole line, so D3 is telling the truth.
> >
> > But suppose thanks to a typo, my h(x) is discontinuous: say, I mistakenly
> > write 9/4 for 9/8 in the formula. I STILL get decoration D3 on the answer
> > don't I? What is your D3 telling us? Or is the onus entirely on the
> > programmer to get the code right?
>
> I've pondered that as well. These are my thoughts:
>
> Two facts to keep in mind: a) the function h is piecewise-defined and b)
> C(f,X) only tells us the truth (by definition) about the restriction of f to
> X over those pieces. So careful scrutiny to the definitions I believe shows
> that decoration D3 is still the truth. In other words, no claim is being
> made by the decoration about the global continuity of h.
>
> It might be nice if IEEE 1788 could act as a "math spell-checker" and make
> stronger claims about the global continuity of h, but I'm not sure from an
> implementability point of view that would be very realistic. So for better
> or worse, if such global information is important to the programmer, I think
> the onus is on him/her.
>
On the one hand, Nate's argument here has the merit of
being simple & available for hardware implementation.
On the other hand, it is a statement about the nature
of the IMPLEMENTATION of a function not the function
itself.
Were there a way to express the function without the
break in domain the issue (& answer) would be different.
And this is potentially a big issue now that many if
not most library functions these days are implemented
as piecewise (hopefully continuous) approximations on
many tiny domains.
I think I would rather find a way to decorate with the
truth about the function than hide behind a convenient
line of reasoning.
Still, it may turn out to be a difficult thing to do.
Dan
P.S. - Let me suggest that it is possible that these
issues do not really arise in 'natural' uses of union
& intersection. The examples given so far (including
mine) have been of functions that could be implemented
as point functions that are generalized to interval
functions in the usual way. Set theoretic operations
are not needed.
I am more interested in the 'natural' uses of set
theoretic functions. In the case of intersection,
they seem to involve deriving an interval for which the
properties of both operands are true. In the Newton's
iteration:
given xx(k) & xmid (the midpoint of that
interval, we compute:
xx(k+1) = (xmid - f(xmid)/ffprime(xx(k)))
\intersect xx(k)
That is, we seek a new interval that is contained in
BOTH the old interval & the image of that interval
under Newton's map.
I'm not sure if this suggests that the decoration should
be the best (safest) of the input decorations as Nate &
John have discussed. But it is a reasonable suggestion.
I would certainly agree in the case of union (something
that seeks the truth about EITHER of its operands) but
I'm a bit more iffy about intersection.
Let me ask of the assembled lurkers if there is some
optimization problem that seeks to find a point (or
interval) where two distinct things are true. Something
for which the natural interval extension might be
thing1 \intersect thing2. Something more revealing
than the Newton's example.
Can anyone present us with such a problem to serve as
a guide in answering the decoration question?