From: analyst41 on
when one can easily write

if (A > B) THEN

stuff

ELSEIF ( A < B) THEN

stuff

ELSE

stuff for the "equal" case

ENDIF
From: Phillip Helbig---undress to reply on
In article
<df5a3155-6e31-435d-9776-ed22b47d6122(a)f20g2000pro.googlegroups.com>,
"analyst41(a)hotmail.com" <analyst41(a)hotmail.com> writes:

> when one can easily write
>
> if (A > B) THEN
>
> stuff
>
> ELSEIF ( A < B) THEN
>
> stuff
>
> ELSE
>
> stuff for the "equal" case
>
> ENDIF

Because the results are processor-dependent, since different rounding
schemes will produce different results.

From: Ron Shepard on
In article
<df5a3155-6e31-435d-9776-ed22b47d6122(a)f20g2000pro.googlegroups.com>,
"analyst41(a)hotmail.com" <analyst41(a)hotmail.com> wrote:

> if (A > B) THEN
>
> stuff
>
> ELSEIF ( A < B) THEN
>
> stuff
>
> ELSE
>
> stuff for the "equal" case
>
> ENDIF

I'm not exactly sure what is the question, but I think with IEEE
floating point and the appropriate values for A and B, all four of
the following branches can be executed.

if (A > B) THEN
stuff
ELSEIF ( A < B) THEN
stuff
ELSEIF ( A == B ) THEN
stuff for the "equal" case
ELSE
stuff involving Inf and NaN
ENDIF


However, the mapping between the IEEE values and the fortran tests
may be processor dependent or dependent on compiler options (e.g.
tests for equality between the two zero values). Also, the order of
the first three tests may affect which branch is taken in some
cases. The tests can also be done with functions from the IEEE
module, which eliminates the processor dependence among IEEE
machines but makes the code less portable.

$.02 -Ron Shepard
From: analyst41 on
On Aug 1, 12:23 pm, Ron Shepard <ron-shep...(a)NOSPAM.comcast.net>
wrote:
> In article
> <df5a3155-6e31-435d-9776-ed22b47d6...(a)f20g2000pro.googlegroups.com>,
>
>  "analys...(a)hotmail.com" <analys...(a)hotmail.com> wrote:
> > if  (A > B) THEN
>
> > stuff
>
> > ELSEIF ( A < B) THEN
>
> > stuff
>
> > ELSE
>
> > stuff for the "equal" case
>
> > ENDIF
>
> I'm not exactly sure what is the question, but I think with IEEE
> floating point and the appropriate values for A and B, all four of
> the following branches can be executed.
>
> if  (A > B) THEN
>    stuff
> ELSEIF ( A < B) THEN
>    stuff
> ELSEIF ( A == B ) THEN
>    stuff for the "equal" case
> ELSE
>    stuff involving Inf and NaN
> ENDIF
>
> However, the mapping between the IEEE values and the fortran tests
> may be processor dependent or dependent on compiler options (e.g.
> tests for equality between the two zero values). Also, the order of
> the first three tests may affect which branch is taken in some
> cases. The tests can also be done with functions from the IEEE
> module, which eliminates the processor dependence among IEEE
> machines but makes the code less portable.
>
> $.02 -Ron Shepard

OK - so tests for Floating point ">",">=","<" and "<=" are subject to
the same processor-dependencies as a direct or indirect test for "=="?
From: Richard Maine on
Phillip Helbig---undress to reply <helbig(a)astro.multiCLOTHESvax.de>
wrote:

> In article
> <df5a3155-6e31-435d-9776-ed22b47d6122(a)f20g2000pro.googlegroups.com>,
> "analyst41(a)hotmail.com" <analyst41(a)hotmail.com> writes:
[most of his question in the subject line]
>
> > when one can easily write
> > if (A > B) THEN
....
> > ELSEIF ( A < B) THEN
....
> > ELSE
> >
> > stuff for the "equal" case
> >
> > ENDIF
>
> Because the results are processor-dependent, since different rounding
> schemes will produce different results.

And because of that, the alternate form shown above is just as
deprecated as any other form. At least I deprecate it just as much. It
is the dependence on exact equality that I deprecate - not some
particular syntax. The above form depends on exact equality just as much
as a test with "==" would. If you find someone who deprecates one form
but not the other, then you should ask them why instead of asking the
world at large. I would disagree with any such distinction. If you have
found a compiler that deprecates one form but not the other, that is
probbaly just because the one form is trivial to detect, while the other
is not (particularly as one could further obfuscate the other without
changing its essential nature).

Note also that there is no such deprecation of floatting point equality
tests in the standard. If you read somewhere that it is deprecated, I
would hope that the author of the words you read would have clarified
what he meant by that. If he just said that it "is deprecated", that
would be sloppily imprecise writing in that it fails to specify who it
is that does the deprecation. Using the passive voice often results in
such sloppy writing (which is why I find it odd that some technical
writing styles prefer it).

In the context of a standardized programming language, the phrase "is
deprecated" generally implies deprecation by some version of the
standard unless there is specific qualification otherwise. That
implication is false in this case (unless something like that slipped
into f2008 when I wasn't looking.)

Many people (myself included) do deprecate floating point equality tests
for the reason that Philip mentioned. Depending on exact results from
any floating point operation is risky except in special cases where you
can be sure that no rounding would have been involved on any practical
system. Rounding is fundamental to floating point. I recommend against
using floating point at all until you have at least a basic appreciation
of the implications of rounding. Yes, that means I think one needs to
get a basic appreciation of the implications of rounding very early in
learning Fortran. It doesn't need to be very sophisticated - just
knowing that anything involving floating point can be inexact is
sufficient for a start.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain