Looking for an Edit Descriptor Solution to a -0 indication

[Groundsel]

In a recent migration to X64, I noted a difference in display of small negative numbers.  These are numbers small enough that they are 0 to the number of figures requested.  In Win32, they used to appear as 0 suitably formatted as regards difits requested.  In X64, they appear as -0.  It seems totally trivial, however, it makes upward compatibility QA checks awkward because one gets a lot of "hits" in a text comparison of output which don't signify any real difference in calculations.

Of course, one can put in logic to set such small negative numbers to 0.  But I suspect there is an edit descriptor solution.  Does anyone know one?  I am looking for a way of getting a Fortran program to kill the minus sign unless there is non-zero content to display to the number of digits requested.  As noted, this appears to me to have been the default in Win32.

[Steven_L_Intel1]

It's also possible that you are using an older compiler version on Win32 - we changed the behavior some time ago of this because the standard requires the minus sign. I get the same results in 32 and 64-bit with -.005 rounded to one fraction digit. This has come up before - the best recommendation seems to be to write the value to a string, search it for "-0.00" (or whatever) and remove the minus before printing. You could build this into a function that is called from the WRITE/PRINT statement.

[Groundsel]

Nice thought, Steve,

And you were right about the old compiler.  The thought that this might be in play had occurred to me too.  I did it because I wanted to test the transition from Windows XP (on an old machine) using Win32 to Windows 7 on a newer build machine using X64 in one swoop.

In light of your observation, however, I settled for the Win32 to X64 test only.  I rebuilt the Win32 solution using Composer XE-2013 Sp1 Update 1, the same compiler and (Windows 7) machine as I used for the X64 build.  I hoped that I would then gev the -0's consistently in all compared calculations.  However, II still got the old 0's with Win32 (minus sign killed on small negative numbers which are 0 to the number of digits displayed).

I am unwilling to put manipulation into the programs for such a purpose as killing a sign.  So, for the QA exercise, I shall write a small utility to work over the output files and remove any such negative signs using something like the string manipulation you suggest.

I can understand why the standard would have made this change.  It communicates that the ostensible 0 displayed is actually a small negaive number which rounds to 0.  However, it would have been nice if the framers of the standard had provided an over-ride edit descriptor for ease of upward compatibility checks.

[Steven_L_Intel1]

It's not really that the standard made a change, it's that we weren't doing what the standard required.

[Peter_P_1]

I've got the same problem with QA since I started using IVF 14.0.

According to the documentation the compiler option "/assume:[no]minus0" should adjust this minus sign behaviour, but it now seems to have no effect, i.e. always uses the new standard compliant behaviour no matter which way the option is set.

[Lorri_M_Intel · Accepted solution]

Try:

              /assume:nostd_minus0_rounding

That should help the output.

[Peter_P_1]

Thanks Lorri; that does the trick!