[Cfp-interest 3200] Various Updates to Annex F+G

[Damian McGuckin]

I have started a new thread to handle the preliminaries for the various 
sub-proposals.

Apart from the one error in Annex F which incorrectly says that -INF is 
odd integral (it is even), most of the changes I am suggesting in Annex F 
and Annex G revolve around the fact that most of the special cases satisfy 
(and can be easily massaged to satisfy) the following syntax. By following 
the same syntax, the readability of all these cases is enhanced, and it 
becomes a lot easier to understand and also to compare special cases (if 
the need arises). It also helps eliminates the spurious commas that are 
all over the place.

If I could badly use the syntax of John Bacchus and Peter Naur, a BNF
syntax of each special case is:

     <function-name> ( <arguments> )
     [ STORES <value-expression> INTO <pointer-name> ]
     [ RETURNS <result> [ FOR <domain> ] [ ( <comment> ) ] ]
     [ RAISES <floating point exception> [ WHEN <scenario> ] ]

Square brackets surround each optional clause in the above statement
although there is always at least one such clause. So not strict BNF.

Also:

     FOR is the lower-case keyword 'for'

     WHEN is the lower-case keyword 'when'

     AND is the lower-case keyword 'and'

     RETURNS is the lower-case keyword 'returns'
     - it may be preceded by AND for reasons of English grammar

     RAISES is the lower-case keyword 'raises'
     - it may be preceded by AND for reasons of English grammar

     INTO is the lower-case multi-keyword 'into the object pointed to by'

And

     A <scenario> limits when a floating point exception is raised being
     - a combination of a <domain> AND a <result>
     - a normally tiny subset of the domain of <function-name>

     A <comment> is explanatory text associated with the <result> or domain
     - the brackets around <comment> have nothing to do with normative text
     - it is free format

     A <result> is the return value of <function-name>
     - it is normally a mathematical expression but ...
     - it may be floating point classification, e.g. NaN, infinite, zero,
     -- in this case, it is normally introduced with the word 'is'

This is an enhancement of what I used in the earlier document which now 
addresses that problematic case we saw a few hours ago with the text:

 	nextafter(x, y) raises the "underflow" and "inexact"
 	floating-point exceptions when x != y and the function value
 	returned is either subnormal or zero.

For now, I will focus on Annex F which are, apart from that one error, are 
editorial in nature and involve moving words from one place to another to
improve readability.

- Damian