Trouble with long equation

h-faber · ‎09-09-2005

Hi,
I have some strange behaviour with a "normal" equation.
Consider this (hard to read, I know) line:

C(7)=(E(8)-(2*E(10)+2*E(46)+E(42)))*PI/E(5)-E(42)

All single values are of type REAL, all of them have neither NULL nor 0 value.
When running through this line, the result I get is frustrating "NaN". I have several more such examples, same behaviour. Now when I split this long equation into

HILF1C7=2*E(10)
HILF2C7=2*E(46)
HILF3C7=HILF1C7+HILF2C7+E(42)
HILF4C7=E(8)-HILF3C7
HILF5C7= HILF4C7*PI
HILF6C7=E(5)-E(42)
C(7)=HILF5C7/HILF6C7

guess what. No more NaN but a usual (desired) value I can continue calculating with.
I have dozens of such equations so I cannot believe to need to split all of them into shortest pieces.

This behaviour occurs under Intel Visual Fortran Compiler 8.1 within Visual Studio 2003.
Does anyone here have an idea what to do to avoid a time-spending effort to split these equations?

Thanks again in advance.
Harald

Steven_L_Intel1 · ‎09-09-2005

You need to restock your supply of parentheses. Try this:

C(7)=(E(8)-(2*E(10)+2*E(46)+E(42)))*PI/(E(5)-E(42))

h-faber · ‎09-09-2005

Hi Steve,
thanks for your quick answer. But as I see, your suggestion gives a different mathematical result

C(7)=(E(8)-(2*E(10)+2*E(46)+E(42)))*PI/(E(5)-E(42))

is different from

C(7)=(E(8)-(2*E(10)+2*E(46)+E(42)))*PI/E(5)-E(42)

To shorten them, yours is

C(7)=X*PI/(E(5)-E(42))

while the original is

C(7)=X*PI/E(5)-E(42) which is like C(7)=[X*PI/E(5)]-E(42)

Or even shorter, I have A/B-C which you turn into A/(B-C).

Steven_L_Intel1 · ‎09-09-2005

Yes, it is different, but it matches (or at least comes closer to) your split-out assignments where you do the subtraction first. I don't know what you really want here, but I suggest you fully parenthesize the expression the way you want. If you still have problemss, please submit a test case.

greldak · ‎09-09-2005

I think that was Steve's point - your single line code was (A/B)-C but your split down one amounted to A/(B-C)

Are you sure your numerator will fit into a real?

jparsly · ‎09-09-2005

We really need to see the value of the numbers.

You have to make sure that you are not setting up a condition

where NaN is the expected result. For example if you are doing

(A/B)-C, you don't want both A and B to be 0.

h-faber · ‎09-12-2005

Well, this all looks very strange here. When I tried a smaller test program with the values we have trouble with, everything is fine, no NaN in sight:

PROGRAM NaNTest
REAL T2,E,K1
DIMENSION E(10)

T2=1.483530
E(6)=0.4000000
E(10)=0.1000000
K1=T2/E(6)/(T2/E(6)-(E(6)/E(10)/(5+E(6)/E(10))))
PRINT *,K1
STOP
END

But in our code this comes to a NaN problem. We wonder why. The program goes through some do-loop, and when it comes to the 3rd iteration, the subroutine with this equation produces a NaN while in the two former iterations it does not. Of course with different values.

The declaration is done by

implicit real (A-Z)

Anyone having an idea what the reason for this problem could be?

hansr · ‎09-12-2005

What are your Project settings?

I think we had similar troubles before we set

the following compiler and linker options :
* Fortran->Data->Local Variable Storage = All Variables SAVE
* Fortran->Data->Initialize Local Saved Scalars to Zero = Yes

Good luck

Hans

h-faber · ‎09-12-2005

Hallo Hans,
thanks for this idea, sounds reasonable. Anyway, after the suggested changes we have still the same problem also after a build-all.

