Ned, Juergen,
I work on syntax of portable interval literals that I would like to submit as a motion.
Portable literals permit users to exchange files with interval literals between
different P1788 implementations that doesn't know about each other.
Any implementation may extend syntax of interval literals and may emit strings that are not portable literals,
but there shall be a conversion specifier "cs" that forces to emit strings that are portable literals.
Any implementation shall parse portable literals and return their valid enclosure though
it may accept strings with non-portable interval literals too.
When we discussed Motion 48, you insisted that rational notation inside intervlal literals like [1/3]
SHOULD be supported (not SHALL) and that implementation "may restrict the support of literals, by
limiting the length of the string or in other ways". I understand that you want to simplify implementations.
However, this prevents implementations that support intervals with rational bounds to exchnge number literals with out loss of accuracy.
Yes, implementation need some additional code to convert interval literals with rational notation.
The main difficulty is not in parsing this notation, but in computation of tightest bounds of [p/q] when p and q have many decimal digits.
The tightest bounds in infsup_F datatype are x_inf = roundDown(p/q), x_sup = roundUp(p/q). Its computation may be difficult.
However, it is easy to compute accurate bounds:
x_inf is either roundDown(p/q) or nextDown(roundDown(p/q));
x_sup is either roundUp(p/q) or nextUp(roundUp(p/q)) .
Sitiation with long mixed-radix number literals [l,u] is similar. It is easy to parse them, it is difficult to check l<=u exactly.
It is easy to check l <= u approximately , with possible false positives.
Do you have objections that each implementation of textToInterval(s) SHALL parse any string that is portable interval literals
( even if it is very long or if it contains rational notation ) but implementation may compute accurate bounds instead of tightest in this case ?
I can prepare a collection of sample implementations of "textToInterval" in C language under permissive license in order
help implementators. I already have prepaired (and gave links to Juergen):
1) A simple tightest implementation based on GMP, though ti may require large time and memory to check l <= u exactly and to compute tightest enclosure;
2) An proof of concept implementation. It doesn't depend on other libraries. It doesn't allocate dynamic memory, but uses static memory proportional to
exponent range of F. It computes tightest enclosure, thoght is permits false positives in l <= u test.
Perhaps, I might prepare yet another implementation that depends only on 754-conforming strtod(), uses fixed memory proportional to mantissa length,
but computes only accurate enclosure.
-Dima