What is the difference between Math and StrictMath, and when would you prefer one over the other?

## Two classes, same API Java ships two classes with the *same* set of static math functions: `java.lang.Math` and `java.lang.StrictMath`. `Math.sin`, `Math.pow`, `Math.log` and friends all have an identical counterpart in `StrictMath`. The difference is not *what* they compute but *how precisely and how reproducibly* they compute it. ## Why floating-point results can differ at all Transcendental functions like sine or logarithm cannot be computed exactly with a finite number of operations — they're approximated by algorithms. Different CPUs and math libraries use slightly different approximation routines, so the **last bit** of a `double` result can vary from one machine to another. A `double` has ~15-17 significant decimal digits; the disagreement is typically in that very last digit, but for code that compares results exactly, even one bit matters. The size of such an error is measured in **ulps** — *units in the last place*, i.e. the gap between two adjacent representable `double` values. "Within 1 ulp" means the result is at most one such step away from the true value. ## `StrictMath` — bit-for-bit reproducible `StrictMath` is the **strict** version: its functions are *specified* to produce **exactly the same bits on every platform**, every JVM, every OS, every CPU. To achieve this it pins the algorithms to a well-known reference implementation called **fdlibm** (Freely Distributable Math Library). Run `StrictMath.sin(1.0)` on a laptop, a server, and a phone and you get the identical 64-bit pattern. The cost is that it can't use the fastest hardware path — it must follow the prescribed algorithm. ## `Math` — platform-optimized, within a tolerance `Math` makes a **weaker, performance-oriented** guarantee. The spec says its results must be: - **accurate to within a documented error bound** (for most methods, within 1 ulp, some within 2), and - **semi-monotonic** (if the true function is monotonic over an interval, the approximation doesn't reverse direction). Within those bounds the JVM is free to substitute **intrinsics**: special hardware instructions or optimized native routines that the JIT compiler swaps in for speed. Because that path is platform-dependent, two different machines may return results that differ in the last ulp. Many `Math` methods *delegate to `StrictMath`* in the JDK source today — but that is an implementation detail you must **not** depend on; the contract only promises the error bound. ## How to choose **Default to `Math`.** It's at least as fast and usually faster, and for the vast majority of code a last-bit difference is irrelevant. **Choose `StrictMath` when exact reproducibility is part of correctness:** - **Deterministic simulations / games** that must replay identically from the same seed across machines. - **Distributed systems** where nodes compute floating-point values and then compare or hash them — any disagreement breaks consensus. - **Cross-platform test oracles** that assert exact expected `double` outputs. - **Regulatory or scientific** computations requiring documented, portable results. ## Historical note: `strictfp` There used to be a related keyword, `strictfp`, that forced strict IEEE-754 intermediate evaluation on expressions. As of Java 17 all floating-point arithmetic is strict by default and `strictfp` is effectively a no-op, but the `Math` vs `StrictMath` distinction for the *library functions* still stands and is the relevant one today. ## One-line summary Same functions; `StrictMath` = identical bits everywhere (reproducible, possibly slower), `Math` = within a small error bound and free to be faster (possibly differs by an ulp between platforms).