Home > Archive > Fortran > March 2004 > Re: Standard Fortran Floating point behaviour
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Standard Fortran Floating point behaviour
|
|
| Dmitri Kavetski 2004-03-31, 11:44 am |
| thanks everybody for the replies.
To make my question more specific, I am interested in whether the following
behavior (summarized by Catherine) is guaranteed by the Fortran standard and
can be relied upon in a general practical compiler:
"Provided float A is explicitly set to an exactly representable value (eg,
0.0, but possibly 2.0, etc.) and never appear on the LHS of an assignment
expression, comparing it again with the same value (possibly in a different
program unit) is guaranteed to return .true."
I have checked this behaviour on CVF with win2K, but want to be sure for
other compilers/machines/future, etc.
As such, this question is more a language/software/hardware-oriented, rather
than a "numerical analysis" issue. So is it reliable standard behaviour?
Dmitri
| |
| Gerry Thomas 2004-03-31, 2:37 pm |
|
"Dmitri Kavetski" <no@one.knows> wrote in message
news:c4eogj$a51$1@seagoon.newcastle.edu.au...
> thanks everybody for the replies.
>
> To make my question more specific, I am interested in whether the
following
> behavior (summarized by Catherine) is guaranteed by the Fortran standard
and
> can be relied upon in a general practical compiler:
>
> "Provided float A is explicitly set to an exactly representable value
(eg,
> 0.0, but possibly 2.0, etc.) and never appear on the LHS of an assignment
> expression, comparing it again with the same value (possibly in a
different
> program unit) is guaranteed to return .true."
If you guarantee that A (exactly representable or otherwise) is never
redefined why wouldn't its value remain the same?
--
Ciao,
Gerry T.
______
"Klinger, it's my considered opinion that no one is going to believe you
are pregnant." -- Henry Blake, the 4077th M*A*S*H.
| |
| Dmitri Kavetski 2004-03-31, 2:37 pm |
| If the comparison is carried out in a register with higher precision then it
is conceivable (?) that the value of A can get padded with additional
nonzero digits and negate the comparison. So I would like to know if
floating point standards prescribe any particular behaviour in this respect.
"Gerry Thomas" <gfthomas@sympatico.ca> wrote in message
news:aRDac.56642$1A6.1260547@news20.bellglobal.com...
>
> "Dmitri Kavetski" <no@one.knows> wrote in message
> news:c4eogj$a51$1@seagoon.newcastle.edu.au...
> following
> and
> (eg,
assignment[color=darkred]
> different
>
> If you guarantee that A (exactly representable or otherwise) is never
> redefined why wouldn't its value remain the same?
>
> --
> Ciao,
> Gerry T.
> ______
> "Klinger, it's my considered opinion that no one is going to believe you
> are pregnant." -- Henry Blake, the 4077th M*A*S*H.
>
>
| |
| glen herrmannsfeldt 2004-03-31, 3:37 pm |
| (previously snipped question about floating point equality comparison)
Dmitri Kavetski wrote:
> If the comparison is carried out in a register with higher precision then it
> is conceivable (?) that the value of A can get padded with additional
> nonzero digits and negate the comparison. So I would like to know if
> floating point standards prescribe any particular behaviour in this respect.
Well, the standard can guarantee all it wants to, but it
is the actual hardware that counts in the end.
If the hardware has operations that add non-zero digits then that
is what you will get. All hardware I know of extends with zeros.
The problems in Fortran occur when mixing precision and expecting
non-zero numbers to compare. 0.2 does not equal 0.2D0, and
because of rounding might not even when converted to single
precision.
There have been discussions about probabilistic rounding, which
might include random digits on extending numbers. Zero might be
a special case, though. If any hardware implemented that, it
might also implement interval comparison so that numbers would
compare equal when they were close enough.
-- glen
| |
| Gerry Thomas 2004-03-31, 8:34 pm |
|
"Dmitri Kavetski" <no@one.knows> wrote in message
news:c4f2tf$lg8$1@seagoon.newcastle.edu.au...
> If the comparison is carried out in a register with higher precision then
it
> is conceivable (?) that the value of A can get padded with additional
> nonzero digits and negate the comparison. So I would like to know if
> floating point standards prescribe any particular behaviour in this
respect.
It's a safe bet that the tautology a==a is true. Whether a==b is a
different question. If a and b are the same kind and a - b is in the
interval (-tiny,+tiny) then in finite precision arithmetic they are the
same. If a and b are not the same kind then watch it. BTW, the floating
point standard is not part of the Fortran standard. I recommend that you
read Goldberg's "What every computer scientist should know about floating
point arithmetic" and, in particular, the end of the article dealing with
double rounding and the uses and abuses of extended precision.
--
Ciao,
Gerry T.
______
"Competent engineers rightly distrust all numerical computations and s
corroboration from alternative numerical methods, from scale models, from
prototypes, from experience... ." -- William V. Kahan.
| |
| Eric K. 2004-03-31, 11:32 pm |
| "Dmitri Kavetski" <no@one.knows> wrote in message news:<c4f2tf$lg8$1@seagoon.newcastle.edu.au>...
> If the comparison is carried out in a register with higher precision then it
> is conceivable (?) that the value of A can get padded with additional
> nonzero digits and negate the comparison. So I would like to know if
> floating point standards prescribe any particular behaviour in this respect.
Most contemporary machines implement (most of) the IEEE-754 floating-point
standard. The general rule is that conversions between floating-point formats
must be exact where possible - i.e., the value is unchanged when switching
precisions. Exact conversions are possible, for instance, with small integer
values; so numbers like 2.0 won't have random low-order bits introduced if
the value is loaded into a longer register.
Exact conversions are not possible for numbers like 0.1, which can't be
represented in a finite number of binary digits. A comparison like
if(x == 0.1)
can be problematic if x is the result of a sequence of floating-point
operations. In (say) 80-bit Intel arithmetic, the computed value of x
might be 0.1 rounded to the 64-bit significand of the 80-bit register;
but the expression "0.1" is a single-precision constant, which, when promoted
to 80 bits, will have a bunch of trailing zeros; so the comparison will fail.
--Eric
|
|
|
|
|