The value reported by float.Epsilon isn't actually Epsilon.
According to documentation (and confirmed by experiment), Single.Epsilon has a value of 1.4E-45, which is the (as the documentation states) "the smallest positive Single greater than zero.".
Compare that to C where
float.h:
#define FLT_EPSILON 1.192092896e-07F /* smallest such that 1.0+FLT_EPSILON != 1.0 */
and C++, where std::numeric_limits<float>::epsilon() is "the difference between 1 and the smallest value greater than 1 that is representable for the data type".
<grumpy off topic aside> epsilon has special meaning within the ANSI/IEEE 754 standard for floating point arthmetic. The C# convention varies sharply from common usage and standard convention. And non-conformance with ANSI/IEEE 754 is not a small issue for a modern computer language. This is basic numeric analysis 101 stuff, and a mistake like this is pretty inexcusable. It makes me gravely concerned about the validity of the rest of the floating point implementation in .net. The C++ version of epsilon is intensely useful, but I can't honestly thing of a single use for the CLR version of epsilon. And the stated intended usage in the documentation for Single.Epsilon is just plain wrong. Single.Epsilon, as currently defined absolutely cannot be used for any reasonable version of soft floating point comparison.</grumpy off topic aside>.
So. Back to the real question. Is there a standard place in CLR where I can get the real machine epsilon (defined as the smallest float for which 1.0f+epsilon != 1.0f) for float?
<more grumpy off-topic aside> It's actually interesting how difficult it is to calculate FLOAT_EPSILON at runtime due to the oddities of Single and Double float operations on x86. I really don't like hard-coding this value.</more grumpy off-topic aside>