| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
George, P1788
On 30 Aug 2010, at 22:36, Corliss, George wrote:
> For several days, there has been a VERY active discussion going on among several people, and it should be exposed to everyone. Unfortunately, you are being brought into the middle of the discussion, and I'm not willing to summarize all that has gone before. Basically, we have been discussing Motion on ``discontinuous'' decoration bit. Much of the discussion has been on decorations for the results of intersect(), union(), and hull(), which are NOT interval extensions of point functions.
Thanks George. I think the email you've circulated contains the nub of what we understand at the moment about this issue. I send herewith the position paper I sent to the smaller group on 21 Aug; look at if interested, and bin it, as I aim to send out a revised version soon.
I agree entirely with Nate's
> BTW, I agree about KISS and comments about complexity. This is why I strongly recommend trying to whittle the actual definitions down to something as minimalist as:
>
> -- Level 1 definition of "defined and continuous" for a point function,
> i.e., C(f,a,x) as John gives in his paper
>
> -- Level 2 exception-handling propagation mechanism, i.e.,
> p1 & p2 & C(f,a,x1,x2)
> for point functions of form f(x1,x2) and just
> p1 & p2
> for intersection and union.
(One correction: C(f,a,x) should be C(f,x) since the "a", which ranges over the input box x, has been "quantified out" by a "forall a in x" when we get to this point.)
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.
- 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.
My Question:
Is "specifying a function as an IEPF" any business of P1788?
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.
Members of P1788's Expression Rearrangement subgroup, I especially welcome your views.
John Pryce
------------------------------
Attachment:
JDPdiscontinuousbitV1.pdf
Description: Adobe PDF document
NAG CompAD Fortran compiler example. Taken from the paper at http://www.stce.rwth-aachen.de/classes/AMSNP/papers/compad_tour.pdf On 29 Aug 2010, at 21:03, John Pryce wrote: > PROGRAM example_1 > USE ACTIVE_MODULE > IMPLICIT NONE > DOUBLE PRECISION :: x, y, u, v, jac(2,2) > TYPE(JACOB_TYPE) :: grad_u, grad_v > > DIFFERENTIATE > INDEPENDENT(x,y) > u=x*y > v=x/y > grad_u=JACOBIAN(u) > grad_v=JACOBIAN(v) > END DIFFERENTIATE > > CALL DERIVTOREAL(grad_u,jac(1,:)) > CALL DERIVTOREAL(grad_v,jac(2,:)) > WRITE(*,*) " Jacobian = ", jac > > END PROGRAM example_1 > > Here you see a function written entirely inline within the main program, but the DIFFERENTIATE ... END DIFFERENTIATE syntactic block together with the INDEPENDENT statement, which are language extensions, say where the function starts and ends and what it's a function of, hence what initialisation of derivative information is required, and when. > > The syntactic structure to specify a function as "an interval extension" is VERY similar. The semantic structure is also very similar, though the detailed semantics are obviously different.