Returns a value indicating whether this instance and a specified float object represent the same value.
true if obj is equal to this instance; otherwise, false.
This method implements the IEquatable`1 interface, and performs slightly better than float.Equals(object) because it does not have to convert the obj parameter to an object.
Depending on your programming language, it might be possible to code an float.Equals(float) method where the parameter type has fewer bits (is narrower) than the instance type. This is possible because some programming languages perform an implicit widening conversion that represents the parameter as a type with as many bits as the instance.
For example, suppose the instance type is float and the parameter type is int. The Microsoft C# compiler generates instructions to represent the value of the parameter as a float object, and then generates a float.Equals(float) method that compares the values of the instance and the widened representation of the parameter.
Consult your programming language's documentation to determine if its compiler performs implicit widening conversions of numeric types. For more information, see the Type Conversion Tables topic.
The float.Equals(float) method should be used with caution, because two apparently equivalent values can be unequal because of the differing precision of the two values. The following example reports that the float value .3333 and the float returned by dividing 1 by 3 are unequal.
code reference: System.Single.Epsilon#1
One comparison technique that avoids the problems associated with comparing for equality involves defining an acceptable margin of difference between two values (such as .01% of one of the values). If the absolute value of the difference between the two values is less than or equal to that margin, the difference is likely to be an outcome of differences in precision and, therefore, the values are likely to be equal. The following example uses this technique to compare .33333 and 1/3, which are the two float values that the previous code example found to be unequal.
code reference: System.Single.Epsilon#2
In this case, the values are equal.
Because float.Epsilon defines the minimum expression of a positive value whose range is near zero, the margin of difference must be greater than float.Epsilon. Typically, it is many times greater than float.Epsilon. Because of this, we recommend that you do not use double.Epsilon when comparing double values for equality.
A second technique that avoids the problems associated with comparing for equality involves comparing the difference between two floating-point numbers with some absolute value. If the difference is less than or equal to that absolute value, the numbers are equal. If it is greater, the numbers are not equal. One way to do this is to arbitrarily select an absolute value. However, this is problematic, because an acceptable margin of difference depends on the magnitude of the float values. A second way takes advantage of a design feature of the floating-point format: The difference between the mantissa components in the integer representations of two floating-point values indicates the number of possible floating-point values that separates the two values. For example, the difference between 0.0 and float.Epsilon is 1, because float.Epsilon is the smallest representable value when working with a float whose value is zero. The following example uses this technique to compare .33333 and 1/3, which are the two double values that the previous code example with the float.Equals(float) method found to be unequal. Note that the example uses the BitConverter.GetBytes(float) and BitConverter.ToInt32(Byte[], int) methods to convert a single-precision floating-point value to its integer representation.
code reference: System.Single.Equals#1
The precision of floating-point numbers beyond the documented precision is specific to the implementation and version of the .NET Framework. Consequently, a comparison of two numbers might produce different results depending on the version of the .NET Framework, because the precision of the numbers' internal representation might change.