On Thu, 18 May 2006, Roland Schilling wrote:
> On Thu, 18 May 2006, Harvey Richardson - Consultant Benchmark Engineer wrote:
>
> > I very much doubt if the standard says anything.
"This standard does not specify ... (the) physical properties of the
representation of quantities and the method of rounding,
approximating, or computing numeric values on a particular
processor."
So the standard itself says that it doesn't say anything.
> > You just
> > have floating-point representation errors and you could
> > get either result depending on the rounding. The 0.4 is
> > not going to be stored exactly.
>
> OK, but that is something I already had in mind. If I print
> the to values to be compared with the format f24.20 I get
> 4.00000000000000000000 4.00000000000000000000
> i.e. 20 zeros after the digital point!
It could well be that what you are seeing here is that indeed
4.0 < 10.*0.4
but that, when rounded to double precision,
4.0 == 10.*0.4
This is not exactly new; I first encountered it on the Apollo
workstation back in the early 80s. It occurs because floating
point registers have more than double precision (on the Apollo
that was m68k, but the same applies to the x87).
Most of the time the excess precision just means that you get
more accurate results, but sometimes it makes weird things happen
like this. If you want to avoid that, you need to store the
subexpression (in this case the 10.*x) in a variable and reduce
the optimisation level far enough to avoid inter-statement
optimisation. In F2003, the latter can be achieved easily by
using the VOLATILE attribute on the variable you store into.
Cheers,
...............Malcolm Cohen ([log in to unmask])
|