Re: Expression evaluation [was Re: I vote NO ...]
On May 18 2011, Dan Zuras Intervals wrote:
> - A Language Level. In essence we already decided P1788 shall have
> such a thing, holding material about allowed expression
> rearrangements, on the lines of IEEE754-2008's Clause 10. ...
I am sorry, but that's not going to work. The reasons were raised
(mainly by outsiders) in the discussion of IEEE 754, but were swept
under the carpet.
IEEE 754 (current) 10.1 paragraph 3 is factually incorrect for many,
I don't understand, Nick.
Since 10.1 paragraph 3 makes no claims I don't see how it can
be factually incorrect.
The paragraph is largely informative with the only 2 normative
verbs being 'might' & 'should'. In the parlance of
standard-speak, both words express the notion of giving
permission to do (or not do) something. The only difference is
that 754 recommends 'should's & takes no position on 'might's.
We are at cross-purposes - perhaps things got renumbered. The paragraph
I am referring to is (with numbers added):
A programming language standard specifies one or more rules for
expression evaluation. A rule for expression evaluation
encompasses:
1. The order of evaluation of operations.
2. The formats of implicit intermediate results.
3. When assignments to explicit destinations round once, and
when twice (see below).
4. The formats of parameters to generic and non-generic
operations.
5. The formats of results of generic operations.
If that's meant as a statement of fact for the important programming
languages, 1-3 are false and 4-5 often false. If it meant to say "a
programming language standard SHALL specify ...", then it is imposing
the wildly different semantic model that is either or both of flatly
unacceptable and wildly incompatible.
As I look at it the 'shall's start in 10.2 & mostly mandate
against doing silly things & documenting what a conforming
implementation actually DOES.
Well, I could go into some points in other paragraphs, but the quote
above shows the issue clearly. The point is that clause 10 implies such
a radical change to the languages' semantic models as to be simply
unacceptable. Even demanding that a compiler document what it actually
does is unacceptable to the higher-performance numeric languages, too!
Consider a binary that does a run-time check as to whether a vector
unit of GPU is free, and uses it if so. That isn't just a thought
experiment; some compilers have done just that, and I believe that
some are reintroducing it.
We began that clause with the best of intentions. That is,
to fix the lack of reproducibility that came about in 1985
when we failed to specify consistent expression behavior.
But the intervening decades saw the gorillas in the room
doing things in separate & not-equal ways & none would
budge.
There is a saying about where a road paved with good intentions
leads :-) More seriously, I am baffled by that. We knew by 1975 that
requiring consistent expression behavior was a seriously bad idea for
performance, and encouraged many users to confuse consistency and
correctness. There were even some environments that deliberately
introduced variations, to improve error detection!
The gorillas in the room entered in the 1950s, became legal residents
in 1966 with Fortran 66, and were well-known to almost all numeric
programmers of the 1960s and 1970s. Some experts disliked them, but
others accepted them as an inevitable consequence of attempting to bind
numeric mathematics to any finite representation.
I am happy to live with them, and 25 years of experience shows that
they aren't going to go away or even hide!
As such, it is my hope that we can all agree on some form of
standardized expression evaluation that SHALL be supported
by all conforming implementations. We are motivated to do
this by the very nature of interval arithmetic. That of
providing solutions that are to be believed. Things like
portability & reliability are FAR more important for us than
the various floating-point guys admitted to themselves.
I am not dissenting from that. That is why I joined this group (with a
special interest in exception detection and flagging!) I believe that
such a specification needs to be in terms of abstract operations, with
the objective of a library-level interface in existing languages.
Whether a NEW language, or even a '4 GL' like Matlab/Octave/etc., could
do better is another matter entirely.
In particular, I regard any hint that such a standard includes a
requirement for established languages to make unacceptable changes
as almost certain to kill acceptance.
But, to make a more positive contribution, here is another approach:
Expressions are required to return an interval that must contain
all of the possible values resulting from a mathematically perfect
evaluation of all possible values in the input intervals.
Both the performance and tightness of the result would be quality of
implementation issues. And, yes, a compiler WOULD be allowed to replace
an expression by a numerically better equivalent. Most compilers would
then have flags, choosing the balance.
That was also my preference for IEEE 754 support, incidentally, but it's
trickier to specify for that.
Regards,
Nick.