Motion 46: finalise interval literals, amendments
P1788
A reply to some comments on Motion 46 interval literals. As a result here a some possible changes to the motion, based on looking at the Sun interval system.
(1) Do we need functions like those suggested by Ian M?
(2) Should the notation for Empty and Entire be changed to have brackets round, e.g. [empty], as in Sun? (Yes, IMO.)
(3) Should nums2interval() use (as it does currently) the Siegfried Rump scheme where nums2interval(oo,oo) gives [HUGEPOS,oo]? Should this be extended to text2interval()? See <4> in code example below.
(4) Should we use Sun's simpler version of "uncertain numbers", instead of the current one, which comes from the Vienna proposal? See <1> in code example below.
Please take this as asking for a straw poll, after which I will circulate a friendly-amended motion.
You can of course also urge
(5) Remove interval literals entirely.
However, I feel even more than before that this would be a mistake, in view of the arguments given by Ned Nedialkov and the fact that interval-literal syntax is used by library functions and doesn't impact language syntax (unless the language wants it to).
John Pryce
---------------------------------------------
On 10 Jun 2013, at 19:55, Ian McIntosh wrote:
> More conversion functions than just text2interval are needed.
>
> One function would convert a single precision value and another a double precision value, both with a parameter specifying how precise they should be considered.
> You could write
> float x = 0.1f;
> interval a = float2interval (x, 7);
> to say that x should be considered to have 7 significant digits (0.1f happens to be accurate to 8 digits), and
> double y = 0.1;
> interval b = double2interval (y, 16);
> to assert 16 digit accuracy for y.
Can you give an application where it would be useful? And a pitfall the user might fall into if she writes it herself, e.g. (in Matlab style) as follows?
function a = float2interval(x,d)
xerr = x/10^d;
a = nums2interval(x-xerr,x+xerr);
end
> For text conversions, there are arguments in favour of two different semantics. In one, "0.1" and "0.100000" are considered as identical infinitely precise representations of 1/10. In the other, "0.1" and "0.100000" are considered as different, with "0.1" meaning [0.05, 0.15] and "0.100000" meaning [0.0000005, 0.1000005]. The first is useful for the mathematical value 1/10, and the second is more useful for measured values where trailing zeros indicate how precise the measurement was. A mathematician who wrote that only the first is needed and an engineer who said only the second is convinced me that both are. 8<)
Sun offers both, and so does the proposed 1788 scheme. Here is code example 2-37 from 2.10.2.3 of Sun Interval Fortran Reference. I have prefixed lines of input with <1>, <2>, etc. for ease of reference, and the next line is the output produced. I put comments giving the P1788 version of the input.
math% cat ce2-37.f95
INTERVAL, DIMENSION(6) :: X
INTEGER I
DO I = LBOUND(X, 1), UBOUND(X, 1)
READ(*, *) X(I)
WRITE(*, *) X(I)
END DO
END
math% f95 -xia ce2-37.f95
math% a.out
<1> 1.234500 !P1788 says "1.234500?1"
[1.2344989999999997,1.2345010000000001]
<2> [1.2345] !proposed that P1788 says same as Sun
[1.2344999999999999,1.2345000000000002]
<3> [-inf,2] !P1788 says same as Sun
[-Inf,2.0]
<4> [-inf] !not valid in P1788
[-Inf,-1.7976931348623157E+308]
<5> [EMPTY] !currently P1788 says "EMPTY", no brackets
[EMPTY]
<6> [1.2345,1.23456] !P1788 says same as Sun
[1.2344999999999999,1.2345600000000002]
For comparisons, assume the "same" P1788 interval type is used, i.e. infsup binary64.
<1> shows Ian's "other semantics". 1.234500 denotes the exact interval [1.234499, 1.234501] and Sun encloses this in the tightest representable interval. P1788 can do the same, with slightly different notation.
<2,3,6> are as expected. Well, as I expect. I continue to think Richard Fateman has it wrong, and Sun has it right. An exact mathematical interval is formed and enclosed in the tightest representable interval.
<5>. I think Sun is right here and we should use [EMPTY], not EMPTY.
<4> is interesting. This is basically Siegfried Rump's proposal that *in this context only* -- a single point interval -- inf should be regarded as "a large unknown finite number", so it defines a nonempty (but unknown) interval.
Then its Level 2 hull is [REALMAX,oo] (or [HUGEPOS,oo], in the notation of 11.11.8 "Constructors"). I already put this idea into the definition of nums2interval(). Should it be in text2interval()?