2006.08.29 style review follow-up

[Mike Cowlishaw <MFC@xxxxxxxxxx>]

From 2006.08.29 style review I had two to-dos:

a) Rephrase 7.1 para 2 to make it more general.  Here is the current
   text:

     In this standard, some operations such as
     fusedMultiplyAdd(x,y,z) and predicates such as isNormal(x) are
     written as named generic functions due to lack of
     widely-accepted operator notations; in a specific programming
     environment they might be represented by operators, or by
     families of format-specific functions, or by generic functions
     whose names may differ from those in this standard.

   Here's my suggestion (after thinking about it, there doesn't seem
   to be any particular reason to give an example):

     In this standard, operations are written as named generic
     functions due to the lack of widely-accepted operator notations;
     in a specific programming environment they might be represented
     by operators, or by families of format-specific functions, or by
     generic functions whose names may differ from those in this
     standard.

b) In 7.3.1 check and simplify wording for the description of nextUp
   and in particular the exponent calculation.  The second-to-last
   and penultimate sentences are currently:

     Within the cohort of x, that member of least exponent is used to
     compute nextUp(x), and consequently nextUp(x) - x is minimized.
     Within the cohort of nextUp(x), the result is also the member of
     least exponent.

   These first of these is redundant and somewhat misleading (x does
   not need to be changed), so I suggest deleting that.

   The second sentence is also redundant and can be deleted if we
   change (at the top of the next page, currently):

      The preferred exponent is Q(x).

   To:

      The preferred exponent is the least possible.

   (The sentence "nextUp signals no exception..." is unchanged.)

   Also, I would keep 'nextUp' in that form a couple of sentences
   earlier (i.e., no initial capital).

Mike