Re: P1788/M0014.01: NO
My vote is NO.
The wording of section 6.1 is unclear, and makes requirements that
are not properly defined, and not possible to implement.
For example, it requires that "it shall be possible to retrieve the
bounds of x exactly." The implications of the word "exactly" here is
ambiguous and perhaps impossible. For example, the interval
implementation in my programming language "Frink"* can use a rational
number to represent the infimum or supremum of an interval. It may also
use arbitrary-precision floating-point numbers or arbitrary-size
integers, or, soon, even transcendental numbers represented
symbolically. (e.g. the exact expression sqrt[2]). This is necessary for
getting the sharpest possible bounds, such as when storing the exact
rational value 1/3, or even 1/10, neither of which can be represented
exactly in common binary representations, including IEEE-754! (Frink
*can* exactly represent the number 0.1 also.)
Thus, only if the receiver of the function can handle exact rational
numbers can I fulfil the requirements of section 6.1 to return my bounds
"exactly," *even though my internal representation may be sharper and
more exact.* A very good, sharp implementation probably can't fulfil
the requirements of this section because if the receiver requests my
bounds, I probably cannot return them "exactly" as required by this
section, but must potentially coerce and round them into some sort of
less-accurate interchange format, like IEEE-754, or something with
finite precision, losing precision in the process, and failing to comply
with the requirements of section 6.1.
It's unclear what was intended by this section as written, other than
to be a lead-up to defining an interchange format. It will fail to be
able to do this as written. The conflicting goals of allowing any
implementation but then requiring that the bounds that this arbitrary
implementation stores have to be retrieved "exactly" are apparently
impossible to reconcile. This motion needs another attempt to be possible.
To see if the next version of this motion succeeds better, here are
some tests. See if it's possible to meet the criteria if your
implementation stores exact rational numbers like 1/3 or 1/10,
arbitrary-size integers, arbitrary-precision floating-point numbers, or
exact symbolic constants like sin[1].
In addition, for the next pass, I would strike the entire section of
6.1 that begins with "This is captured by the following definition" and
deleting to the end of 6.1. This section on concrete interval format
unnecessarily confuses the issue, as the "implementation may choose any
means" section allows any implementation, and randomly listing a couple
of them is not necessary.
* http://futureboy.us/frinkdocs/
--
Alan Eliasen
eliasen@xxxxxxxxxxxxxx
http://futureboy.us/