Detecting NaN

Detecting NaN

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

5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

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?

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.

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

 

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.

Leave a Comment

Please sign in to add a comment. Not a member? Join today