3 replaced http://stackoverflow.com/ with https://stackoverflow.com/
source | link

To directly answer your question, you want to use the term epsilon. More accurately, it's machine epsilon but common usage drops "machine" and just uses epsilon.

Looking in my local copy of float.h I see:

#define DBL_EPSILON     2.2204460492503131e-016 /* smallest such that 1.0+DBL_EPSILON != 1.0 */  
#define FLT_EPSILON     1.192092896e-07F        /* smallest such that 1.0+FLT_EPSILON != 1.0 */  
#define LDBL_EPSILON    DBL_EPSILON             /* smallest such that 1.0+LDBL_EPSILON != 1.0 */

And the associated comments makes it clear that epsilon is the term you're referring to.

But we can also rely upon some other, external references to verify that epsilon is the correct term. See here, here, here, and finally this combination of SO query tagsSO query tags. I wasn't able to find a direct reference to the IEEE 754 standard to quote.


You didn't ask, but I found this reference that is very relevant to the example you provided to clarify your question.

Have a look at this blog article by Bruce Dawson of Valve on comparing floating point values for some insight as to why you don't want to use the comparison that you suggested.

There's quite a bit of information packed into that article, but this is the most relevant snipppet from there:

If comparing floats for equality is a bad idea then how about checking whether their difference is within some error bounds or epsilon value, like this:

bool isEqual = fabs(f1 – f2) <= epsilon;

With this calculation we can express the concept of two floats being close enough that we want to consider them to be equal. But what value should we use for epsilon?
Given our experimentation above we might be tempted to use the error in our sum, which was about 1.19e-7f. In fact, there’s even a define in float.h with that exact value, and it’s called FLT_EPSILON.
Clearly that’s it. The header file gods have spoken and FLT_EPSILON is the one true epsilon!
Except that that is rubbish. For numbers between 1.0 and 2.0 FLT_EPSILON represents the difference between adjacent floats. For numbers smaller than 1.0 an epsilon of FLT_EPSILON quickly becomes too large, and with small enough numbers FLT_EPSILON may be bigger than the numbers you are comparing!

Dawson goes over quite a few other considerations about the intricacies involved when comparing floats and dealing with very small values like this, so I would encourage your reading the rest of his post.

To directly answer your question, you want to use the term epsilon. More accurately, it's machine epsilon but common usage drops "machine" and just uses epsilon.

Looking in my local copy of float.h I see:

#define DBL_EPSILON     2.2204460492503131e-016 /* smallest such that 1.0+DBL_EPSILON != 1.0 */  
#define FLT_EPSILON     1.192092896e-07F        /* smallest such that 1.0+FLT_EPSILON != 1.0 */  
#define LDBL_EPSILON    DBL_EPSILON             /* smallest such that 1.0+LDBL_EPSILON != 1.0 */

And the associated comments makes it clear that epsilon is the term you're referring to.

But we can also rely upon some other, external references to verify that epsilon is the correct term. See here, here, here, and finally this combination of SO query tags. I wasn't able to find a direct reference to the IEEE 754 standard to quote.


You didn't ask, but I found this reference that is very relevant to the example you provided to clarify your question.

Have a look at this blog article by Bruce Dawson of Valve on comparing floating point values for some insight as to why you don't want to use the comparison that you suggested.

There's quite a bit of information packed into that article, but this is the most relevant snipppet from there:

If comparing floats for equality is a bad idea then how about checking whether their difference is within some error bounds or epsilon value, like this:

bool isEqual = fabs(f1 – f2) <= epsilon;

With this calculation we can express the concept of two floats being close enough that we want to consider them to be equal. But what value should we use for epsilon?
Given our experimentation above we might be tempted to use the error in our sum, which was about 1.19e-7f. In fact, there’s even a define in float.h with that exact value, and it’s called FLT_EPSILON.
Clearly that’s it. The header file gods have spoken and FLT_EPSILON is the one true epsilon!
Except that that is rubbish. For numbers between 1.0 and 2.0 FLT_EPSILON represents the difference between adjacent floats. For numbers smaller than 1.0 an epsilon of FLT_EPSILON quickly becomes too large, and with small enough numbers FLT_EPSILON may be bigger than the numbers you are comparing!

Dawson goes over quite a few other considerations about the intricacies involved when comparing floats and dealing with very small values like this, so I would encourage your reading the rest of his post.

To directly answer your question, you want to use the term epsilon. More accurately, it's machine epsilon but common usage drops "machine" and just uses epsilon.

Looking in my local copy of float.h I see:

#define DBL_EPSILON     2.2204460492503131e-016 /* smallest such that 1.0+DBL_EPSILON != 1.0 */  
#define FLT_EPSILON     1.192092896e-07F        /* smallest such that 1.0+FLT_EPSILON != 1.0 */  
#define LDBL_EPSILON    DBL_EPSILON             /* smallest such that 1.0+LDBL_EPSILON != 1.0 */

