Re-revised Clause 7 "Flavors", hopefully ready for vote

[John Pryce <j.d.pryce@xxxxxxxxxx>]

P1788

Here is a new draft of Clause 7 "Flavors". I think the ideas are now made firm. There may be minor changes because of poor wording - please read with care, and complain about any obscurities. But I believe this text is ready to proceed to the vote.

The main changes are:

1. A thorough revision of §7.5.3 "Level 2 operations". Following Vladik's 
  support for my thesis that "uncertainty is essential", the possibility
  that an implementation may be unable to decide certain facts, because of
  algorithmic constraints, is made an inherent feature of Level 2 in any 
  flavor.
  
  For example the description (7.5.3 item 3(b)) of how the T-version phi_T of
  an operation phi with decorated-interval result is handled now says
 
>   If [the Level 1 result is found to exist and] is a decorated interval y_dy there are 
>   three cases.
>   - If phi is an arithmetic operation, and [the input box] is a decorated
>     common input (this implies dy=com, see §7.4.2), and a common T-interval
>     z containing y is found, then phi_T returns such a z with the decoration
>     com. 
>   - Otherwise, if a T-interval z containing y is found (in particular if
>     Entire exists in the flavor and is a T-interval), then phi_T returns
>     such a z with a flavor-defined decoration. 
>   - Otherwise, no such z is found. Then phi_T signals the IntvlOverflow
>     exception and the returned result, if any, is flavor-defined.

  Here "is found" is defined to mean that the implementation is able to compute
  a value, or determine whether a fact is true.

  In the first of the 3 cases above, I've kept the requirement that the returned
  decoration is "com" -- not a possibly weaker decoration, as suggested by Michel.
  This is because it seems to me all the bases have been covered:
  - The input *is* a decorated common input box, meaning its components are common
  intervals decorated "com". I said "is", not "is found to be", because I can't
  conceive a flavor, type or implementation, where it is difficult at run time to
  decide if a given interval is common or not. Is that reasonable?
  - The common z containing y "is found" by the implementation. So at this point all
  uncertainty has disappeared, and there is no reason to return a weaker decoration.

  The terms "decorated common evaluation" and "decorated common input" have been made
  Level 1 (not Level 2) notions, put in 7.4.2. The subsubsection after 7.4.3 that used
  to define them has been removed.

2. I have changed the exceptions "IntvConstructorFails" and "IntvConstructorUnsure" to
  "UndefinedOperation" and "PossiblyUndefinedOperation" throughout the text, for the
  reasons I stated before.

There are various issues of conformance and documentation that I would also like you to check and ponder. E.g. at the start of 7.5.3:
  "the flavor SHALL give a rule ..." about T-versions of flavor-specific operations;
  "The flavor SHOULD make recommendations or requirements" about the number formats
  use for numeric results of operations.

Should these be there at all? Should the "shall" become "should" or vice versa? Are there other places where the standard should require a flavor to specify things, but currently doesn't? I know these are "meta-questions". I know flavors are in many ways a nuisance. I know it seems 1788 won't contain any Kaucher flavor for the present. 

But we have flavors, and we should get them right. And I remain convinced that flavors will in the future turn out to have been worth the effort of inventing them.

Regards

John Pryce

Attachment: 20140203Flavors.pdf
Description: Adobe PDF document