- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
my problem is somewhat hard to pin down, since I notice it only on a fairly high level in the code. In the code I am developing, a number of matrix operations are performed using the Numerical Recipes routines. ifc gives erroneous and internally inconsistent results for singular value decomposition and for Cholesky decomposition of my positive-definite symmetric matrix. The operations occasionally do involve the evaluation of differences between nearly equal numbers, but nowhere do these get close to machine precision.
I compared the test results with those obtained with the Portland Group Fortran compiler (which is twice as slow; hats off for to you for speed!). This compiler does produce the correct result from the same code.
I would be happy to supply more details of the problem if anyone has a clue where to look.
Thanks,
Gijs
my problem is somewhat hard to pin down, since I notice it only on a fairly high level in the code. In the code I am developing, a number of matrix operations are performed using the Numerical Recipes routines. ifc gives erroneous and internally inconsistent results for singular value decomposition and for Cholesky decomposition of my positive-definite symmetric matrix. The operations occasionally do involve the evaluation of differences between nearly equal numbers, but nowhere do these get close to machine precision.
I compared the test results with those obtained with the Portland Group Fortran compiler (which is twice as slow; hats off for to you for speed!). This compiler does produce the correct result from the same code.
I would be happy to supply more details of the problem if anyone has a clue where to look.
Thanks,
Gijs
Link Copied
4 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Since last week, I did a little additional research. I found that the actual values returned by my program compiled by ifc *change* according to whether I get external routines from a linked library, are compiled along with the other source files, or are included as internal subroutines. Again, I tested every version against our Portland compiler, which gives the same result every time.
My Linux is v2.4.9-13, and the machine is an SGI Pentium III 800 MHz. Compiler flags are -O0 -mp (though changing these has no effect on the results; haven't tried the -x? flags). Same results for compiling from scratch and running on a similar 900 MHz system. Still stymied.
Thanks for any help.
My Linux is v2.4.9-13, and the machine is an SGI Pentium III 800 MHz. Compiler flags are -O0 -mp (though changing these has no effect on the results; haven't tried the -x? flags). Same results for compiling from scratch and running on a similar 900 MHz system. Still stymied.
Thanks for any help.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The only circumstances I have come across which might give the sort of behavior you describe involved changing the precision by modification of the floating point control word at runtime, leading to inconsistencies with the math library.
Unless this helps, please submit an issue, with a test case if at all possible, to Intel Premier Support at htpps:premier.intel.com .
Martyn
Unless this helps, please submit an issue, with a test case if at all possible, to Intel Premier Support at htpps:premier.intel.com .
Martyn
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks.
I found a possible cause of the problem: there is a difference in the way the compilers handle array references: an array A(:) which is indexed A(2:1) is handled as a zero length array by the Portland compiler (the desired behaviour in my case), but gives rise to a memory leak with the Intel compiler. Note that this sloppy programming is NOT flagged an error to by compiling with -CB! I will submit an issue to Premier Support with a sample program.
Gijs
I found a possible cause of the problem: there is a difference in the way the compilers handle array references: an array A(:) which is indexed A(2:1) is handled as a zero length array by the Portland compiler (the desired behaviour in my case), but gives rise to a memory leak with the Intel compiler. Note that this sloppy programming is NOT flagged an error to by compiling with -CB! I will submit an issue to Premier Support with a sample program.
Gijs
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am having similiar problems and am not sure why. Any updates?

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page