Revised Flavors text, and Motion to accept it

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

P1788

I submit the attached revised text of Clause 7 "Flavors", with a motion:
======
This text shall replace the current version and be accepted as standard text.
======

If
- you approve this after discussion and resulting amendments;
- pass Motions 54 to 57 on Level 2;
- pass Motion 59 on Level 3;
- come to a decision on other outstanding motions;

then I believe the main text is essentially ready to be submitted for the sponsor ballot stage.

Comments and Rationale
----------------------
Christian had already noted the need to tighten up the start of §7 to state conformance requirements precisely.

We needed to grasp the "Flavors nettle":
    To define a Level 1 -> Level 2 map, we need to introduce types.
    Do we
    (a) require every type T to be able to enclose any Level 1
    interval (essentially, Entire must exist); or
    (b) allow it not to do so, and signal the ContainmentFailure
    exception instead?
    Anyway, what does "enclose" mean in a general flavor?

Discussion so far showed support for choice (b) above and none for (a). So I've done that.

This required considerably more tightening up. Draft 8.1 of Oct 25th only had 3 items of "core behavior" for a flavor in 7.1. One must add several more, and be clearer on what is flavor-independent and what is flavor-defined:

- One must specify a flavor needs a "contains" (aka "encloses")
  relation.
- One must require that types exist.
- One must require a type T Level 2 interval operation to enclose
  the Level 1 result by a T-interval.
- One must therefore require a notion of "the" Level 1 result.
  That is, either an operation, on given inputs, has *no* value,
  or it has *one* value -- for interval-valued operations this is
  typically the tightest among various possibilities (e.g. the
  "natural interval extension" of a point operation).
- Example: intersection([1,2],[3,4]) has *no* value in classical
  Moore flavor; has *one* value Empty in set-based flavor; has
  *one* value [3,2] (improper) in Kaucher flavor.

The main resulting changes are:
- Longer list of "core behavior" at Level 1, rearranged somewhat.

- More careful definition of "common evaluation". It was rather
  unprofessional before, since it really only covered operations
  that only have interval inputs and output.
  We have to cover interval, real, boolean & string.
  The new version is better, but still incomplete/careless
  in places. *Please check*.

- For simplicity, 7.3 now says the flavor embedding map (gothic-f)
  is generally omitted so IR is regarded as being a subset of F,
  the flavor's intervals.

- New 7.4, saying that what "non-common" evaluations exist is
  flavor-defined, and requiring *no* or *one* value at Level 1.
  So the "Level 1 result" shall be well-defined if it exists.

- The term "widened common evaluation" removed; it was easier to
  do without it.

- New 7.5 requiring "contains" relation in every flavor.

- New 7.6 "The relation of Level 1 to Level 2" requiring types,
  and hull, to exist.
  7.6 also gives requirements on a Level 2 operation in a general
  flavor. In particular if interval-valued it shall enclose the
  Level 1 result.
  7.6 also defines "valid" & "tightest" accuracy modes in every
  flavor, and says a flavor may define other modes, and make
  accuracy requirements.

- 8.3 "Recognizing common evaluation" tidied up and shortened 
  somewhat. (Not included in the current PDF.)

This is quite a substantial change. I apologise. But I think something on these lines is forced on us once we grasp the "flavors nettle".

If you think something in here is unnecessary, say so, with reasons.

Regards

John Pryce

Attachment: 20131202Flavors.pdf
Description: Adobe PDF document