all the variables are double precision, except nx,ny,L and r that are
integer
A1 = -0.1d0
A2 = -0.1d0
B1 = 1.0d0
B2 = 1.2d0
r = 2
dx = (B1-A1)/dble(nx)
dy = (B2-A2)/dble(ny)
Do L=1,ltop
headlev(L)%hx = dx
headlev(L)%hy = dy
dx=dx/dble(r)
dy=dy/dble(r)
End do
when I print dx and dy it shows :
0.550000000000000 0.650000000000000
0.275000000000000 0.325000000000000
0.137500000000000 0.162500000000000
6.875000000000001E-002 8.125000000000000E-002
3.437500000000000E-002 4.062500000000000E-002
1.718750000000000E-002 2.031250000000000E-002
8.593750000000001E-003 1.015625000000000E-002
my question is about the "1" that is in the end (
6.875000000000001E-002) . What can I do to eleminate the suprious and
keep the variable as double precision ???
thank you
millena
> 6.875000000000001E-002 8.125000000000000E-002
> my question is about the "1" that is in the end (
> 6.875000000000001E-002) . What can I do to eleminate the suprious and
> keep the variable as double precision ???
You could get an IEEE 754R machine with decimal floating point,
or print with an explicit format (I remembered this time) that specifies
one fewer digit than you see.
Are you really worried about the 1, or just don't think it
looks nice?
-- glen
Why do you think that the variable is not double precision? Double
precision does not mean that it is perfect, merely that it's about twice
as good as single precision. There will still potentially be errors of
this nature in the smallest bit.
- Brooks
--
The "bmoses-nospam" address is valid; no unmunging needed.
Look up a book on numerical analysis and floating-point arithmetic.
Your computer cannot represent dx exactly in binary arithmetic, so
you should always expect relative errors of order epsilon(1d0),
and that seems to be what you got. Think of calculating the fraction
1.0/3.0 in ordinary decimal arithmetic. Whatever finite number of
decimal places you work to, you will get 0.333...33, which is wrong by
3 in the last digit. In binary arithmetic this sort of thing happens
for any rational number whose integer denominator is not a power of 2.
If you want to avoid seeing spurious ...000000001 (and ...999999999)
use an explicit format (D,E,EN,ES,F or G) that lets you control the
number of digits printed. I suspect you were using * (list-directed)
format, in which the compiler-writer chose the number of digits, and
you have told us you disagree with her or his choice.
You were objecting to the 16th significant digit in the output. Unless
you are doing pure mathematics, you should also consider whether the
input data and the algorithm are good enough for you to believe all
the previous 15 digits.
--
John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john....@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
>Are you really worried about the 1, or just don't think it
>looks nice?
I am really worried about the "1", but not when I print... but during
my the others calculus... because when I have this spurious it change
the position of my adaptive mesh. I really would like to "cut" it . I
tried to work with single precision but is worst...
So... as can't have a machine with a decimal floating point I think
that I will restrict my domain to work only with a "pure" numbers...
:o(
but.. thank you so much
millena
Bernhard.
OK, the problem is that you don't know which way it will round, and
sometimes it is the wrong way. My only solution to that is to force it
by adding (or subtracting) a small amount before truncating it.
Yes it is ugly, can never be perfect, but works most of the time.
Having worked on mesh problems before, people like to choose values that
are close to mesh lines, which means the problem shows up much more
often than it would on average. You want to add an amount that is much
less likely to end up on a mesh rounding boundary. One half, or most
any other simple fraction, is probably not good, as someone, someday,
will try that fraction.
Hopefully that helps, otherwise there should be enough people here
to find a solution that works. Note that additional precision doesn't
help, but only moves the rounding points.
-- glen