S
Sean
What I will describe is an abstraction of a problem I encountered.
Let's say we have a positive double array x[],
use a for loop I find out the minimal value of in x[],
and let y = min{ x[] },
then I use another for loop in which I do this:
z = x - y
if (z == 0.0) min_index = i;
min_index is initially set to -1
I use cygwin gcc 3.4.4.
I wrote c code simpliy as I describe above, then I have no problem
finding
the right min_index
But in a more complicated code which basiclly does the same thing,
then weird problem happens.
If I switch the optimization option off, then I get the right result.
If I compile the code with -O2/3/4 then min_index = -1
i.e. non of the values in z[] equals to 0.
add a printf to print out the smallest value of z[],
then I find that the smallest value is very close to zero (~10^-15
10^-18)
but not zero.
My quesiton is: is it possible to get a-a !=0 but close to zero in FP
arithmetic ?
Is FP arithmetic deterministic? Is there other errors in FP arithmetic
other than
rounding errors?
I found an article which seems relevant
http://hal.archives-ouvertes.fr/hal-00128124/en/
In this paper, the following paragraphy says something that is very
new to me.
Can anyone give me some quick explainations?
Despite, or perhaps because of, the prevalence of “IEEE-compliant”
systems,
there exist a number of myths of what IEEE-compliance really entails
from the
point of view of programsemantics. We shall discuss the following
myths, among
others:
• “Since C’s float (resp. double) type is mapped to IEEE single (resp..
double) precision arithmetic, arithmetic operations have a uniquely
de-
fined meaning across platforms.”
• “Arithmetic operations are deterministic; that is, if I do z=x+y in
two
places in the same program and my program never touches x and y in the
meantime, then the results should be the same.”
• A variant: “If x < 1 tests true at one point, then x < 1 stays true
later
if I never modify x.”
• “The same program, strictly compliant with the C standard with no
“un-
defined behaviours”, should yield identical results if compiled on the
same
IEEE-compliant platform by different compliant compilers.”
Let's say we have a positive double array x[],
use a for loop I find out the minimal value of in x[],
and let y = min{ x[] },
then I use another for loop in which I do this:
z = x - y
if (z == 0.0) min_index = i;
min_index is initially set to -1
I use cygwin gcc 3.4.4.
I wrote c code simpliy as I describe above, then I have no problem
finding
the right min_index
But in a more complicated code which basiclly does the same thing,
then weird problem happens.
If I switch the optimization option off, then I get the right result.
If I compile the code with -O2/3/4 then min_index = -1
i.e. non of the values in z[] equals to 0.
add a printf to print out the smallest value of z[],
then I find that the smallest value is very close to zero (~10^-15
10^-18)
but not zero.
My quesiton is: is it possible to get a-a !=0 but close to zero in FP
arithmetic ?
Is FP arithmetic deterministic? Is there other errors in FP arithmetic
other than
rounding errors?
I found an article which seems relevant
http://hal.archives-ouvertes.fr/hal-00128124/en/
In this paper, the following paragraphy says something that is very
new to me.
Can anyone give me some quick explainations?
Despite, or perhaps because of, the prevalence of “IEEE-compliant”
systems,
there exist a number of myths of what IEEE-compliance really entails
from the
point of view of programsemantics. We shall discuss the following
myths, among
others:
• “Since C’s float (resp. double) type is mapped to IEEE single (resp..
double) precision arithmetic, arithmetic operations have a uniquely
de-
fined meaning across platforms.”
• “Arithmetic operations are deterministic; that is, if I do z=x+y in
two
places in the same program and my program never touches x and y in the
meantime, then the results should be the same.”
• A variant: “If x < 1 tests true at one point, then x < 1 stays true
later
if I never modify x.”
• “The same program, strictly compliant with the C standard with no
“un-
defined behaviours”, should yield identical results if compiled on the
same
IEEE-compliant platform by different compliant compilers.”