And the associated comments makes it clear that epsilon is the term you're referring to.

But we can also rely upon some other, external references to verify that epsilon is the correct term. See here, here, here, and finally this combination of SO query tags. I wasn't able to find a direct reference to the IEEE 754 standard to quote.


You didn't ask, but I found this reference that is very relevant to the example you provided to clarify your question.

Have a look at this blog article by Bruce Dawson of Valve on comparing floating point values for some insight as to why you don't want to use the comparison that you suggested.

There's quite a bit of information packed into that article, but this is the most relevant snipppet from there:

If comparing floats for equality is a bad idea then how about checking whether their difference is within some error bounds or epsilon value, like this:

bool isEqual = fabs(f1 – f2) <= epsilon;

With this calculation we can express the concept of two floats being close enough that we want to consider them to be equal. But what value should we use for epsilon?
Given our experimentation above we might be tempted to use the error in our sum, which was about 1.19e-7f. In fact, there’s even a define in float.h with that exact value, and it’s called FLT_EPSILON.
Clearly that’s it. The header file gods have spoken and FLT_EPSILON is the one true epsilon!
Except that that is rubbish. For numbers between 1.0 and 2.0 FLT_EPSILON represents the difference between adjacent floats. For numbers smaller than 1.0 an epsilon of FLT_EPSILON quickly becomes too large, and with small enough numbers FLT_EPSILON may be bigger than the numbers you are comparing!

Dawson goes over quite a few other considerations about the intricacies involved when comparing floats and dealing with very small values like this, so I would encourage your reading the rest of his post.

2 clarified question and additional information
source | link

YouTo directly answer your question, you want to use the term epsilon. More accurately, it's machine epsilon but common usage drops "machine" and just uses epsilon.

Looking in my local copy of float.h I see:

#define DBL_EPSILON     2.2204460492503131e-016 /* smallest such that 1.0+DBL_EPSILON != 1.0 */  
#define FLT_EPSILON     1.192092896e-07F        /* smallest such that 1.0+FLT_EPSILON != 1.0 */  
#define LDBL_EPSILON    DBL_EPSILON             /* smallest such that 1.0+LDBL_EPSILON != 1.0 */

And the associated comments makes it clear that epsilon is the term you're referring to.

But we can also rely upon some other, external references to verify that epsilon is the correct term. See here, here, here, and finally this combination of SO query tags. I wasn't able to find a direct reference to the IEEE 754 standard to quote.


And withYou didn't ask, but I found this reference that having been said:is very relevant to the example you provided to clarify your question.

Have a look at this blog article by Bruce Dawson of Valve on comparing floating point values for some insight as to why you don't want to use the comparison that you suggested.

There's quite a bit of information packed into that article, but this is the most relevant snipppet from there:

If comparing floats for equality is a bad idea then how about checking whether their difference is within some error bounds or epsilon value, like this:

bool isEqual = fabs(f1 – f2) <= epsilon;

With this calculation we can express the concept of two floats being close enough that we want to consider them to be equal. But what value should we use for epsilon?
Given our experimentation above we might be tempted to use the error in our sum, which was about 1.19e-7f. In fact, there’s even a define in float.h with that exact value, and it’s called FLT_EPSILON.
Clearly that’s it. The header file gods have spoken and FLT_EPSILON is the one true epsilon!
Except that that is rubbish. For numbers between 1.0 and 2.0 FLT_EPSILON represents the difference between adjacent floats. For numbers smaller than 1.0 an epsilon of FLT_EPSILON quickly becomes too large, and with small enough numbers FLT_EPSILON may be bigger than the numbers you are comparing!

Dawson goes over quite a few other considerations, about the intricacies involved when comparing floats and dealing with very small values like this, so I would encourage your reading the rest of his post.

You want to use the term epsilon.

Looking in my local copy of float.h I see:

#define DBL_EPSILON     2.2204460492503131e-016 /* smallest such that 1.0+DBL_EPSILON != 1.0 */  
#define FLT_EPSILON     1.192092896e-07F        /* smallest such that 1.0+FLT_EPSILON != 1.0 */  
#define LDBL_EPSILON    DBL_EPSILON             /* smallest such that 1.0+LDBL_EPSILON != 1.0 */

And the associated comments makes it clear that epsilon is the term you're referring to.

But we can also rely upon some other, external references to verify that epsilon is the correct term. See here, here, here, and finally this combination of SO query tags. I wasn't able to find a direct reference to the IEEE 754 standard to quote.


And with that having been said:

Have a look at this blog article by Bruce Dawson of Valve on comparing floating point values for some insight as to why you don't want to use the comparison that you suggested.

There's quite a bit of information packed into that article, but this is the most relevant snipppet from there:

If comparing floats for equality is a bad idea then how about checking whether their difference is within some error bounds or epsilon value, like this:

