Martin Joergensen opined:
[color=blue]
> Hi,
>
> I've encountered a really, *really*, REALLY strange error :-)
>
> I have a for-loop and after 8 runs I get strange results...... I
> mean: A really strange result....
>
>
> I'm calculating temperatures. T[j][i] = 20 degrees at all
> times.... The 2D T-array looks like this:
>
> | 2: 3: ..... i-direction goes to the right ->
> --+----------
> 2: | 20 20
> 3: | 20 20
>
> j-direction goes down
>
> (index 1 and 4 = 0, but they don't matter)
>
> The code *that works* looks like this:
> - - - - - - - - - - - -
>
> {
> /* copy 2D (old) temperatures to 1D-array */
> count = 0;
> solved_temp[0] = 0;
>
> /* number_of_interior_cells = 4 */
> for(j=2, i=1, no=1; no<=(int) number_of_interior_cells; no++)
> {
> /* update columns (x-value) */
> i++;
>
> solved_temp[no] = T[j][i];
> solved_temp[no] += ( hx[j][i] * ( T[j][i-1]-T[j][i] ) )
> / h0[j][i];
> solved_temp[no] += ( hx[j][i+1] * ( T[j][i+1]-T[j][i] ) )
> / h0[j][i];
> solved_temp[no] += ( hy[j][i] * ( T[j-1][i]-T[j][i] ) )
> / h0[j][i];
> solved_temp[no] += ( hy[j+1][i] * ( T[j+1][i]-T[j][i] ) )
> / h0[j][i];
>
> /* below you see the code that *doesn't work* - isn't it
> the same??? */
>
> //solved_temp[no] = T[j][i] + (
> // hx[j][i] * ( T[j][i-1]-T[j][i] ) + hx[j][i+1] * (
> T[j][i+1]-T[j][i] ) +
> // hy[j][i] * ( T[j-1][i]-T[j][i] ) + hy[j+1][i] * (
> T[j+1][i]-T[j][i] )
> // ) / h0[j][i];
>
> if(i == nx-1) /* hits east boundary? */
> {
> j++; /* next row */
> i=1; /* reset x-coordinate */
> }
> }
> }
>
> The expected result is that solved_temp[1] = 20, solved_temp[2] =
> 20, solved_temp[3] = 20, solved_temp[4] = 20 at all times. If I
> swap the above outcommented/commented sections with each other, I
> get what I expect the first 7 times. On the 8th time I get that
> the next result for solved_temp[1] = -1.#IND000000000000, but the
> other results are okay....
>
> What exactly is that -1.#IND000000000000 means?[/color]
My guess is that your commented out code overflows. The above looks
like some IEEE error/overflow/NaN thingy. It's still too much weekend
'round here for a closer look. Also, you should have really posted a
compilable example that shows the problem.
[color=blue]
> And isn't it exactly the same code??? I'm pretty confused...[/color]
Mathematically, it probably is. Computers, unfortunately don't have
infinite precision. Therein may lie your undoing.
[color=blue]
> In case you're wondering, hx or hy is either 0 or 1 as you can
> see below and all the temperature differences is 0, so it
> shouldn't matter anyway... h0 = 2 but also that shouldn't change
> anything since everything gives 0 so I have something which is 0
> divided by 2 and that ofcourse should give 0........ It all ends
> up in (20 + 0) = 20...
>
> Printing hx (step = 8):
>
> i=1: i=2: i=3:
> i=4:
> j=1: -> 0.00000 -> 0.00000 -> 0.00000 -> 0.00000
> j=2: -> 0.00000 -> 0.00000 -> 1.00000 -> 0.00000
> j=3: -> 0.00000 -> 0.00000 -> 1.00000 -> 0.00000
> j=4: -> 0.00000 -> 0.00000 -> 0.00000 -> 0.00000
>
> Printing hy (step = 8):
>
> i=1: i=2: i=3:
> i=4:
> j=1: -> 0.00000 -> 0.00000 -> 0.00000 -> 0.00000
> j=2: -> 0.00000 -> 0.00000 -> 0.00000 -> 0.00000
> j=3: -> 0.00000 -> 1.00000 -> 1.00000 -> 0.00000
> j=4: -> 0.00000 -> 0.00000 -> 0.00000 -> 0.00000
>
> (only 5 decimal digits shown, but it shouldn't change anything in
> the big picture I guess)....
>
> Why does it work when I calculate solved_temp[no] in 5 individual
> steps instead of in one long calculation? Even Microsoft Visual
> Studio 2005 debugger agrees with me, but then I step over the
> calculation line and find this stupid/strange result......!
>
> I hope somebody can explain this really weird behaviour... I hope
> there's a "natural" explanation like "stack overflow" or
> whatever....?
>
> I was a bit afraid of posting this if I didn't check my code
> properly but now I've looked at it for about 1-2 hours and when
> my debugger even agrees with me and I then choose F10 "step over"
> and get another result, then I think I need professional help :-)
>
> It works now (with 5 individual calculations), but I just want to
> be sure that this error doesn't come back later....[/color]
I'd also recommend you find a good text on the pitfalls of using finite
precision floating point arithmetic. One fairly good link has been
posted here a couple of months back. The only thing I remember about
it was that it was on the Sun site somewhere.
--
Why use Windows, since there is a door?
(By
fachat@galileo.rhein-neckar.de, Andre Fachat)
<http://clc-wiki.net/wiki/Introduction_to_comp.lang.c>
