- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The option has only limited effect. Can you show us a short program that demonstrates the issue?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page