bool isEqual = fabs(f1 – f2) <= epsilon;

With this calculation we can express the concept of two floats being close enough that we want to consider them to be equal. But what value should we use for epsilon?
Given our experimentation above we might be tempted to use the error in our sum, which was about 1.19e-7f. In fact, there’s even a define in float.h with that exact value, and it’s called FLT_EPSILON.
Clearly that’s it. The header file gods have spoken and FLT_EPSILON is the one true epsilon!
Except that that is rubbish. For numbers between 1.0 and 2.0 FLT_EPSILON represents the difference between adjacent floats. For numbers smaller than 1.0 an epsilon of FLT_EPSILON quickly becomes too large, and with small enough numbers FLT_EPSILON may be bigger than the numbers you are comparing!

Dawson goes over quite a few other considerations, and I would encourage your reading his post.

To directly answer your question, you want to use the term epsilon. More accurately, it's machine epsilon but common usage drops "machine" and just uses epsilon.

Looking in my local copy of float.h I see:

#define DBL_EPSILON     2.2204460492503131e-016 /* smallest such that 1.0+DBL_EPSILON != 1.0 */  
#define FLT_EPSILON     1.192092896e-07F        /* smallest such that 1.0+FLT_EPSILON != 1.0 */  
#define LDBL_EPSILON    DBL_EPSILON             /* smallest such that 1.0+LDBL_EPSILON != 1.0 */

And the associated comments makes it clear that epsilon is the term you're referring to.

But we can also rely upon some other, external references to verify that epsilon is the correct term. See here, here, here, and finally this combination of SO query tags. I wasn't able to find a direct reference to the IEEE 754 standard to quote.


You didn't ask, but I found this reference that is very relevant to the example you provided to clarify your question.

Have a look at this blog article by Bruce Dawson of Valve on comparing floating point values for some insight as to why you don't want to use the comparison that you suggested.

There's quite a bit of information packed into that article, but this is the most relevant snipppet from there:

If comparing floats for equality is a bad idea then how about checking whether their difference is within some error bounds or epsilon value, like this:

bool isEqual = fabs(f1 – f2) <= epsilon;

With this calculation we can express the concept of two floats being close enough that we want to consider them to be equal. But what value should we use for epsilon?
Given our experimentation above we might be tempted to use the error in our sum, which was about 1.19e-7f. In fact, there’s even a define in float.h with that exact value, and it’s called FLT_EPSILON.
Clearly that’s it. The header file gods have spoken and FLT_EPSILON is the one true epsilon!
Except that that is rubbish. For numbers between 1.0 and 2.0 FLT_EPSILON represents the difference between adjacent floats. For numbers smaller than 1.0 an epsilon of FLT_EPSILON quickly becomes too large, and with small enough numbers FLT_EPSILON may be bigger than the numbers you are comparing!

Dawson goes over quite a few other considerations about the intricacies involved when comparing floats and dealing with very small values like this, so I would encourage your reading the rest of his post.

1
source | link

You want to use the term epsilon.

Looking in my local copy of float.h I see:

#define DBL_EPSILON     2.2204460492503131e-016 /* smallest such that 1.0+DBL_EPSILON != 1.0 */  
#define FLT_EPSILON     1.192092896e-07F        /* smallest such that 1.0+FLT_EPSILON != 1.0 */  
#define LDBL_EPSILON    DBL_EPSILON             /* smallest such that 1.0+LDBL_EPSILON != 1.0 */

And the associated comments makes it clear that epsilon is the term you're referring to.

But we can also rely upon some other, external references to verify that epsilon is the correct term. See here, here, here, and finally this combination of SO query tags. I wasn't able to find a direct reference to the IEEE 754 standard to quote.


And with that having been said:

Have a look at this blog article by Bruce Dawson of Valve on comparing floating point values for some insight as to why you don't want to use the comparison that you suggested.

There's quite a bit of information packed into that article, but this is the most relevant snipppet from there:

If comparing floats for equality is a bad idea then how about checking whether their difference is within some error bounds or epsilon value, like this:

bool isEqual = fabs(f1 – f2) <= epsilon;

With this calculation we can express the concept of two floats being close enough that we want to consider them to be equal. But what value should we use for epsilon?
Given our experimentation above we might be tempted to use the error in our sum, which was about 1.19e-7f. In fact, there’s even a define in float.h with that exact value, and it’s called FLT_EPSILON.
Clearly that’s it. The header file gods have spoken and FLT_EPSILON is the one true epsilon!
Except that that is rubbish. For numbers between 1.0 and 2.0 FLT_EPSILON represents the difference between adjacent floats. For numbers smaller than 1.0 an epsilon of FLT_EPSILON quickly becomes too large, and with small enough numbers FLT_EPSILON may be bigger than the numbers you are comparing!

Dawson goes over quite a few other considerations, and I would encourage your reading his post.