issue in machine constants imsl

[jossl]

Hello,

I am having some problems with the IFNAN and AMACH imsl functions.I am working with the intel fortran compiler (11.1) and Visual Studio 2008 and the version 6.0 of the IMSL libraries.

AMACH and IFNAN do not return the expected values when running the example following program.

It seems as though the library routines assume that the used machine does not support quiet NaN and IEEE floating-point format, although this should not be the case.

I am are looking forward for any helpful input.

Best regards,

Lisa Joss

----------------------------

example

---------------------------

program test

use AMACH_INT

use IFNAN_INT

implicit none

double precision :: X

logical :: log_ifnan, log_isnan

X = 0./0

log_ifnan = IFNAN(X)

! Check if NaN : specified as bit format not equal to itself

log_isnan = X .NE. X

print *, 'X = ', X

print *, 'X is NaN? ', log_ifnan, log_isnan

! AMACH(6) is a machine constant which should return a quiet NaN

X = AMACH(6)

log_ifnan = IFNAN(X)

log_isnan = X .NE. X

print *, 'X = ', X

print *, 'X is NaN? ', log_ifnan, log_isnan

end program

----------------------------

output

----------------------------

X = NaN

X is NaN? F T

X = 3.402198970993592E+038

X is NaN? T F

[mecej4]

The output that you get should be expected to depend on the /fpe:n option in effect (whether you explicitly specified it in your build configuration or project files, or the default value, or specified on the command line).

For example, with /fpe:0 the program will abort when asked to divide by floating zero.

With IFort 11.1.070 and IMSL 6.0, with /fpe:3 I get this output:

X = NaN
X is NaN? F T
X = NaN
X is NaN? T T

[jossl]

Thanks for the prompt answer.

I tried setting /fpe:3 as follows:

Project Properties

-> Fortran

-> Floating Point

-> Floating point exception handling:Produce NaN, signed infinities, and denormal results

-> Command Line

-> Additional Options: /fpe:3

Nonethelessthe output is kept unchanged. Is there maybe another place where properties are set which overwrites the /fpe:3 option?

[Steven_L_Intel1]

There are a couple of issues here.

The first is that the IMSL function IFNAN will return true only if the NaN is a "Signaling NaN". It does not consider a "Quiet NaN" to be a NaN, which I think is an incorrect choice, but that's the way it is written. Along with this, the IA-32 architecture will convert signaling NaNs to quiet NaNs on a floating point load. The NaN that gets generated by the divide is a quiet NaN (sign bit 1).

The second is that doing things such as "X .ne. X" are guaranteed to work only if the /fp:strict or /fp:source mode is enabled, though I find in this example it doesn't matter, at least with 12.1.

I would recommend instead the use of the Fortran 2003 standard IEEE_ARITHMETIC intrinsic module and its IEEE_IS_NAN function.

[jossl]

I still see a problem since X=AMACH(6) should give a quiet NaN but instead it returns 3.4E38 even if X is double precision (i.e. 3.4E38 is far from being close to the highest number).

Moreover, I have run the same code on a linux platform, and there everything was as expected (intel compiler 11.0, imsl 6.00).

However, I didn't really grasp the difference between a quiet NaN and a signaling NaN... I am a chemical enginner, and I see we don't speak the same language here... could you maybe re-express what you wanted to say in an easier way? :)

Thanks!

[Steven_L_Intel1]

Here is what I get with the 11.1 compiler, though I am using a "newer" IMSL 6 (the one that comes with the 12.1 compiler):

X = NaN
X is NaN? F T
X = NaN
X is NaN? T T

I don't know how you get 3.4E38, unless the build of IMSL you are using has a severe bug.

For a discussion of NaNs, I refer you to Wikipedia.

What are you using this for? Perhaps there's a better way.

[jossl]

Well actually I am solving differential equations with ivpag from the imsl libraries, and I encountered some strange things, of which the example with the NaNs. I fear that the IMSl libraries aren't used/built/installed in an appropriate manner.

How could I diagnose a severe bug in the build of the IMSL I am using?

[mecej4]

Some initial preparation doing mathematical transformations, if possible, is something that I should prefer to do instead of (i) mastering the intricacies of NaNs of various types, (ii) making sure that the compiler options have been properly selected to process these NaNs and infinities, and (iii) verifying whether the compiler, runtime and libraries such as IMSL process pathological input satisfactorily.

Are your differential equations singular or close to singular?

[jossl]

Ok... I'll explain the whole context:

We are using the IVPAG integrator of the IMSL numerical libraries in order to solve a system of stiff differential equations (which are not singular). We have encountered some substantial differences when compiling the program on different platforms and in different modes (debug/release):

- In Debug mode (Windows platform, compiled in Visual Studio 2008) the program runs as expected.

- When compiled in release mode (Linux platform) the integration is halted due to fatal error 7 from divpag:

*** FATAL ERROR 7 from DIVPAG. Integration halted after failing to

*** achieve corrector convergence, even after reducing the stepsize

*** by a factor of 1.0E+10 to H = 1.000000022351743D-11. TOL =

*** 1.000000000000000D-05 may be too small.

We are very much surprised by this since it does run in debug mode.

Moreover, we have observed (by chance) this strange behavior with the NaN stuff, and I was suspecting that the differences observed in both cases could be linked. Anyway, I would really like to be sure that the build of the IMSL libraries we are using isn't buggy!

Sorry for having been confusing in the previous posts...

[mecej4]

IMSL is mature and bugs are few.

However, a few months ago I noticed a subtle bug in another IMSL integrator, IVOAM: the IMSL routine expected that the FTZ (flush-to-zero) and DAZ (denormals-are-zero) flags would be off. With IMSL routines that call a user function, such as IVPAG and IVOAM, if the user function is compiled with these flags on, the flags may remain on after the user function returns control to IMSL, and cause a crash, incorrect results, etc.

See Strange bug (?) in FNL7, routine IVOAM

Perhaps the same work-around is worth trying. Check whether the IMSL setup has been run (to set FFLAGS, F90FLAGS, LINK_FNL_SHARED, etc.).

Contacting Roguewave support is another action to consider.

The Intel ODE integrator library is of high quality.