(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.
abstain
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()?