Re: Expression evaluation [was Re: I vote NO ...]
> Date: 18 May 2011 11:38:11 +0100
> From: "N.M. Maclaren" <nmm1@xxxxxxxxx>
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: 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,
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.
> 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.
And you've hit the reason for making no claims right on the
head. Since we couldn't get any of the languages present in
the room to agree to anything collectively, the whole of clause
10 is mostly recommended. There is a lot more informative text
in it than normative but very few 'shall's.
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.
>
> 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.
Yes, we knew this. Our Fortran guy was there.
>
> 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.
Our C guy was there too.
>
> 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.
Alas, at least with regard to clause 10, I agree with you.
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.
>
> 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.
You may be right.
As Nate has pointed out many times, one way an implementation
can distinguish itself from the competition is to find novel
way of tightening the answers in interval expressions.
But the situation for us today is different than for 754 in
2008. It is even different from 754 in 1985. The notion of
'standardized intervals' is new to the world. There are no
previous examples of dusty decks that must be supported.
(Many previous interval examples but none that claim any sort
of standardization.)
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'm sure we must permit other forms of evaluation under the
phrase "MIGHT also be supported". But I still hope we can
agree on a single form that is a 'shall'.
(Perhaps more than one. This is not a contradiction. There
should be a single standard default but we might want to
specify several standard alternatives that also shall be
supported.)
I may be wrong.
We may not be able to agree on anything standard.
But its worth a try.
Don't you think?
Dan