Equality of floating point numbers
-
Okay, I think that I understand the issues affecting C# equality testing (including numerical precision, type conversions, boxing etc) - e.g. http://blogs.msdn.com/jmstall/archive/2005/03/09/390135.aspx[^] - but I don't understand the statement in MSDN (http://msdn.microsoft.com/en-gb/library/bsc2ak47.aspx[^]):
x.Equals(x) returns true, except in cases that involve floating-point types. See IEC 60559:1989, Binary Floating-point Arithmetic for Microprocessor Systems.
Can anyone please explain? How can this sometimes evaluate to false? (I couldn't find anything interesting re: IEC 60559:1989 - still Googling though.) P.S.
double d = Double.NaN;
d.Equals(d); // is still true - although it doesn't have to be under the standard"...there's what people want to hear, there's what people want to believe, there's everything else, THEN there's the truth!" - New York D.A., The International
-
Okay, I think that I understand the issues affecting C# equality testing (including numerical precision, type conversions, boxing etc) - e.g. http://blogs.msdn.com/jmstall/archive/2005/03/09/390135.aspx[^] - but I don't understand the statement in MSDN (http://msdn.microsoft.com/en-gb/library/bsc2ak47.aspx[^]):
x.Equals(x) returns true, except in cases that involve floating-point types. See IEC 60559:1989, Binary Floating-point Arithmetic for Microprocessor Systems.
Can anyone please explain? How can this sometimes evaluate to false? (I couldn't find anything interesting re: IEC 60559:1989 - still Googling though.) P.S.
double d = Double.NaN;
d.Equals(d); // is still true - although it doesn't have to be under the standard"...there's what people want to hear, there's what people want to believe, there's everything else, THEN there's the truth!" - New York D.A., The International
Hi, the MSDN documentation on Object.Equals says: This method can be overridden by a derived class.... The following statements must be true for all implementations of the Equals method... x.Equals(x) returns true, except in cases that involve floating-point types. See IEC 60559:1989, Binary Floating-point Arithmetic for Microprocessor Systems. so all it says is xfloat.Equals(xfloat) is ALLOWED to return false; it just leaves the Equals() result for floats undefined. The IEC standard isn't available for free, so I can't check this, however I assume they call the result of x==x undefined, hence hardware that implements IEC 60559:1989, and software running on such hardware, would find it difficult to enforce x.Equals(x) returns true. The fundamental reason is it does not make sense at all to test two floats for equality; by their very nature, float values are either close to each other (difference less than epsilon), or they are not. Zero does not exist in nature. :)
Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
-
Hi, the MSDN documentation on Object.Equals says: This method can be overridden by a derived class.... The following statements must be true for all implementations of the Equals method... x.Equals(x) returns true, except in cases that involve floating-point types. See IEC 60559:1989, Binary Floating-point Arithmetic for Microprocessor Systems. so all it says is xfloat.Equals(xfloat) is ALLOWED to return false; it just leaves the Equals() result for floats undefined. The IEC standard isn't available for free, so I can't check this, however I assume they call the result of x==x undefined, hence hardware that implements IEC 60559:1989, and software running on such hardware, would find it difficult to enforce x.Equals(x) returns true. The fundamental reason is it does not make sense at all to test two floats for equality; by their very nature, float values are either close to each other (difference less than epsilon), or they are not. Zero does not exist in nature. :)
Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
Luc Pattyn wrote:
Zero does not exist in nature.
Shhhhhhhhhhhhhh, please don't tell it to Zero. It assumes its existance having the same dignity of 1, 2, pi and so on. :rolleyes:
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Luc Pattyn wrote:
Zero does not exist in nature.
Shhhhhhhhhhhhhh, please don't tell it to Zero. It assumes its existance having the same dignity of 1, 2, pi and so on. :rolleyes:
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Hi, the MSDN documentation on Object.Equals says: This method can be overridden by a derived class.... The following statements must be true for all implementations of the Equals method... x.Equals(x) returns true, except in cases that involve floating-point types. See IEC 60559:1989, Binary Floating-point Arithmetic for Microprocessor Systems. so all it says is xfloat.Equals(xfloat) is ALLOWED to return false; it just leaves the Equals() result for floats undefined. The IEC standard isn't available for free, so I can't check this, however I assume they call the result of x==x undefined, hence hardware that implements IEC 60559:1989, and software running on such hardware, would find it difficult to enforce x.Equals(x) returns true. The fundamental reason is it does not make sense at all to test two floats for equality; by their very nature, float values are either close to each other (difference less than epsilon), or they are not. Zero does not exist in nature. :)
Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
I think that the standard states that NaN may be treated as not being equal to NaN - which seems fair as operations resulting in NaN are NOT returning an an actual numerical value. .NET does however treat them as equal when using Equals() but not when using ==. I can't see how
x.Equals(x)can evaluate to false for real numbers (whatever the implementation) when the 2 operands are references to the same object. Do you think that MSDN is really just saying not to rely on it - even when referencing the same object? (If so it would be useful if they stated thay some other comparison should be used with reference to Epsilon.)"...there's what people want to hear, there's what people want to believe, there's everything else, THEN there's the truth!" - New York D.A., The International
-
I think that the standard states that NaN may be treated as not being equal to NaN - which seems fair as operations resulting in NaN are NOT returning an an actual numerical value. .NET does however treat them as equal when using Equals() but not when using ==. I can't see how
x.Equals(x)can evaluate to false for real numbers (whatever the implementation) when the 2 operands are references to the same object. Do you think that MSDN is really just saying not to rely on it - even when referencing the same object? (If so it would be useful if they stated thay some other comparison should be used with reference to Epsilon.)"...there's what people want to hear, there's what people want to believe, there's everything else, THEN there's the truth!" - New York D.A., The International
As I said, MSDN requires an inherited Equals to return true for x.Equals(x) unless x is of type float/double, in which case there is no such requirement at all. Your point on one NaN not being equal to another NaN is absolutely valid; anyway, x.Equals(y) is not supposed to first check if x and y refer to the same object. So if they both refer to the same float variable and that happens to be NaN, then is really should return wouldn't be wrong to return false! AFAIK the same argument applies to plus and minus infinity, one infinity does not equal another. :)
Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
modified on Sunday, June 21, 2009 2:14 PM