Re: Motions 54, 55, 56, 57: YES
Vincent & P1788
On 2013 Dec 27, at 02:30, Vincent Lefevre wrote:
> 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.
Done.
> §12.3, paragraph 2: "double or float respectively, in C" is true in
> most C implementations, but not required by the ISO C standard.
Changed.
> §12.3, concerning "equal as datums", how about the term "identical"
> as a synonymous (to avoid reusing "equal" for different meanings)?
Sensible idea, and I've done it. However one needs terms later for
"unequal as datums" -> "non-identical" (I don't like unidentical)
"equality as datums" -> "identicality"
I hope that will do.
> §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>
> --------
The work Ned & I did over Christmas on formalising FTDIA has definitely justified NaI as *being* (∅, ill).
> §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."
Good point. Done
> §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.
In view of what has been said on this it seems best to remove that sentence, which I've done. I hope notes on these issues find their way into the informative web-based material that Juergen is planning.
> §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.
Done
> §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).
I've added a short paragraph on overflow here.
> §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?
I think subsequent discussion showed the requirements don't imply (or had been changed to not imply) what Guillaume thought they imply. I still prefer "T-hull is a deterministic & minimal enclosure", and have yet to see a definite example where this impacts performance for a type likely to be used in practice. I will consider relaxing this if good alternative wording is submitted.
> §12.10.1, formula (35): the closing bracket is missing.
I couldn't locate this.
These changes are on the SVN, revision 257.
John Pryce