Meaning of Double.Epsilon

[Niki Estner]

If == isssues a warning, double.Equals() also should.

Also bare in mind that a Warning doesn't mean "It is wrong" but "It could
possibly be wrong", otherwise it would be an Error.

I think that's a misunderstanding. Here are a few warnings I've randomly
picked:
CS0028 'function declaration' has the wrong signature to be an entry point
CS0105 The using directive for 'namespace' appeared previously in this
namespace
CS0162 Unreachable code detected
CS0251 Indexing an array with a negative index (array indices always start
at zero)
CS0628 'member' : new protected member declared in sealed class
CS0649 Field 'field' is never assigned to, and will always have its default
value 'value'
CS1522 Empty switch block
CS1591 Missing XML comment for publicly visible type or member
'Type_or_Member'
CS5000 Unknown compiler option '/option'

These do suggest that a warning acually means "this code can be compiled,
but it makes no sense and will either do nothing, or crash". I don't think a
fp comparison would fit in that category.

Niki

 

[Jon Skeet [C# MVP]]

The funny thing is that if you compare a float with and int value -1 the
result returns true even if its value is not -1. The following prints
"hello":

float f1 = -1.00000001f;
float f2 = -0.99999999f;
if (f1==-1 && f2==-1)
{
Console.WriteLine("hello");
}

There's nothing funny about that - the nearest float to those literals
is exactly -1. Have a look in the IL. That explains the Ceiling/Floor
problems you were having too.

 

[cody]

That's the point I've already tried to say: I *do* use tests like "if
(a

I think this is going slightly off-topic now, but of course "special values"
like these have to be values that cannot be result of a calculation.
Depending on the meaning of the value this could be a negative value (e.g
distances), NaN, a value above 100 (percentages), or whatever. Although NaN
is a good "special value", too, it does have disadvantages, sometimes: AFAIK
Double.Parse can't parse it, converting it to an int will throw an
exception,

If you use it as special value to mean "uninitialized", you certainly won't
parse it or convert it to int.

you only have one single special value,

otherwise it wouldn't be special

and sometimes NaN can be result of a calculation...

Indeed, NaN can be result of a calculation whereas -1 can't ))

In fact, special values(besides NaN,NegativeInf,PositiveInf) in floating
point sounds a bit like an oxymoron (ok it isn't). But maybe special ranges
are ok.

 

[cody]

float f1 = -1.00000001f;

There's nothing funny about that - the nearest float to those literals
is exactly -1. Have a look in the IL. That explains the Ceiling/Floor
problems you were having too.

I'd have expected a simple truncation which would have returned true for
f1==-1 but false for f2==-1,
since -0.999999f would have been truncated to 0 which obviously wasn't the
case. And who guarantees that every platform will handle this the same way?
Even if the standard exactly dictates what should happen such edge cases are
imho always a good candidate for implementation errors.

I stick to my opinion - never trust a floating point value.

 

[Jon Skeet [C# MVP]]

I'd have expected a simple truncation which would have returned true for
f1==-1 but false for f2==-1,
since -0.999999f would have been truncated to 0 which obviously wasn't the
case.

No - both f1 and f2 are exactly -1.

And who guarantees that every platform will handle this the same way?

The C# specification states:

<quote>
The value of a real literal having type float or double is determined
by using the IEEE "round to nearest" mode.
</quote>

I have no reason to doubt that applying that to both -1.00000001 and
-0.99999999 would show that both should have a value of -1.

Even if the standard exactly dictates what should happen such edge
cases are imho always a good candidate for implementation errors.

I stick to my opinion - never trust a floating point value.

Well, only trust a floating point value if you know what's going on. My
point is that there was nothing "funny" going on in your code - it was
perfectly predictable.