In my opinion, there should be no "tightness requirement" in the
standard. Tightness is an implementation feature like speed. Are
there any interval speed requirements in the standard?
Dima, Portable literals are a great implementation feature.
Thanks for mentioning it.
Of course, when implemented with intervals, the only requirement
should be that containment constraint is never violated.
Cheers,
Bill
On 9/27/13 6:38 PM, Dmitry Nadezhin wrote:
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