# Talk:Haversine formula

Page contents not supported in other languages.

## haversine formula two definitions

As structured at present, the haversine formula is confusingly defined in terms of itself for the central angle. At first glance and likely to less trig aware people, the formula seems overloaded, meaning different things depending on what argument is fed in.

I suggest reordering the article so that the definition of the haversine of an angle is given before the haversine formula for the central angle written in terms of latitude and longitude. is given by instead of in terms of latitudes and longitudes becomes contributes to the confusion. The use of 'formula' versus 'function' also needs clarified. To recap, is the article trying to say:

The haversine function of an angle, given below:

${\displaystyle \operatorname {hav} (\theta )=\sin ^{2}\left({\frac {\theta }{2}}\right)={\frac {1-\cos(\theta )}{2}}}$

And can be transformed to be in terms of latitude and longitude instead of the central angle Θ, as shown below:

${\displaystyle \operatorname {hav} \left(\Theta \right)=\operatorname {hav} (\varphi _{2}-\varphi _{1})+\cos(\varphi _{1})\cos(\varphi _{2})\operatorname {hav} (\lambda _{2}-\lambda _{1})}$

The term 'haversine formula' as commonly used is then actually the inverse of this solved for 'd' from the equation for the great angle, theta.

Currently there appear to be two different definition of haversine formula:

1. The haversine formula hav of Θ is given by:

2. The haversine formula determines the great-circle distance between two points on a sphere given their longitudes and latitudes.

Which is it? It's confusing right now but I think the haversine formula commonly refers to the inverse haversine of the great angle written in terms of lattitude and longidue solved for d?

I don't want to go crazy and make all these changes without a second opinion, so if you agree with me please enact them.

## Cos or sin in the first formula?

I undid the change from cos to sin. Cos is correct when the formula is expressed in terms of latitude.

NB in the general haversine formula given below under "law of haversines" for a spherical triangle sin is indeed correct. The point is simply that latitude is measured from the equator not the pole, so sin of the great-circle distance from the pole becomes cos(latitude). — Preceding unsigned comment added by Dgwsoft (talkcontribs) 11:51, 14 September 2011 (UTC)

This point is in fact explained under "law of haversines". I just want to make it clear why it should not be changed back. Dgwsoft (talk) 14:13, 14 September 2011 (UTC)

It can be expressed in terms of both sin and dos, and in practice it has to be computed with sin, as cos doesn't have enough precision for small angles. Esmond.pitt (talk) 12:18, 13 July 2022 (UTC)

Err, both sin and cos, Esmond.pitt (talk) 12:18, 13 July 2022 (UTC)

## Why not give the simplification or link to it?

Just give the square box approximation formula as an alternative since many of the uses of haversine are to answer the 'show all locations with X miles of latitude/longititude Y'. The square implementation is just a table lookup based on longititude to set the size of the square (i.e., the number of degrees in the box width and height based on latitude).

## Why atan2?

In the formula for d, you can use either arcsin or arctangent:

d = 2 R asin(√h) = 2 R atan2(√h, √(1−h))

The Census Bureau FAQ recommends using the atan2 function instead of the asin function, but I have to confess that I can't see why.

The stated explanation is that the asin function requires "bulletproofing" in order to check that √h doesn't exceed unity, while "no bulletproofing is needed for an inverse tangent", but this makes no sense to me: in the atan2 version, you still need to check that h doesn't exceed 1 or or the square root will fail.

