Path: utzoo!attcan!uunet!mailrus!iuvax!klshafer
From: klshafer@iuvax.cs.indiana.edu (Ken Shafer)
Newsgroups: comp.lang.fortran
Subject: Re: Explain this output to me (a new twist)
Message-ID: <45963@iuvax.cs.indiana.edu>
Date: 29 May 90 02:47:19 GMT
References: <1554@ns-mx.uiowa.edu> <90May23.184629edt.20043@me.utoronto.ca> <1543@charon.cwi.nl> <1990May27.193758.25099@uncecs.edu>
Reply-To: klshafer@iuvax.cs.indiana.edu (Ken Shafer)
Organization: Indiana University, Bloomington
Lines: 45

In article <1990May27.193758.25099@uncecs.edu> urjlew@uncecs.edu (Rostyk Lewyckyj) writes:
>
>
>In the original problem the program starts at -.5 and increments
>by approximately .1 to approximately .5. The output of the steps
>is displayed to 7 places.
...........remainder of explanation(s) deleted.......

This problem has been well explained so I won't add to that discussion
directly.

But I will contribute another example regarding the pitfalls of approximations
with floating point:

About 11 years ago I was stymied for a day or two with a bug at a client site,
using CDC FORTRAN 66 (this was pre f77 days.) The application used a
combination of numerics and text. I was using REAL arrays for storing
some character strings, and knowing that CDC had a 60bit word and 6bit
characters, these were A10 (10byte) structures.  I was doing an IF
test for equality of strings (looking for command keywords and the like)
and I would print the two variables out as a10 before comparison
and see that indeed they were different, but when I compared them the
equality branch of the IF was the branch taken!

Eventually I figured it out. The particular selection of characters in
the strings to be compared resulted in wildly different exponents,
and the compiler generated code to 'normalize' the exponents, and the
least significant bits (the fractional part) were subsequently shoved
off into oblivion, yielding two floating-point values that were 
"equal."  The solution was to change all the declarations from REAL
to INTEGER for the 'character' data, and the comparisons degenerated
into straight comparisons, the 'proper' logic was generated.

All this may seem moot in lieu of the character data available in
fortran 77, but be aware that some f77 compilers still have some
restrictions on character data types.  For example, Hewlett Packard
RTE-6/RTE-A f77 will not permit character data types in COMMON
blocks that are resident in extended-memory-address ($ema) partitions,
necessitating setting character data to some other type.  The
object lesson here is that, if for ANY reason you can not use 
character types to store character data, USE TYPE INTEGER rather
than TYPE REAL.

Regards,
          ken.............klshafer@iuvax.cs.indiana.edu