Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Minus zero instead of zero?

Massimo
Beginner
1,873 Views

Greetings,

I am modifying some Fortran77 code to Fortran90 and I observe a strange phenomenon. The old code was compiled with the 2011 XE composer under Visual Studio 2010, the new one under 2016 XE composer under Visual Studio 2015 Community edition. To check that the code conversion did not introduce any mistake, I am both executable with the same input file. I do get the same output on a number of tests (quite encouraging), with one difference: the new executable writes -0.000 instead of 0.000. It should not be a matter of decimal positions, because the result is the cosine of 90 degrees. The code runs in simple precision: I doubt that could be the culprit. If it is, then it's a matter of F90 vs. F77 or of the new version of the compiler? Any idea?

Thanks is advance.

0 Kudos
11 Replies
andrew_4619
Honored Contributor III
1,873 Views

You previously got 0.000 when you should have had -0.000 due to a bug in IFORT ( not standards compliant). This change was a couple of years back maybe from memory. As far as I am aware there is no compiler option to revert to the old (incorrect) behavior,

0 Kudos
Massimo
Beginner
1,873 Views

Thank you for your prompt answer. Do I understand correctly that printing floating point zero as "minus zero" is the standard, expected behaviour? I confess I am bit surprised, and I am pretty sure users of the software would also be, but if that is how it is meant to appear, then I guess I have just to accept it.

0 Kudos
TimP
Honored Contributor III
1,873 Views
Minus zero would be the result of an inexact calculation which rounds to zero from the negative side. I think this situation was discussed on this forum.
0 Kudos
andrew_4619
Honored Contributor III
1,873 Views

There now appears to be a /assume:nominus0 compiler option that looks like it gives to 'old' behaviour

 

nominus0

The compiler uses Fortran 90/77 standard semantics in the SIGN intrinsic to treat -0.0 and +0.0 as 0.0, and writes a value of 0.0 with no sign on formatted output.

0 Kudos
Massimo
Beginner
1,873 Views

Apologies if I sound dumb, but is there a way to pass this option to the compiler from within Visual Studio? I looked at the options but could not find any place to customize the compiling process.

0 Kudos
andrew_4619
Honored Contributor III
1,873 Views

If it is not in anyway of the menu options on the project properties the way is to add it manually, right click on the oproject in solution explorer and select Properties. Then type it in:

Configuration Proprerties > Fortran > Command Line > Additional Options

It is not a dumb question, VS has a huge numbers of options and features . Having used  it for years I still keep learning new and useful things!

0 Kudos
Massimo
Beginner
1,873 Views

Thanks, right place found and option added. BUT no effect, I still have minus zero instead of zero. Perhaps a problem with numerical precision in the conversion from degree to radians? Input is in degrees, converted to radians as *acos(-1)./180. Input is 90, I should get a cosine of zero.

0 Kudos
Calvin_D_R_
New Contributor I
1,873 Views

In my latest installation: VS 2013, Intel Parallel Studio XE 2015 Composer Edition for Windows, the IEEE minus Zero option is at

Configuration Properties>Fortran>Floating Point>Enable IEEE Minus Zero Support

 

0 Kudos
Steven_L_Intel1
Employee
1,873 Views

The option has only limited effect. Can you show us a short program that demonstrates the issue?

0 Kudos
Massimo
Beginner
1,873 Views

Well spotted! But that did not solve my problem, so I dug a bit deeper and here is what I found.

Input 90 degrees, transform to radians by multiplying it by acos(-1.)/180, compute the cosine.... and get -4.3711388E-08 instead of zero. Printed out in F10.3 format I saw just -0.000, I'm going to put a threshold on the minimal value to be considered zero.. I do not really like that solution but I do see an alternative, right now.

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,873 Views

You might get closer using acos(-1.0_DP)/180.0_DP, compute cosine (in DP),... but not necessarily 0.0 (+/-). Thresholds are a necessary inconvenience (as well as reminder) of the nature of using non-infinite precision.

Question to ponder: If you have a hypothetical computer that has infinite precision (IEE754-like format), and it is instructed to perform an operation that produces a repeating fraction of infinite length, does it take an infinite amount of time to complete the instruction?

Jim Dempsey

0 Kudos
Reply