Re: Motion on ``discontinuous'' decoration bit
John and all,
On Sep 1, 2010, at 3:39 AM, John Pryce wrote:
>
> But this email is about another point in these discussions.
>
> Being stubborn, I persist in thinking that it would be useful IF it were possible to specify a function as being explicitly "an interval extension of a point function" so it contains NO intersection and union operations. Let's call such an f an IEPF.
If we adopt something like that, what ARE intersect(), union(), hull()?
>
> - The semantics of the ``discontinuous'' decoration bit in an IEPF are simple.
> - In a non-IEPF, they are analysable but MUCH more hairy.
> - There are important cases where an algorithm expects an IEPF, e.g.
> the f(x) and f'(x) in interval Newton,
> the f in y' = f(t,y) for validated solution of ODEs.
> - Often, the f is provided by an application user and passed as an argument to library code for solving f(x)=0, y'=f(t,y), etc. Anything that helps the library code check validity is useful.
It seems to me there are two extremes:
1. Mathematician: A "function" is what we teach in calculus. Your IEPF.
2. Coder: A "function" is anything I can code, including by AWFUL coding practices.
For example, I could assert that
function f(x) {
return 1.0;
}
Is an implementation of f(x) = 1, if x is machine-representable; 0 otherwise. I do NOT expect to handle that automatically.
Another of my favorite "OH S**T" examples for automatic differentiation:
f(x) = integral_0^x g(t) dt
Compute f'(x), for general g(t). Perhaps half my sophomores can do that :-(
Oh, my implementation of integral() is a state-of-the-art adaptive quadrature code. No AD technique I know returns g(x). Piecewise, yes, but not the mathematically correct answer.
Relevant here is that although f(x) is a IEPF, my implementation is not, even if I use only "good coding practices."
I ABSOLUTELY agree IEPFs are easier to handle. We should handle them correctly.
I submit that, like the AD folks, we should accept the "anything I can code" as a goal, AND accept that we will sin and fall short of God's grace.
> My Question:
> Is "specifying a function as an IEPF" any business of P1788?
If we do, don't we still HAVE to address intersection(), union(), and hull()?
>
> As far as I can see this has to be done at the language level. One analogy is the way one can specify a function as PURE (basically "no side-effects") in Fortran 95, which imposes various compiler-checkable restrictions, see e.g.
> http://dacnet.rice.edu/versions/hpf1/hpf-v10/subsubsection2_5_3_1_1.html
>
> As another analogy I gave (copied below) the way the NAG CompAD Fortran compiler specifies a function as "to be differentiated".
> - George said he doesn't think much of language extensions, as used there. (Nor do I.)
> - Nate said he could think of dozens of ways to achieve the same effect.
> (I can think of several, doubtless far fewer than Nate can.)
> That's not the point. My point is
>
> Is this sort of language-related issue IN PRINCIPLE something P1788 should get involved in?
>
> IEEE754-2008 explicitly treats language-related issues in §10. IMHO, P1788 should not shy away from it. As I'm a math nerd, one of my reasons is to make correctness proofs of P1788-conforming code easier to achieve.
My "I only have finite time" conscience says, "NO!", but your argument is convincing. I suppose so. Sigh.
George