Floating Point and Precision

What the types hold

Type	Bits	Mantissa	Significant decimal digits	Max
float	32	24	~7	$3.4\cdot 10^{38}$
double	64	53	~15-16	$1.8\cdot 10^{308}$
long double (x86)	80	64	~18-19	$1.2\cdot 10^{4932}$
__float128	128	113	~33	huge

long double is 80-bit on x86 Linux (Codeforces) but the same as double on MSVC — do not rely on it for correctness if the judge’s compiler is unknown.

The rules

Never compare with ==

const double EPS = 1e-9;
bool eq(double a, double b) { return fabs(a - b) < EPS; }
int sgn(double x) { return (x > EPS) - (x < -EPS); }

Choose $\epsilon$ relative to the magnitude. With values around $10^9$, a double has absolute precision about $10^{-7}$, so $\epsilon =10^{-9}$ is smaller than the noise and will misclassify. Use a relative comparison when magnitudes vary:

bool eq(double a, double b) { return fabs(a - b) <= EPS * max(1.0, max(fabs(a), fabs(b))); }

Where precision is lost

Operation	Danger
Subtracting near-equal values	catastrophic cancellation — the killer
Adding numbers of very different magnitudes	the small one vanishes
Repeated accumulation	error grows as $O(\sqrt{n})$ or $O(n)$
sqrt of a tiny negative (from cancellation)	NaN
acos of a value slightly outside $[-1,1]$	NaN
Large exponents	overflow to inf
Comparing computed values	the whole problem

The two classic rescues

Quadratic formula. $\frac{-b+\sqrt{b^2-4ac}}{2a}$ cancels when $b>0$. Use
$q=-\frac{1}{2}\left(b+\mathrm{sgn}(b)\sqrt{b^2-4ac}\right),x_1=q/a,x_2=c/q.$

Angle between vectors. acos(dot/(|a||b|)) loses precision near $0$ and $\pi$ and can feed acos an out-of-range value. Use

double ang = atan2(fabs(cross(a,b)), dot(a,b));

Avoiding floating point entirely

The best fix is not to use it:

Instead of	Use
sqrt(d1) < sqrt(d2)	d1 < d2 (squared distances)
a/b < c/d	a*d < c*b (watch signs and overflow)
Slope comparison	cross product
x == y for rationals	store pair<num, den> reduced by the gcd
Percentages	scale to integers
Angles	cross and dot products
pow(a, b) for integers	fast exponentiation with long long
log2(n)	__lg(n) or 31 - __builtin_clz(n)

Rule: do every decision in exact arithmetic; use floating point only for the final output.

Summation accuracy

Naive summation of $n$ values accumulates $O(n\epsilon )$ error. Two fixes:

Kahan summation — track the lost low-order bits:

double sum = 0, c = 0;
for (double x : v) {
    double y = x - c, t = sum + y;
    c = (t - sum) - y;
    sum = t;
}

Pairwise summation — sum recursively in halves; error drops to $O(\epsilon \log n)$ and it is what std::accumulate on a sorted range effectively achieves. Simply sorting by magnitude before summing captures most of the benefit.

Output

printf("%.10f\n", x);
cout << fixed << setprecision(10) << x << "\n";

Read the statement for the required precision — usually $10^{-6}$ or $10^{-9}$ relative or absolute. Printing more digits than the computation supports is harmless; printing fewer is not.

Watch for negative zero: -0.000000 may be rejected by a strict checker. Add 0.0 or clamp tiny magnitudes to 0 before printing.

Special values

isnan(x)      // NaN != NaN, always
isinf(x)
0.0 / 0.0     // NaN
1.0 / 0.0     // inf

NaN propagates silently through arithmetic and makes every comparison false — which turns a sort with a NaN in the data into undefined behaviour. Guard sqrt and acos arguments.

Compiler flags to avoid

-ffast-math (implied by -Ofast) permits the compiler to reorder floating-point operations and assume no NaN/inf. It can change results and break isnan checks. Do not use it when precision matters.

See also: Geometry Basics · Exact Rational Arithmetic · Common Pitfalls