Any differences in REAL(16) for Linux and Windows implementations?

[stevencapper]

I've downloaded the Linux Fortran v8.1 compiler build 20041118Z as well as the Windows Visual Fortran build 20040802.

I am coding a numerical integrator which implements an nd Newton's method solver. The code has been compiled under Visual Studio .net 2003 and using a linux makefile with the default real and double kinds set to 128 bit. There is, however, a remarkable difference in accuracy between the two programs. Any constants that I've calculated are identically equal (up to default printout precision > 30 digits). The linux solver appears to have an upper accuracy limit of 27 digits, whilst the windows one has 31 digits.

I know for the default real kind, there's a difference in precision between the two (http://support.intel.com/support/performancetools/fortran/sb/CS-007783.htm).
Should this affect REAL(16), if so are there any compiler flags which would facilitate consistent behaviour?

Cheers,
--
Steven Capper

[Steven_L_Intel1]

There is no difference in the implementation. I would urge you to download and install current versions of those compilers from File Downloads in Intel Premier Support. (You will have to register for this.)

If the difference persists with current compilers, please let us know through Premier Support and supply a sample.

The Windows compiler you have is several months older than the Linux compiler, and this could account for some differences. You should also look to see which options are set implicitly in the Visual Studio environment - you can see this under Command Line in the Fortran property tab.

[stevencapper]

Thanks for the quick response.

The age difference is something I've not considered for the Windows compiler. I will look in to that. I've checked the Visual Studio compile flags and there's nothing out of the ordinary that I can see. At the moment I'm working with a debug build so there are no fancy compiler options other that the real, double 16 default types.

I think I'm going to have to locate where the apparent "precision loss" starts under linux. Unfortunately that won't be easy as there's a lot of code to go through.

Are there any sanity check benchmarks that you can recommend for fortran, as there may be a problem with my linux libraries (I'm running Gentoo)?

Cheers,
--
Steven Capper

[Steven_L_Intel1]

If you're working with a debug build, you get no optimization, which could definitely change results.

I would not trust any "sanity tests" you happen to find - most of them are flawed in one way or another.

[TimP]

I just ran Paranoia with -r16, with the current 32-bit linux compiler. It showed consistent 113-bit precision, with a variety of reasonable options.

[stevencapper]

Thanks for running the tests. I am beginning to think that there may be a problem with my linux system. As I've compiled the code on a DEC alpha (f90 -r16) and the program gives pretty much identical accuracy results to the Windows program.

Do the Intel linux libraries have and dependence (for maths operations) on any of the system libraries?

Cheers,
--
Steven Capper

[Steven_L_Intel1]

Not that I am aware of.

[stevencapper]

It's as you suggested originally Steve. Installing the latest Windows compiler reproduced the same problem. I have switched to the following compiler builds:
Windows: 20040802Z
Linux: 20040803Z
And the code now runs perfectly.

[Steven_L_Intel1]

Please submit a problem report to Intel Premier Support so that we can investigate. It could be that the new compilers are correct and that you are depending on incorrect results - or a bug could have been introduced.

[Steven_L_Intel1]

Thanks for the report. It was the math library (which does REAL*16 arithmetic) that changed. Your code, at one point, has a value that is almost but not quite -1.0 and adds 1.0 to it. This is a classic issue called "cancellation error", so the result is very small, but the new result is a bit TOO small considering the precision. I've passed it on to the developers.