Prev: code speed moving from fortran 77 compiler to f2003 compiler
Next: Call for benchmarks: proposals by 30 June
From: Thomas Koenig on 14 Jun 2010 15:40
Hello world,

assume a is a REAL and contains a NaN.

What could

print *, a + 1 - a

output? NaN would (obviously) be OK, but would 1 also permitted?

What if all intrinsic IEEE modules are used?
From: glen herrmannsfeldt on 14 Jun 2010 15:51
Thomas Koenig <tkoenig(a)netcologne.de> wrote:

> assume a is a REAL and contains a NaN.

> What could

> print *, a + 1 - a

> output? NaN would (obviously) be OK, but would 1 also permitted?

> What if all intrinsic IEEE modules are used?

Is this a Fortran or IEEE question? In Fortran, you need ()'s
to force evaluation order, so consider:

print *, (a + 1) - a

Without ()'s, Fortran allows the compiler to reorder the expression.

My feeling (could be wrong) is that Fortran allows for, but
does not require, the IEEE floating point standard.
Others may disagree.

-- glen
From: Richard Maine on 14 Jun 2010 15:53
Thomas Koenig <tkoenig(a)netcologne.de> wrote:

> assume a is a REAL and contains a NaN.
>
> What could
>
> print *, a + 1 - a
>
> output? NaN would (obviously) be OK, but would 1 also permitted?

No. Your subject line suggests that that "a-a" should be 0. That is not
so when "a" is a NaN. The result of NaN-NaN is NaN. So this is not a
question of reordering. Even if the code was manually reordered, and
parens used to force that ordering, as

print *, (a-a)+1

that would not change the answer. It is not any reordering that is at
issue here; it is whether "a-a" is necessarily 0.

Of course, if the compiler doesn't claim full support of NaNs, that's a
very different matter. A compiler is not required to support NaNs at
all. In that case, the vendor can claim that the code is nonstandard,
allowing the compiler to do anything, as soon as it ventures into
territory that creates a NaN.

And another "of course" is that being quite that strict about
conformamce to the rules of NaN handling can kill optimization, so you
might well find compilers not doing it.

> What if all intrinsic IEEE modules are used?

That would tend to push towards being more strict.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: Ron Shepard on 15 Jun 2010 11:23
In article <1jk2u5c.1xwzsq21ou64e8N%nospam(a)see.signature>,
nospam(a)see.signature (Richard Maine) wrote:

> Even if the code was manually reordered, and
> parens used to force that ordering, as
>
> print *, (a-a)+1
>
> that would not change the answer. It is not any reordering that is at
> issue here; it is whether "a-a" is necessarily 0.

Isn't the issue whether (a-a) is allowed to be eliminated during the
evaluation of the expression? I would think this would satisfy the
"mathematically equivalent" requirement in the standard. Of course
IEEE arithmetic with its NAN, INF, -ZERO, and so on complicates
these issues, but if IEEE is not supported by some compiler (or if
it has been disabled with compiler options), then I would think that
(a-a) could in fact be eliminated from the expression (at the
symbolic code level) and never explicitly evaluated (to 0.0 or NAN
or any other possible value).

So I think the issue is whether the expression "(a-a)+1" is
mathematically equivalent to the expression "1", and how support of
IEEE arithmetic might affect that answer.

$.02 -Ron Shepard
From: glen herrmannsfeldt on 15 Jun 2010 15:52
Ron Shepard <ron-shepard(a)nospam.comcast.net> wrote:
(snip, someone wrote)

>> print *, (a-a)+1
(snip)

> Isn't the issue whether (a-a) is allowed to be eliminated during the
> evaluation of the expression? I would think this would satisfy the
> "mathematically equivalent" requirement in the standard.

I agree. And since IEEE is not (yet) a requirement of Fortran...

> Of course
> IEEE arithmetic with its NAN, INF, -ZERO, and so on complicates
> these issues, but if IEEE is not supported by some compiler (or if
> it has been disabled with compiler options), then I would think that
> (a-a) could in fact be eliminated from the expression (at the
> symbolic code level) and never explicitly evaluated (to 0.0 or NAN
> or any other possible value).

One may want this optimization, and yet be able to do other
IEEE tests. For example, as in a previous post, one might want
the ability to set and test for NaN, but still want the
optimizer to optimize expressions.

> So I think the issue is whether the expression "(a-a)+1" is
> mathematically equivalent to the expression "1", and how
> support of IEEE arithmetic might affect that answer.

One might ask why anyone would write such an expression.

In the case of:

if(x.ne.x) ...

It is hard to see why one would write that, other than as
a potential test for NaN. (Though possibly as machine generated
code in those cases where it is used.) So, now, how far from
the (x.ne.x) case should the compiler be expected to recognize
it as a potential NaN test and not optimize it out?

-- glen
 |  Next  |  Last
Pages: 1 2 3 4
Prev: code speed moving from fortran 77 compiler to f2003 compiler
Next: Call for benchmarks: proposals by 30 June