Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

New Motion: Accept rewritten §6 "Expressions ..."



P1788

This is just to state, separately from my last, that I submit this motion:
Motion==============================================
Clause 6 "Expressions and the functions they define" 
be accepted as standard text.
====================================================

Rationale. 

This clause is central, since it aims to explain why and how interval arithmetic is actually useful for getting enclosures. It is in Chapter 1 because if one sticks to common intervals the conclusions apply to all flavors. (Nate Hayes' recent document shows how much more complicated and subtle the FTIA becomes, in the Kaucher flavor.)

We used to have a formal definition of "expression", offered by Arnold Neumaier. It was essentially the "algebraic expression" in the current §6.

Then, as part of migrating this material to Chapter 1, I had (re)written this with an informal definition of what an expression is, on the grounds that a formal definition would constrain a language, which is not 1788's job. 

Prof Wolfram Kahl (Ned's colleague at McMaster U. and a languages expert) pointed out that this fear is misguided. The concept "expression" as used in the FTIA is nothing to do with a language - one could apply the FTIA to results of an interval program written in machine code, say. 

"Expression" in a language typically is a special case of "expression" as used by the FTIA, under some restrictions. But a serious FTIA application will have expressions made up of a number of lines of code, each containing an expression in the language-sense. And the expression to which the FTIA is applied is the one created by a particular run of the code. The computational graph - or the code list, which is essentially a linearly ordered CG - is the most insightful way to represent this.

So I rewrote it again, with more precise definitions than in the previous version.