Steven_L_Intel1 · ‎09-12-2005

You may be addressing an array out of bounds. Does this happen in a debug build? If so, you should be able to step through the code with the debugger and find where the NaN is coming from (perhaps by watching the value of variables as they change.)

h-faber · ‎09-12-2005

>sblionel wrote:
You may be addressing an array out of bounds. Does this happen in a debug build?

Not only in debug mode, but also when running without debugging.

>If so, you should be able to step through the code with the debugger and find where the NaN is coming from (perhaps by watching the value of variables as they change.)

This is the problem. The values the debugger shows are the ones I have posted above in a former message.

K1=T2/E(6)/(T2/E(6)-(E(6)/E(10)/(5+E(6)/E(10))))

T2=1.483530
E(6)=0.4000000
E(10)=0.1000000

And, this is not the only equation producing NaN. There are some more, looking similar. Mysterious is that splitting the equations into sub-calculations turns out to become no NaN.

Steven_L_Intel1 · ‎09-12-2005

I didn't see that you resolved the inconsistency between the long equation and your separate expressions.

hansr · ‎09-12-2005

I remember: Searching wrong array bounds is very hard. I have spent much time, also with the tool "ftnchek".

Hans

greldak · ‎09-12-2005

It might be that somewhere in the optimisation an intermediate value is generated which is NaN have you tried compiling with no optimisation for the affected routine.

Also as there are a lot of sequential divisions you could try rewriting your equation

K2=(T(2)/E(6))*((T(2)/E(6))-(E(6)/E(10))*(5+(E(6)/E(10))))

and see if that helps

h-faber · ‎09-12-2005

Hi Craig,

>It might be that somewhere in the optimisation an intermediate value is generated which is NaN have you tried compiling with no optimisation for the affected routine.

We use default values for optimization which is disabled.

>Also as there are a lot of sequential divisions you could try rewriting your equation
>K2=(T(2)/E(6))*((T(2)/E(6))-(E(6)/E(10))*(5+(E(6)/E(10))))>and see if that helps.

Unfortunately this is a different equation than ours.

h-faber · ‎09-12-2005

sblionel wrote:
I didn't see that you resolved the inconsistency between the long equation and your separate expressions.

We also tried

K1=(T2/E(6))/((T2/E(6))-((E(6)/E(10))/(5+(E(6)/E(10)))))

but still NaN.
Remember that this equation works twice but in the third loop with the same values it produces a NaN.

A solution for this problem is really important for us as we have dozens or even hundreds of such equations which we do not want to split each into 10 pieces or so.

Steven_L_Intel1 · ‎09-12-2005

If the problem persists with a current compiler, please submit a test case to Intel Premier Support and we'll be glad to take a look.

h-faber · ‎09-12-2005

Hi Steve,
we have the 8.1 compiler as we and the customer once decided to take this one. It was even before 9.x was announced. A change in the current project in progress will not take place.
Sending the project might also be difficult as it contains customer data etc. But I will check this possibility.

Steven_L_Intel1 · ‎09-12-2005

Well, you can try the latest 8.1 compiler. But I can't imagine how we'll solve this in the forum.

greldak · ‎09-13-2005

its a rearrangement of your equation avoiding the use of sequential division opertors.

remember

a/b/c=ac/b

although I have seen fortran compilers which will treat it as a/bc and even ac/b in some levels of optimisation and a/bc in others. This is one reason why brackets are very important.

anthonyrichards · ‎09-13-2005

It would help a lot if

a) you gave the result of the simple computation for the values you give as being applicable when you get a Nan, and

b) a set of values, including the answer you get, for one of the preceding steps through the loop in the actual complicated program when you do not get a Nan.

That is, we need inputs for a,b,c,d,e etc and output X when you try to compute X=a/b/(c-d/e), or whatever, in both the program that gives the NAn and the simple example that fails to reproduce it. You must be very careful that you copy the equation exactly when running the simplified version.