Quote:

> PRECOR=(B1*B1*PAK + (1-PAK)/B1)**(-1.5)

I note that in the sample output, B1 is always 1.

For any finite value of PAK, 1*1*PAK = PAK, (1-PAK)/B1 = 1-PAK,

so this is equivalent to (PAK + (1-PAK)).

When ABS(PAK) is much greater than 1, you'd get 0**(-1.5).

But all your values of PAK are close to 1, so we'd expect PRECOR = 1**(-1.5)

which is just 1, and indeed that's what your program usually prints.

What can produce a NaN?

0/0

infinity +/- infinity

infinity * 0, 0 * infinity, infinity/infinity

sqrt(-ve number)

However, you are using an operation which is not in the IEEE standard,

namely X ** (-1.5). It could possibly be a bug in the implementation

of real**real. I would be inclined to try

PRECOR = B1*B1*PAK + (1-PAK)/B1

PRECOR = 1/SQRT(PRECOR*PRECOR*PRECOR)

All of the operations in this version of the code are covered by the

IEEE standard, and for B1 > 0.1, PAK in [0.0,1.0] this certainly has

no business producing a NaN.

Quote:

>I am running this on:

> a 486/50 running Windows 3.1, 8 MBytes of RAM,

> code compiled as a Windows app using Watcom Fortran 9.0

> Program is a 32 bit exe, using Watcom's "386 supervisor"

> Am linking with FPI87 flag (no x87 emulation, use and require

> x87)

>The other interesting thing to note is that this doesn't appear

>to generate a NaN when run on a 386 with a 387 installed.

I've heard of "486" chips from a certain non-Intel manufacturer that

were shipped with a bug in the floating-point system, where an FMOV

followed by some other instruction would sometimes not happen. If

the FMOV is followed by an FWAIT, the bug doesn't bite. If your

compiler is generating FWAITs, and the library code for real**real

has FWAITs in the right places, or if you have actual Intel chips,

this isn't your problem.

--

"C is quirky, flawed, and an enormous success." -- Dennis M. Ritchie.