Re: Problem with a small "exercise" code using compiler xlf
- From: glen herrmannsfeldt <gah@xxxxxxxxxxxxxxxx>
- Date: Tue, 4 Aug 2009 18:08:53 +0000 (UTC)
deltaquattro <deltaquattro@xxxxxxxxx> wrote:
< On 31 Lug, 17:46, Dave Allured <nos...@xxxxxxxxxx> wrote:
(snip)
<> When changing from REAL to DOUBLE PRECISION causes a radical change in
<> numeric results, that is symptomatic of either an unstable numerical
<> algorithm, or a program bug.
< I really disagree. It is simply an indication that you need more
< accuracy to describe your numerical problem. For example, if you have
< to compute a first derivative numerically, then *any* numerical
< algorithm implemented in floating point arithmetics, regardless of
< stability, will start to fail once the two points are "sufficiently
< near". How much "near" will depend on how many significant digits can
< be represented using your REAL(KIND=..) type. So it may simply be an
< indication of the fact that you need more significant digits. As a
< matter of fact, going from REAL to DOUBLE PRECISION solved part of the
< problem (the negative argument to sqrt). The missing culprit was found
< by e p chandler.
For many problems, increased precision will help, but not all.
<> Do the work, examine the intermediate values and work backwards, and you
<> shall find enlightenment.
< You're right, Dave, I should have gone through that, and I apologize
< if it looked like I asked you to do my work for me. If you have a look
< at my older posts you will see that, when I was a coder, I always did
< that, but in this case I had less time since it was not directly my
< job. Surely it isnt yours! So I wasn't expecting you to go through the
< hassle of examining the intermediate values. I was just hoping that
< you guys, being more experienced than me, would find be bug in less
< time, as indeed it was. Thanks to everybody,
In the case of problems like this, negative square roots when
the analytical solution can never be negative, in most cases more
presision doesn't help, and often the problem will show up at
higher precision and not at lower precision. My favorite example
is the calculation of standard deviation from the sum and sum of
squares of a set of data. With real data (with actual noise) it
isn't likely to happen, but with test data it is easy to get a
case where the standard deviation is zero, but rounding error
in the intermediate calculation gives a negative square root.
If the input values don't have exact binary representation,
then even with values near one, the rounding in the LSB can
easily cause problems. A similar case occurs in the
calculation of r, the correlation coefficient, in linear
regression calculations. Especially note that more precision
does not help.
Note that IEEE floating point allows for the selection of a
rounding mode, but that is rarely used in calculations.
In this case, one could choose one rounding mode for one part
of the calculation, and a different one for the other, such that
the result would tend to be non-negative when subtracted.
I have never known anyone to do that.
This also reminds me of a feature on the IBM Stretch computer
(not that I ever used one), which allows one to choose the
shifting in of zeros or ones in post normalization.
The suggestion was to run a program both ways and compare the
results. That would detect some types of precsion loss problems,
but not all.
-- glen
.
- References:
- Re: Problem with a small "exercise" code using compiler xlf
- From: deltaquattro
- Re: Problem with a small "exercise" code using compiler xlf
- Prev by Date: Re: Problem with a small "exercise" code using compiler xlf
- Next by Date: Re: c_loc - error with gfortran, not ifort
- Previous by thread: Re: Problem with a small "exercise" code using compiler xlf
- Next by thread: Re: Problem with a small "exercise" code using compiler xlf
- Index(es):
Relevant Pages
|
