Constructors & decorations
<<Sorry, I sent an unfinished version of this. Discard it.>>
P1788
The group has discussed interval constructors at various times and there is probably a consensus that there should be these, where REAL means an unspecified floating point type and STRING a text-string type.
nums2Interval(REAL l, REAL u) constructs [l,u] if l <= u. Vienna§2.5's standardInterval().
num2Interval(REAL x) same as nums2interval(x,x). Vienna§4.1.
text2Interval(STRING t) on the lines of Vienna §6.
Empty() and Entire() also count as constructors.
The names are provisional! And should be qualified by a destination format, e.g. nums2Binary64Interval.
Query 1. I suggest that if any of these succeeds in constructing an interval, it returns that interval and decorates it as
- isValid
- isDefined
- isContinuous
- either isBounded or notBounded, depending on whether the _mathematical_
interval defined by the input arguments is bounded or not.
Never possiblyBounded.
Whereas if it fails to construct an interval, it returns Empty (as Vienna proposes) and decorates it as
- notValid
- possiblyDefined
- possiblyContinuous
- possiblyBounded
Q: Anyone see flaws in this scheme?
Query 2. There are conversion functions to a given interval format (the F-hull, §5.2.3 of the draft standard, version 01). How should these handle the decoration of the input interval?
- They could copy it unchanged to the output. I'm dubious, but so far can't see that it can lead to disastrous consequences for any of the four trits.
- Or, an F-hull operation could be regarded as a constructor, so that its output is a "brand new" interval, decorated as in Query 1. In effect, for instance, for an interval xx of arbitrary format
binary64Hull(xx) is the same as nums2Binary64Interval(inf(xx), sup(xx))
at least when xx is nonempty.
Q: Which is better? Or something else?
Query 3.
I can't see any reason why an operation should ever generate possiblyValid, and therefore conclude it is never used. Agreed?
Regards
John Pryce