(On the other hand, if your trig and square root functions operate on complex numbers, neither case will fail—you'll just get a small imaginary part, which you can ignore, if h slightly exceeds 1.)

Moreover, I just did a numerical check using the GNU C library math functions (which are usually pretty good) in double precision (~16 decimal places) on a Pentium (IV), comparing to an arbitrary-precision (50-decimal places) calculation, and both the asin and atan versions are equally (in)accurate. For h = 1-1e-13, both versions give an error of about 3.16e-7 compared to the correct result of 1.5707963267948966192313216916397514420985846996876 for d/2R.

So, I'm going to delete the recommendation to use arctangent, as a bit of "folk numerical analysis" that maybe was true for somebody's pocket calculator years ago but doesn't seem to have any relation to reality now. Please, feel free to correct me if I'm missing something.

—Steven G. Johnson 03:43, Apr 12, 2004 (UTC)

ATAN2 does not suffer from problems when the arc crosses the pole . The tangent function is discontinuous because it is defined as t = o/a. ATAN2 takes o and a as parameters and computes a result in such a way that the problematic division is never performed, incidentally mitigating floating point errors too. Consider yourself corrected. That said, haversine is a stone-age approximation for people who don't have computers and should never be used for anything that requires high precision over large distance. Yes ships use it to navigate but they make constant corrections and the close they get the smaller the absolute error.

—Peter Wone 11:02, May 5, 2011 (UTC) —Preceding unsigned comment added by Styphnate (talkcontribs)

I can't see what you're saying. Can you give a specific example? --208.80.119.67 (talk) 01:04, 3 December 2011 (UTC)
Styphnate, it sounds like you are describing the advantages of atan2 vs. atan. Here, it is being used instead of asin, which has no division by zero. (Actually, computers with IEEE arithmetic can divide by zero just fine and get ±∞. The advantage of atan2 over atan is more that atan2 has an expanded range, from −π to π. However, that isn't relevant here since the arguments are always positive.)
Regarding the "stone age" nature of this formula, you should pause to consider the fact that spheres are used for other things in mathematics besides approximating planets. — Steven G. Johnson (talk) 21:17, 3 December 2011 (UTC)

## What's the formula?

In one part of the article it is claimed that:

haversin(θ) = sin2(θ / 2)

While later on the article says:

the use of detailed printed haversine charts saved navigators from squaring sines and halving the result

which would imply that:

haversin(θ) = sin2(θ) / 2

So do you square an angle's sine and then halve the result, or halve the angle and then square its sine? --Delirium 08:51, Apr 12, 2004 (UTC)

The first formula is correct (see also the versine article for the etymology...the haversine is half the versine). I didn't write that sentence in the article, so I can only speculate that the author of that sentence meant the halving of the argument, not the result, or perhaps the doubling of the result. I've modified the article to clarify. —Steven G. Johnson 17:46, Apr 12, 2004 (UTC)
Apologies; that was truly idiotic of me. I also was the originator of the whole "haversin(d/R) = h, where h=etc." wording, which I see has been changed. I don't blame you; it was cumbersome. But I thought the replacement was rather confusing; so I've proposed yet another version. I know "right-hand-side" sounds amateurish: but I really think the goal should be to be as intelligible to all readers, even at the cost of amateurishness. Doops 05:31, 14 Apr 2004 (UTC) P.S. I also see that my 'rammify' has been altered, which I kinda expected because it's old-fashioned and eccentric: but it really is a perfectly sensible use of the word. Look it up. :)
I assume you mean 'ramify'. I'm familiar with the word, and ramify small errors would be appropriate to describe the errors branching into many different computations, but is not really the right connotation for magnifying them in a single computation. —Steven G. Johnson

## Why solve for d?

OK, I've got a question: why solve for d at all? In order to calculate the distance directly by the equation given, you will have to take the square root of a number which is likely to be near one; then caculate the arcsine of that. Wouldn't it be much, much easier to have, along with your detailed, printed table of haversines, a detailed, printed table of archaversines? Doops 05:39, 14 Apr 2004 (UTC)

Of course. A detailed printed table for the haversine is a detailed printed table for the inverse haversine...you just look up in the other column. As the article says, this saved navigators from squaring sines, computing square roots, etc. —Steven G. Johnson 05:56, Apr 14, 2004 (UTC)
>As the article says, this saved navigators from squaring sines, computing square roots, etc.
Exactly! It was that phrase of yours which led me to ask the question! :) Doops 06:14, 14 Apr 2004 (UTC)

## RHS vs. LHS

I'm sorry to keep bringing this up; but I am really not happy with the language Let h denote haversin(d/R), given from above. &c. &c.

Since I'm obviously not the expert here, and since I don't want to be annoying, I'm not going to change it back again; but I really have to say that this phrasing seems counterintuitive to me. Although doubtless its a perfectly defensible statement mathematically, it does seem to be saying, in effect, "let h = the LHS" when what we want to say is "let h = the RHS". Now obviously RHS = LHS, so this perhaps shouldn't matter; but I'm worried that somebody might plug h=haversin(d/R) into the formulae on the next line, getting the perfectly pointless result d=dR/R.

It's not at all circular, since LHS = RHS. Because the equation relating the two was one line before the defnition of h, I find it hard to believe that the reader would not realize that they have to use the RHS to apply the equation. —Steven G. Johnson
Yes; but why? I'm sure people can figure it out; perhaps the con- argument is no big deal; but what's the pro- argument? I simply don't see the point in doing things in a non-intuitive way.
The subtly-weird statement, to me, is to explicitly define h as one "side" or the other of an equation where both sides are equal—h is just a number, not a symbolic expression. Given that number, and knowing the relevant relation h = haversin(d/R), you then want to find d. This is algebra, not a computer programming language; "=" is equality, not assignment. —Steven G. Johnson 00:03, Apr 15, 2004 (UTC)
Gosh, I have so many comments I don't know where to begin!
• first of all, Stevenj, you haven't answered my question: what is the argument in favor of the current version?
• secondly, perhaps you're right that explicitly defining h as the RHS is weird. But I think (see below) that the text as it stands right now implicitly "defines" "h" as the LHS.
• right now, the text reads "let h denote sin2(θ/2)." "Denote" seems pretty much like assignment to me! That is to say, when I hear the word 'denote,' I imagine a little label pointing at the expression with the letter h written on it. Not a mathematical definition, but a mental one.
• And there is a very real difference between the two sides of the equation here: the RHS (as you point out above) is simply a number, which we can calculate based on observable data; but the LHS isn't! Or at least we don't think of it that way — if we thought of it that way, then we'd have a useless tautology!
• But I guess we could treat both sides as 'just a number'; I guess we could go whole hog and, after giving the equation, begin the paragraph by saying: "Call this quantity h. By solving the eqation above we can find the distance d in terms of h and R (the known radius of the earth), etc. etc." We'd refer to the equation as a value, then proceed in the next line to manipulate it again like an active equation; but at least this would make the definition of h RHS/LHS-neutral.
Anyway, sorry for worrying at this so much. I'm not trying to be obnoxious! I just really believe in making things as straightforward as possible. Doops 03:14, 15 Apr 2004 (UTC)

The only reason (correct me if I'm wrong) for using h at all is to make the formula less messy-looking; if we were willing to have a long, confusing formula we could just write (for the 3rd large-font equation) d=R archaversin (haversin Δ&phi etc. etc.) And perhaps we should just go with that! But if we really do want to use h for the sake of simplicity, I think things will simply be much more simple if we get people thinking of h as another name for the RHS. The present language may mean that to some people; but not, I think, to all.

(Also, regarding the second version of the solved-for-d equation: don't you think we should make more explicit how it was derived? I think the mention (now deleted) that the def'n of haversine was applied before the arcsine taken was useful. Isn't it better to show than to tell?)

At a certain point, adding verbiage to belabor the obvious makes things less clear. —Steven G. Johnson 19:45, Apr 14, 2004 (UTC)
That's certainly true (see my new comment below). Doops 03:14, 15 Apr 2004 (UTC)

Again, I'm not an expert: which means (on the one hand) that I should be humble in altering the article; but on the other, that I might have useful suggestions regarding how it will sound to the layman. Doops 18:35, 14 Apr 2004 (UTC)

## Possible rearrangement

Hi. I've put up a possible rearrangement of the whole article at Talk:Haversine_formula/Alt

Some points about it:

• The main goal was to arrange the article so that the novice outsider, upon clicking to it, could get a quick summary of the haversine formula as quickly and painlessly as possible.
• All discussions about the technical aspects and rationale are moved to the second section, the first paragraph of which is intended for the general reader. The rest of the section (which I haven't presumed to write) would be more technical in nature, and could perhaps be in smaller type to make this distinction clear.
• I've left the remainder of the article unchanged.

Comments? If you like this ordering, please work on that second section (beyond the first paragraph) so that there's a logical progression! Thanks— Doops 03:14, 15 Apr 2004 (UTC)

## Suggestion to add the precise formula for the earth

The article states, that haversine is not 100% accurate for the planet earth due to the fact that it's an ellipsoid. couldn't the article link to an entry with the correct formula or at least the name of the formula to be used for the earth? —Preceding unsigned comment added by 81.56.82.123 (talk) 00:29, 19 August 2008 (UTC)

## Useful to add mention of Kahan's formula?

Just in case anybody is tempted to do a straight computer implementation of the haversine formula, with its large numerical errors near the antipodal point, maybe it could be useful to add a mention of another algorithm by William Kahan that addresses that issue? His somewhat roundabout description is at http://www.cs.berkeley.edu/~wkahan/Math128/angle.pdf Terry0051 (talk) 23:29, 2 March 2009 (UTC)

Discussion of alternative formulas for great-circle distances belongs on Great-circle distance, not here. —Steven G. Johnson (talk) 02:45, 3 March 2009 (UTC)
It's certainly surprising if a discussion of the material in this very article belongs only somewhere else: the formula previously mentioned is effectively a recasting of the formula that is the subject of this article, providing the same result while avoiding the numerical drawback.Terry0051 (talk) 16:47, 4 March 2009 (UTC)
All great-circle formulas are a recasting of the haversine formula, because all of them are equivalent in exact arithmetic. We have a whole article on great-circle formulas; we shouldn't be duplicating that material here when we can just link to that article. —Steven G. Johnson (talk) 17:30, 4 March 2009 (UTC)

## Geometric mean?

The article suggests using the geometric mean of the earth's equatorial and polar radii. There are two problems with this: First, it matters very little which mean is used for two numbers so close in value. The difference between the geometric and arithmetic means is only about 9 meters. But using either unweighted mean ignores the fact that much of the earth's surface is closer to the equator than to the poles. The average over the entire surface is about 2/3 a + 1/3 b, where a is the equatorial radius and b the polar radius, or a(1-1/3f), where f is the flattening. Using the WGS84 numbers, this is 6371008.771 meters, which for all practical purposes can be rounded to 6371 kilometers. —Preceding unsigned comment added by 63.86.92.198 (talk) 13:25, 6 May 2009 (UTC)

At the very least the topic should link to the Earth radius topic, where common Earth radii values are explained. KAW 24 (talk) 16:29, 8 February 2010 (UTC)

## Why not delete the "(in radians)" part

There are no factors of Pi in the equation so it should work perfectly well if your latitude and longitude are in degrees. Just don't mix radians and degrees in the same sin or cos.

Probably the "in radians" was because the formula also includes haversine(d/R), which is only correct if the argument to the haversine function is taken to be in radians. — Steven G. Johnson (talk) 04:02, 5 August 2009 (UTC)

## How to use Haversine to compute distance and angle between two points?

If I have two points defined as Lat1, Long1 and Lat2 and Long2, where these numbers are in terms of degrees of latitude and longitude (in terms of decimal degrees, not DMS) then how would I use the Haversine forumula to compute the distance between the two points, and the angle (or heading) of point 2 relative to point 1. For example, if the first point was the location of my TV antenna, and the second point was the location of a TV transmission tower (50 to 150 miles away), then I want to know the distance and also the direction to point my antenna. (I know that TV fool.com does this, but I want to compute the heading or direction manually). — Preceding unsigned comment added by 65.95.198.181 (talk) 16:58, 25 May 2013 (UTC)

## Ellipsoid distances

It would be nice if Wikipedia could have a formula for distances on ellipsoids, e.g. the WGS84 ellipsoid (prefererably a generic formula with parameters for WGS84 and other geodetic ellipsoids). If Wiki already has such an article this article should link to it.150.227.15.253 (talk) 14:37, 21 February 2019 (UTC)

## Alternate Haversine Formula Avoiding Cosine: Loss of significance near poles.

On 9 November 2021 an alternate versions of the haversine formula written using only the haversine function, multiplication, additions and subtraction was added to the article. To justify the alternate version the edit says cosines cause resolution degradation. Presumably, this refers to loss of significant figures. I believe the new alternate version of this formula is actually more likely to produce a loss of significance. See the original formula and the new alternate formula below:

Original Haversine Formula

The haversine formula allows the haversine of θ (that is, hav(θ)) to be computed directly from the latitude (represented by φ) and longitude (represented by λ) of the two points:

${\displaystyle \operatorname {hav} \left(\theta \right)=\operatorname {hav} \left(\varphi _{2}-\varphi _{1}\right)+\cos \left(\varphi _{1}\right)\cos \left(\varphi _{2}\right)\operatorname {hav} \left(\lambda _{2}-\lambda _{1}\right)}$

Altnerate Haversine Formula Added in the 9 Nov 2021 edit

or, to avoid using cosines which cause resolution degradation at small angles:

${\displaystyle \operatorname {hav} (\theta )=\operatorname {hav} (\varphi _{2}-\varphi _{1})+\left(1-\operatorname {hav} (\varphi _{1}-\varphi _{2})-\operatorname {hav} (\varphi _{1}+\varphi _{2})\right)\cdot \operatorname {hav} \left(\lambda _{2}-\lambda _{1}\right)}$

The edit doesn't describes conditions under which the original version of the haversine formula can cause loss of significance or how the alternate version improves this. Since the haversine function is always positive and cosine is positive when the latitudes (φ1 and φ2) are normalized between -90° and +90°, I think the original version of haversine formula is reasonably robust against loss of significance when it is used to solve for θ (provided the latitudes are normalized).

However, the new alternate version of the haversine formula is not robust near the poles due cancellation in the subtraction. For instance, consider φ1 = φ2 = 89.9°, λ1 = 0°, λ2 = 180°. Obviously, these two points are exactly 0.2° apart so θ = 0.2°. Unfortunately, using the alternate version of haversine formula to solve for θ with 5 digits of precision produces the wrong result due to the loss of significant figures in the subtraction:

{\displaystyle {\begin{aligned}\operatorname {hav} (\theta )&=\operatorname {hav} (\varphi _{2}-\varphi _{1})+\left(1-\operatorname {hav} (\varphi _{1}-\varphi _{2})-\operatorname {hav} (\varphi _{1}+\varphi _{2})\right)\cdot \operatorname {hav} \left(\lambda _{2}-\lambda _{1}\right)\\\operatorname {hav} (\theta )&=\operatorname {hav} (89.9^{\circ }-89.9^{\circ })+\left(1-\operatorname {hav} (89.9^{\circ }-89.9^{\circ })-\operatorname {hav} (89.9^{\circ }+89.9^{\circ })\right)\cdot \operatorname {hav} \left(180^{\circ }-0^{\circ }\right)\\\operatorname {hav} (\theta )&=\operatorname {hav} (0^{\circ })+\left(1-\operatorname {hav} (0^{\circ })-\operatorname {hav} (179.8^{\circ })\right)\cdot \operatorname {hav} \left(180^{\circ }-0^{\circ }\right)\\\operatorname {hav} (\theta )&=0+\left(1-0-0.999996954\right)\cdot 1\\\end{aligned}}}

rounding to 5 digits of precision:

{\displaystyle {\begin{aligned}\operatorname {hav} (\theta )&=0+\left(1-0-1.00000\right)\cdot 1\\\operatorname {hav} (\theta )&=0\\\theta &=0^{\circ }\\\end{aligned}}}

However, using the original version of the haversine formula to solve for θ gives a far more accurate solution to θ:

{\displaystyle {\begin{aligned}\operatorname {hav} \left(\theta \right)&=\operatorname {hav} \left(\varphi _{2}-\varphi _{1}\right)+\cos \left(\varphi _{1}\right)\cos \left(\varphi _{2}\right)\operatorname {hav} \left(\lambda _{2}-\lambda _{1}\right)\\\operatorname {hav} \left(\theta \right)&=\operatorname {hav} \left(89.9^{\circ }-89.9^{\circ }\right)+\cos \left(89.9^{\circ }\right)\cos \left(89.9^{\circ }\right)\operatorname {hav} \left(180^{\circ }-0^{\circ }\right)\\\operatorname {hav} \left(\theta \right)&=\operatorname {hav} \left(0^{\circ }\right)+\cos \left(89.9^{\circ }\right)\cos \left(89.9^{\circ }\right)\operatorname {hav} \left(180^{\circ }\right)\\\operatorname {hav} \left(\theta \right)&=0+\left(1.745328366\cdot 10^{-3}\right)\left(1.745328366\cdot 10^{-3}\right)\cdot 1\end{aligned}}}

rounding to 5 digits of precision:

{\displaystyle {\begin{aligned}\operatorname {hav} \left(\theta \right)&=0+\left(1.7453\cdot 10^{-3}\right)\left(1.7453\cdot 10^{-3}\right)\cdot 1\\\operatorname {hav} \left(\theta \right)&=3.0460\cdot 10^{-6}\\\theta &=\operatorname {archav} \left(3.0460\cdot 10^{-6}\right)\\\theta &=0.19999^{\circ }\end{aligned}}}

I think either the alternate version of the haversine formula should be removed from this article or conditions in which it is preferable to use the alternate version should be described and supported with citations.

Jeff D Harper (talk) 22:24, 31 May 2022 (UTC)

The point is not even slightly dubious, and it has centuries of navigational practice behind. It. The problem is that cos(theta) doesn't vary much for small angles (consider its near-horizontal slope near zero), so lots of precision is required to use it. Hence the alternate formulation which uses sin(theta) instead. Esmond.pitt (talk) 06:14, 13 July 2022 (UTC)

I support the removal of the alternate version.
The fact that cos(theta) has very little slope near zero is not a problem. On the contrary numerical instability arises from functions which have very high slope, arcsin and arccos being good examples. In fact, the numerical instability mentioned in this article when considering near-antipodal points arises from the arcsin in the formula. At near antipodal points the input to the arcsin function approaches 1, where very small changes to the input have large changes in its output. This problem exists regardless of if there is cos in the formula or not.
@Esmond.pitt, could you provide a specific example, i.e. a pair of lat,lon input values that exhibit the supposed problem. Andrewborrell (talk) 08:03, 29 September 2022 (UTC)