Re: Do I have a second? Re: Motion to stop work on the standard
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.
--
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)