Where triangle solving comes from — and where it still matters
Solving triangles is one of the oldest computational problems in mathematics. Hipparchus of Nicaea (~150 BCE) is generally credited as the first to compile chord tables — the ancient predecessor of the sine table — specifically so astronomers could solve triangles formed by Earth, the Sun, and stars. Three centuries later Ptolemy's Almagest extended those tables and made systematic triangle solving the workhorse of Greek astronomy. The Law of Cosines in its modern form was first written down by the Persian mathematician al-Kāshī in the 15th century; the Law of Sines appears in 13th-century work by Nasir al-Din al-Tusi. The formulas this calculator runs are roughly 700 years old.
They are still load-bearing today in surprising places. Land surveying still uses chained triangulation networks to extend a known baseline into a continental-scale coordinate grid — the entire US Public Land Survey is built on this principle. Structural engineers analyze roof and bridge trusses by repeatedly solving the triangles each gusset plate joins. Astronomers measure distances to nearby stars by stellar parallax: a very thin triangle whose tiny apex angle is the parallax (often less than 0.001″ of arc) and whose base is the Earth's orbital diameter (~300 million km). And GPS, while it works on a sphere rather than a plane, uses the spherical analog of the same formulas.
When the arithmetic gets touchy
The formulas are exact, but the inputs you give a calculator never are. Three input patterns hit numerical edges hard enough to be worth knowing about:
Near-degenerate triangles — when one side is almost as long as the sum of the other two (say a = 5, b = 7, c = 11.999), the term (a² + b² − c²) / (2ab) inside arccos approaches −1, and floating-point rounding can push it just past −1, returning NaN or the wrong branch. The solver checks the triangle inequality (each side strictly less than the sum of the other two) with a small tolerance before computing; sliver triangles that pass the check still lose accuracy in their angles because arccos is steep near ±1.
Very thin triangles — when one angle is below about 1°, sin of that angle is tiny, so the Law of Sines divides by something close to zero. Two-digit input precision can produce a four-digit-error output. If you genuinely need accurate angles for a triangle one of whose angles is fractions of a degree, work with the side ratios directly instead of going through arcsine.
The SSA boundary — when b·sin(A)/a equals 1 exactly, there is one right-triangle solution; when it's just below 1 (say 0.99999), there are two valid triangles that differ by tens of degrees. Whether your real-world data lands above or below 1 depends on the last decimal place of your measurement, which is essentially random. Always verify SSA results by feeding the returned angles back into the Law of Sines and checking the third side matches.
Questions the basic FAQ doesn't cover
How is the Law of Cosines related to the Pythagorean theorem?
It's the Pythagorean theorem with an extra correction term for non-right triangles. Set C = 90° in c² = a² + b² − 2ab·cos(C): because cos(90°) = 0, the formula collapses to c² = a² + b². The −2ab·cos(C) term measures exactly how much the relationship deviates from the right-angle case. For an acute C, the term is negative so c² < a² + b²; for obtuse C, positive so c² > a² + b².
What's the connection to vectors and the dot product?
If sides a and b are vectors emanating from the same vertex, then side c is the vector a − b. Computing |a − b|² via the dot product gives |a|² + |b|² − 2(a·b), and since a·b = |a||b|cos(C), this is exactly the Law of Cosines. So the law isn't a separate theorem from vector geometry — it's the same statement in different notation. Anyone comfortable with the dot product already knows the Law of Cosines.
Can this solver handle a triangle on the surface of a sphere?
No. This tool assumes a flat (Euclidean) plane. Spherical triangles — used in navigation, astronomy, and large-scale geodesy — obey different relationships: the spherical Law of Cosines is cos(a) = cos(b)·cos(c) + sin(b)·sin(c)·cos(A) where a, b, c are arc lengths in radians, not linear distances. The angles of a spherical triangle also sum to more than 180° (the excess is proportional to the triangle's area). For a triangle whose sides are short compared to the sphere's radius — say, a city-block-sized survey — the planar formulas are accurate to within rounding error.
Why do my hand-computed angles sum to 179.99° instead of exactly 180°?
Floating-point rounding in arccos. Each angle the solver returns is accurate to roughly 13 decimal digits in radians but typically displayed to 4 decimal places in degrees, so each truncation throws away a tiny amount. Three truncations don't always sum back to a clean 180. As a rule of thumb: a sum within 0.01° of 180° is rounding noise; a sum off by more than 0.1° usually means inconsistent input data — for example, an SSS triangle whose sides don't quite satisfy the triangle inequality, or an ASA case where the third angle was computed first.