This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
RE: Formatted Read Accuracy
- From: "Joe Malin" <joseph dot malin at oracle dot com>
- To: "'Toon Moene'" <toon at moene dot indiv dot nluug dot nl>, "'Emil Block'" <blime at his dot com>
- Cc: <gcc-help at gcc dot gnu dot org>
- Date: Thu, 10 Oct 2002 14:52:11 -0700
- Subject: RE: Formatted Read Accuracy
- Organization: Oracle Corporation
- Reply-to: <joseph dot malin at oracle dot com>
It wasn't clear from my post, but this is what I was getting at.
The sequence described by Toon represents the following:
System reads the set of characters "67.9936".
System converts them into a floating point representation, which when
examined in memory is actually 67.99359(...) out to whatever precision
results from a combination of compiler-OS-hardware.
System stores this value.
User asks for the value via a PRINT statement
System converts the floating point representation to characters, based
on (1) a conversion algorithm and (2) number of significant digits
requested or (3) default significant digits for output.
Result printed may be 67.9936 or 67.99359(...).
Why a difference between compilers? I would be shocked (somewhat) to
find that the internal representation of the number was changing between
compilers. But not disbelieving. The compiler uses some sort of system
library to do a conversion. The library may change, the compiler's use
of the library may change. Results may vary.
What I think is more likely is that Emil was not tremendously specific
about his output method. He may have used a PRINT without a format,
which then defaulted to 4 significant digits in one compiler and more
than that in other. Result is a difference in precision. Or, there
were some other compiler flags or settings that affected the conversion.
The bottom line is one of programming techniques for floating point.
First, understand precision and accuracy and the difference between the
2, also how floating point numbers are converted and stored. Second,
use input values wisely, and understand how the output accuracy is
affected by conversion. Third, don't worry about precision differences
that are beyond the level of accuracy you can expect. An example is
warranted.
Suppose I have a thermometer that is accurate to within .01 degrees. I
then measure a reaction occuring in what I measure to be 5.5 moles of
HCL and 7 moles of NaOH. I make a calculation based on this
information, using a Fortran program. I am upset because I expected a
value of 15.79 but instead got a value of 15.92. What gives?
The answer is: nothing gives. You can't expect accuracy of anything
more than 0 significant digits. That is, a value of 16 is suspect, but
beyond that any value between 15.00 and 15.99 is valid, given your
accuracy level. Therefore, your Fortran program should not even be
printing out 2 significant digits. It's fundamentally misleading for
you to be printing 15.79 or 15.92 instead of 15.
Joe
> -----Original Message-----
> From: gcc-help-owner@gcc.gnu.org
> [mailto:gcc-help-owner@gcc.gnu.org] On Behalf Of Toon Moene
> Sent: Thursday, October 10, 2002 14:27
> To: Emil Block
> Cc: gcc-help@gcc.gnu.org
> Subject: Re: Formatted Read Accuracy
>
>
> Emil Block wrote:
>
> > I have confirmed with a debuger (and write statements) that "line"
> > indeed contains 67.9936, and after the read the value is 67.9935989
> > with G77 and is 67.9936 with F77.
>
> I'm afraid I just don't see your problem.
>
> I tried the following complete, stand-alone program:
>
> $ cat trivial.f
> READ '(F9.4)',X
> PRINT '(F9.4)',X
> END
> $ g77 trivial.f
> $ ./a.out
> 67.9936
> 67.9936
>
> The second `67.9936' is the output of the program - seems
> perfectly OK
> to me ...
>
> Now, if you really want to be scared s***less, try the following with
> your favourite Fortran compiler:
>
> $ cat trivial2.f
> READ '(F12.0)',X
> PRINT '(F12.0)',X
> END
> $ <fortran-compiler> trivial2.f
> $ ./a.out
> 839380840.
> ???? <- Scary, ain't it :-)
>
> Floating point arithmetic - not for the faint-of-heart.
>
> --
> Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31
> 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The
> Netherlands Maintainer, GNU Fortran 77:
> http://gcc.gnu.org/onlinedocs/g77_news.html
> Join GNU Fortran
> 95: http://g95.sourceforge.net/ (under construction)
>
>