On 2013-11-23 10:15:31 -0500, Lee Winter wrote:
I agree, but premature optimization is one of the roots of all evil.
I'm not a math guy. I'm a computer guy. And I am fantastically
sensitive to the issue of invalid standards. A three-year wait sounds
about right for the community to gain some experience implementing and
experiencing the emergent behavior of the current draft.
Setting a standard has two connotations. One is a rigorous treatment
of the subject matter ab initio. The other is a correlation and
resolution of the inconsistencies between existing (probably
competing) implementations. P-1788 as it currently exists is a case
of the former. As such it needs to provide _rigor_ as its key
contribution. Bill is pointing out a serious shortfall in that
requirement.
Perhaps we could spend a couple years on the second approach to
standardization, especially once implementations of the P-1788
proposal become available and added to the existing population of
examples. After all, multiple implementations are the absolutely best
way to discover inconsistencies and ambiguities within the proposal.
As an implementer I don't care about the hard parts of the standard.
I care a lot about the bad parts of the standard.
I completely agree.
Other important points about the first connotation:
1. The standard must be implementable.
2. An implementation must be useful and usable in an efficient way.
Users will expect various kinds of optimization or there is a risk
that they won't use the standard.
As an example, there are some problems with IEEE 754 on the software
side due to the initial lack of consideration of the software side
(but IMHO, the hardware side implementations are partly responsible),
in particular in C (which has consequences for the implementation of
other languages written in C). For instance, among the most well-known
compilers:
* GCC:
- x86 is poorly supported, see bug 323 (which has been closed
3 times assuming it was a "bug" in x86, before being reopened,
and someone wanted to close it a 4th time). I'm citing it also
because some comments give a good idea of problems related to
the meaning of an expression.
- Directed rounding modes are not supported *by default*, even
when -std=c99 is used. And their support doesn't seem to be
really guaranteed. This will affect P1788.
For both points, the main reason is efficiency.
* Clang: developers do not consider IEEE 754 to be supported at all,
and they don't seem to have any plan to support it.
* ICC 10.1 (I don't know about the latest versions) under GNU/Linux:
problems with NaN support (failing NAN != NAN test), problems with
signed zeros, unsupported rounding modes.
What I mean is that we shouldn't focus only on theoretical aspects,
but also think of implementations (one or several reference
implementations could help).
Also I disagree a bit with Bill (but I'm not sure what he really
means): IMHO, P1788 doesn't have to specify everything and should
let some parts to the language (and/or implementation). Still, we
need a good formalization of what is used by P1788, e.g. about
the notion of expression if used in normative parts.