Perhaps, it were wiser if P1788 required the same radix in l and u ends of interval number literals.
However, I am not sure if it is possible to fix it now.
I remind why I insist on rational number literals.
I want interchange between different interval types different implementations.
Implementation A1 if interval type T1 should be to able convert its interval x
to an interval literal s of the same value as x by s=intervalToExact(x).
And then implementation A2 of iterval type T2 should be able to read this to interval y that contains x
by y=textToInterval(s).
If T1 is infsup_F where F is a binary floating-point format then
intervalToExact(x) can return interval literal where ends are hexadecimal number literals.
If T1 is infsup_F where F is a decimal floating-point format then
intervalToExact(x) can return interval literal where ends are decimal number literals.
If T1 is infsup_F where F is a format whose members are rational numbers then
intervalToExact(x) can return interval literal where ends are rational number literals.
So I request that y=textToInterval(s) of P1788.1 implementation is able to read any of such string
into infsup_b64 interval y which contains x.
It can be achieve by adding a sentence to 6.6.1
"- A rational literal p / q. This comprises an integer literal p, the / character, and a positive-natural literal
q. Its value is the value of p divided by the value of q."
As rational literal has radix 10, the difficult case of mixing hexadecimal and rational ends
will be excluded by the new words in 6.6.2 “of the same radix (10 or 16)”.
I feel quite uneasy advocating for rationals into the simplified standard. I do not see them massively
used to justify the added complexity.
If we have l and u in [ l, u ] of the same radix (as suggested in my previous e-mail),
we can leave it as implementation dependent how they are (outward) rounded when
converted to binary64.
Does it mean that you want to replace
"If s is a valid interval literal with Level 1 value x,
the result shall be the hull of x (the constructor succeeds)."
in 6.7.5 by something like this
"If s is a valid interval literal with Level 1 value x,
the result shall contain x (the constructor succeeds).”
I thought about it. I am not an expert on conversions. My question is, for more knowledgeable
people, how difficult is to compute the hull in binary from two decimal strings for which we
know l <= u?
Here are two more questions. In both 1788 and 1788.1, we have “Accuracy requirements.” In an implementation, they have to be documented. Has anybody tried to document the tightness of interval
operations for a particular package? Moreover, is there an implementation that (provably) satisfies these
requirements?
Regards,
Ned