Motions 54, 55, 56, 57: YES
I vote YES on Motions 54, 55, 56, 57.
Here are my comments for Motions 54 and 55. I'll send possible
comments later for §12.12 (Motions 56 and 57).
§12.1.1, last sentence: "It is language-defined whether the format or
type of a datum can be determined at run time."
Why language-defined, and not possibly implementation-defined?
If the implementation is entirely provided by a library, then this
will be implementation-defined.
§12.3, paragraph 2: "double or float respectively, in C" is true in
most C implementations, but not required by the ISO C standard.
§12.3, concerning "equal as datums", how about the term "identical"
as a synonymous (to avoid reusing "equal" for different meanings)?
§12.5.1, "Each decorated interval type shall contain a “Not an Interval”
datum NaI, identified with (∅, ill)." I think there's an open question
related to that. See:
--------
From: Vincent Lefevre <vincent@xxxxxxxxxx>
To: stds-1788@xxxxxxxxxxxxxxxxx
Subject: NaI vs (Empty,ill) (was: Motion 52: final "Expressions" text for vote)
Date: Mon, 25 Nov 2013 00:45:09 +0100
Message-ID: <20131124234509.GA30649@xxxxxxxxxxxxxxx>
--------
§12.5.2, paragraph 2 (on mid-rad): "Whether such a type also contains
semi-bounded intervals is language- or implementation-defined."
Since mid-rad is just an example of an implicit type (i.e. it is not
part of specifications), I think it would be better to say something
like: "Such a type may also contain semi-bounded intervals."
§12.6.2, paragraph 1: "This eliminates the problem of double rounding
in mixed-format work."
In our context, this is not correct in general, where such a problem
is nonexistent: as I've said last September, double rounding doesn't
have any effect in directed rounding modes (assuming comparable
formats/types, which is the case in general with 754-formats of same
radix), i.e. double rounding gives the same value as single rounding.
IMHO, in this context, the main gain from mixed-type operations could
be faster code (if the corresponding formatOf 754-operations are
implemented in hardware) without the need of specific optimizations.
On the opposite, an implementation could say that T1-add(T2,T3) is
provided by writing something like: (T1) add((Tmax) u, (Tmax) v),
using C's cast notation, where Tmax is wider than T2 and T3.
§12.7, paragraph 1: "floating-point" could be dropped here, as
there are other kinds of multiple-precision systems. For instance,
floating-point expansion systems (a.k.a. staggered arithmetic?)
are such multiple-precision systems, but not multiple-precision
floating-point systems.
§12.8.1: It could be noted that the hull operation may inevitably
transform a bounded set into an unbounded interval. The notion of
overflow on intervals could be introduced here (though there is a
bit in Section 8, on the decoration system).
§12.10.1: Concerning Guillaume's remark about the "tightest" mode
with implicit types, I would not disagree to relax the spec.
Similarly, I also made a remark in quite old discussions, wondering
why a particular minimal enclosure had to be chosen for the T-hull,
and I don't remember if there was any good reason. One should notice
that with some particular implicit types, a minimal enclosure may be
much wider than other ones, but I see such issues as QoI (just like
the choice of the precision for the interval types). However, later
in Guillaume's remark: "As a consequence, I believe it is impossible
to design a conforming implementation.", I don't think this is true;
any example?
§12.10.1, formula (35): the closing bracket is missing.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)