Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Expression evaluation [was Re: I vote NO ...]



On May 17 2011, John Pryce 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. We could add to it that P1788 compliant language implementations SHOULD include operations with an explicit rounding direction. I don't see how we can make it a SHALL.

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,
probably most, and perhaps even all of the most relevant programming
languages.  Not in details, but in fundamentals.  It was pointed out
that, unless IEEE 754 made at least SOME compromises with the semantic
models that have been used by almost all programming languages for the
past 50 years, it wasn't going to be accepted any more by them than the
1984 version was.  No such compromises were made.

Fortran has always made it very clear that the purpose of an expression
is to produce a processor-dependent approximation to the mathematical
expression (see Fortran 2008 7.1.7 and elsewhere), and does NOT define
the detailed evaluation of operands and sub-expressions.  I can assure
you that the HPC people will not easily let that go.  Incidentally, the
changes to the standard to support interval arithmetic would be small,
except for I/O.

C is, as you would expect, thoroughly confused over this matter.
Despite common claims, the parsing order need NOT be the evaluation
order, but that mainly affects the IEEE 754 flags (see C99 5.1.2.3 and
elsewhere).  As far as the actual value is concerned, C99 completely
rewrote this area, but both C90 and C99 allow 'super- precision' and
sometimes alternative expression evaluation in very different ways (see
C99 5.2.4.2, 5.2.4.2.2, 7.12.2).  It is of no direct consequence, as the
existing C standard cannot support interval arithmetic without being
rewritten, but a LOT of languages base their semantic models on C.

And, of course, in both the IEEE 754 support is optional and the
standard's specification is hedged around with so many "get out of jail
free" cards that a compiler can easily provide 'support' without being
usable.  The result of this is that they are completely useless when
portability or reliability really matters.

That does not matter much for the IEEE 754 features, where they are
bolt-on extras, but would sound the death knell for the acceptance of
interval arithmetic.


Regards,
Nick Maclaren.