Detecting NaN

[DavidWhite]

For some combination of sets of data, by program fails to converge.

I have determined that some variables end up with NaN.

My program doesn't stop when I'm using  /fpe:0

Any ideas how to catch where this NaNny hitchhiker gets on?

Since this is a DLL called from Excel, I need to drive the inputs from Excel.  I have discovered that I need to run the program with one set of inputs (all breakpoints turned off), then change the inputs in a specific way, and the next call reports failed values, in part of the code running to the iteration limit of 1000 iterations.  I assume that the NaN occurs somewhere in or before this section of code, but stepping through the iterations is too lengthy.  I thought that /fpe:0 would flag when the error occurs, but the program doesn't break, just returns the bad data to Excel.

Thanks,

David

[andrew_4619]

There is the ISNAN function perhaps you could use this and/or conditional breakpoints in the debugger to detect the point the nan appears which might give the required insight?

[IanH]

Have you tried the /fpe-all:0 option?  Excel probably sets the floating point environment to be what it wants, not what you supplied to the Fortran compile (I suspect /fpe:xx requires a Fortran main program to work)

See also the IEEE_ARITHMETIC and IEEE_EXCEPTIONS standard stuff.

[DavidWhite]

Thanks, Ian.

Caught the nannygoat first time!

/fpe-all:0 works. It would be useful if that was one of the options in VS, instead of having to add it as an extra option.

Thanks,

David

[TommyCee]

This is an interesting issue David posted.  I, too, struggled w/ NaN issues in some hairy code I was working with a while back.  This code implemented a number of hairy integrations, which involved numerous iterations of various subroutines.  My runtime errors were expressed as:

M6201 runtime error (DOMAIN)

I posted this issue here:

http://software.intel.com/en-us/forums/topic/277207

Ultimately, the /fpe:0 switch setting was suggested, which did help me trace the problem when I tried it.  But I was unaware of /fpe-all:0 until reading this post.  My impression is that /fpe-all:0 is more powerful/more robust and may be a lot more useful in elucidating the NaN buggers at runtime.