On my CentOS 5 box, in a C++ program that does much arithmetic, including numerous matrix multiplications, I have a situation in in which the result depends on the nature of nearby I/O. Thus, with all arithmetic done with type double, and where values are mostly in the range [-1.0e0,+1.0e0] or nearby, I do:
cerr << "some stuff" << endl; mat3 = matmult(mat1,mat2);
I get a difference of the order 1.0e-15 depending on whether the cerr line does or does not end in "endl" as shown.
I am imagining that there is some "randomness" in the roundoff that depends on the I/O situation. Is this credible? Any other suggestions?
Thanks for your help, Mike.
Hello Michael,
On Sun, 2011-04-24 at 02:54 +0000, Michael D. Berger wrote:
cerr << "some stuff" << endl; mat3 = matmult(mat1,mat2);
I get a difference of the order 1.0e-15 depending on whether the cerr line does or does not end in "endl" as shown.
If the exact same input produces different results depending on whether or not you add and endl before the function call would probably count as a bug. Could be something like a status bit that does not get cleared when it should be.
However, since this is such a gcc specific issue I would suggest you take this upstream: http://gcc.gnu.org/lists.html . People there will probably be able to help you better than the people on this list.
Regards, Leonard.
On Apr 23, 2011, at 9:54 PM, Michael D. Berger wrote:
On my CentOS 5 box, in a C++ program that does much arithmetic, including numerous matrix multiplications, I have a situation in in which the result depends on the nature of nearby I/O. Thus, with all arithmetic done with type double, and where values are mostly in the range [-1.0e0,+1.0e0] or nearby, I do:
cerr << "some stuff" << endl; mat3 = matmult(mat1,mat2);
I get a difference of the order 1.0e-15 depending on whether the cerr line does or does not end in "endl" as shown.
I am imagining that there is some "randomness" in the roundoff that depends on the I/O situation. Is this credible? Any other suggestions?
Thanks for your help, Mike.
Mike, I think I'm understanding your problem. This just sounds like a floating point rounding issue.
You've read the floating point bible already? http://download.oracle.com/docs/cd/E19957-01/806-3568/ncg_goldberg.html
Todd
-
Leonard den Ottolander -
Michael D. Berger -
Todd Rinaldo