# Why is std::atan2 returning -0.0?

Really? Negative zero?!

double Vector2D::GetFacingAngle(const Vector2D& target, const Vector2D& source) {
a2de::Vector2D facingVec(Vector2D(source) - Vector2D(target));

//Negating 'y' argument to account for flipped nature of 'y' screen coordinates.
double result = std::atan2(-facingVec.GetY(), facingVec.GetX());

//Which causes -0.0 as a possible result when source is right of target at the same 'y' coordinate.
if(a2de::Math::IsEqual(result, -0.0)) return 0.0;
return result;
}


Is this a common behavior? (Similar to subtracting 'y' coordinates for 'up' movement in screen coordinates contrary to Cartesian coordinates.)

• BTW, you shouldn't need to care whether it comes out negative zero or positive zero. Any further floating point math you do on the result should work correctly anyway. – Nathan Reed Aug 7 '12 at 0:12
• It doesn't matter at all, because -0.0 == 0.0 according to IEEE 754 – Maik Semder Aug 7 '12 at 11:44
• @MaikSemder From an aesthetic standpoint it does (like...displaying the angle to the screen) – Casey Aug 7 '12 at 12:32
• @Casey I see, no reason to touch the math code though. The math code works fine. This is a GUI problem. Make the values user friendly in the UI code before you show it on screen, rather than polluting the basic math code with unnecessary comparisons. – Maik Semder Aug 7 '12 at 12:42

The link contains some notes on behavior and handling of the occurrence, although beyond that it's not entirely clear to me what you're asking, specifically -- it's not a bug with atan2 though. In fact, the wiki article on the function notes that the relevant Intel assembly instruction (FPATAN), which you're likely generating here, will produce a negative zero when first parameter in negative zero but the second is positive zero. Your explicit negation of your vector's Y component could easily produce such a scenario.