This is the mail archive of the
mailing list for the GCC project.
Re: GCC beaten by ICC in stupid trig test!
- From: Toon Moene <toon at moene dot indiv dot nluug dot nl>
- Cc: JoeJoe dot Buck at synopsys dot COM, Bradley Lucier <lucier at math dot purdue dot edu>, roger at eyesopen dot com, gdr at integrable-solutions dot net, gcc at gcc dot gnu dot org, abraham at dina dot kvl dot dk, gcc-patches at gcc dot gnu dot org, laurent at guerby dot net, fjahanian at apple dot com
- Date: Wed, 24 Mar 2004 22:38:51 +0100
- Subject: Re: GCC beaten by ICC in stupid trig test!
- Organization: Moene Computational Physics, Maartensdijk, NL
- References: <13661448-7DC0-11D8-817F-000A958F150A@math.purdue.edu> <20040324105146.A1279@synopsys.com> <EDB6EC7E-7DC4-11D8-817F-000A958F150A@math.purdue.edu> <20040324110433.A2050@synopsys.com> <4061F6EF.email@example.com>
Dave Korn wrote:
> IIUIC the fact that the + operator is specified in the standard as
> binding left-to-right imply that "a + b + c" with no brackets *has* to
> be interpreted as "(a + b) + c".
No, it establishes the way the multi-operator expressions may be
combined *for interpretation*. I.e., what the expression means (on a
high level, before applying such rules as 1.4 (6) [This standard does
not specify] ... the method of rounding, approximating or computing
numeric values on a particular processor").
This might not be as clear as possible, because '+' happens to be
associative in the REAL world.
What the Fortran standard wants to make clear is that a grouping is
necessary to establish an interpretation for unparenthesized expressions
with more than one operator.
The example with '+' is trivial, because '+' is associative in the real
numbers, so a standard-enforced ordering is superfluous.
However, this is not true of '/' (division) or '**' (exponentiation).
Therefore, the standard establishes that for division:
A / B / C means (A / B) / C and not A / (B / C)
and for exponentiation:
A ** B ** C means A ** (B ** C) and not (A ** B) ** C
Both interpretations follow mathematical practice, but still have to be
defined for the standard.
Hope this helps,
Toon Moene - mailto:firstname.lastname@example.org - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc.gnu.org/fortran/ (under construction)