6

I'm currently doing distance calculations between coordinates and have been getting slightly different results depending on the language used.

Part of the calculation is taking calculating the cosine of a given radian. I get the following results

// cos(0.8941658257446736)

// 0.6261694290123146 node
// 0.6261694290123146 rust
// 0.6261694290123148 go
// 0.6261694290123148 python
// 0.6261694290123148 swift
// 0.6261694290123146 c++
// 0.6261694290123146 java
// 0.6261694290123147 c

I would like to try and understand why. If you look past 16dp c is the only "correct" answer in terms of rounding. What I am surprised as is python having a different result.

This small difference is being amplified currently and over 000's of positions it is adding a not insignificant distance.

Not really sure how this is a duplicate. Also I am more asking for a holistic answer rather than language specific. I don't have a compute science degree.

UPDATE

I accept that maybe this is too broad a question I suppose I was curious as to why as my background isn't CS. I appreciate the links to the blogs that were posted in the comments.

UPDATE 2

This question arose from porting a service from nodejs to go. Go is even weirder as I am now unable to run tests as the summation of distances varies with multiple values.

Given a list of coordinates and calculating the distance and adding them together I get different results. I'm not asking a question but seems crazy that go will produce different results.

9605.795975874069
9605.795975874067
9605.79597587407

For completeness here is the Distance calculation I am using:

func Distance(pointA Coordinate, pointB Coordinate) float64 {
    const R = 6371000 // Earth radius meters
    phi1 := pointA.Lat * math.Pi / 180
    phi2 := pointB.Lat * math.Pi / 180
    lambda1 := pointA.Lon * math.Pi / 180
    lambda2 := pointB.Lon * math.Pi / 180

    deltaPhi := phi2 - phi1
    deltaLambda := lambda2 - lambda1
    a := math.Sin(deltaPhi/2)*math.Sin(deltaPhi/2) + math.Cos(phi1)*math.Cos(phi2)*math.Sin(deltaLambda/2)*math.Sin(deltaLambda/2)
    c := 2 * math.Atan2(math.Sqrt(a), math.Sqrt(1-a))

    d := R * c
    return d
}
Improve this question
17
  • 16
    The results you posted are the results somehow displayed to you. That somehow might involve rounding and truncating, varies on languages and the way you print it. For example Go's output is 0.6261694290123148, but if you use "higher precision" printing like fmt.Printf("%.25f", v), you'll get 0.6261694290123147599302911. The 16th fraction digit becomes 7 not 8 compared to when printed using the default format. Commented Oct 16, 2019 at 11:13
  • 8
    Possible duplicate of double and accuracy You are right on the edge and this will depend on how cos is implemented and if 80-bit floating point is used for the intermediate results. Commented Oct 16, 2019 at 11:14
  • 6
    Basically you are asking 10 questions in one (like "what does X do in language Y", for 10 different languages). Plus: telling us what you think your code does ... isnt sufficient. See minimal reproducible example. How are supposed to tell you what kind of FP problem you might have, without being able to look at the exact code that created one of those lines?! Commented Oct 16, 2019 at 11:15
  • 1
    Its not that difficult to replicate, simply calculating cosine, need the exact syntax for every lanuage?? This is using builtins for every language so dont understand what you would like. Im asking a more holistic question as @icza has done Commented Oct 16, 2019 at 11:17
  • 4
    Fun fact: In C++ it is very possible that x = 0.8941658257446736; assert(cos(x) == cos(x + argc/1000)); fires (one might be computed at compile time, the other at run-time, possibly using different methods). See the "Transcendentals" section at randomascii.wordpress.com/2013/07/16/floating-point-determinism. So yes, the exact syntax (and compiler, and flags, and floating point rounding mode, etc.) used may be relevant. Commented Oct 16, 2019 at 11:18

2 Answers 2

Reset to default
2

IEEE-754 only requires basic operations (+-*/) and sqrt to be correctly rounded, i.e. the error must be no more than 0.5ULP. Transcendental functions like sin, cos, exp... are very complex so they're only recommended to be correctly rounded. Different implementations may use different algorithms to calculate the result for those functions depending on the space and time requirements. Therefore variations like you observed is completely normal

There is no standard that requires faithful rounding of transcendental functions. IEEE-754 (2008) recommends, but does not require, that these functions be correctly rounded.

Standard for the sine of very large numbers

See also

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

“Correctly rounded” and “faithfully rounded” are specific terms in floating-point, and they need to be used carefully. “Properly rounded” is not a specifically defined phrase; it would depend on context as to what “proper” is. “Correct” rounding is the strictest: The floating-point result must be the infinitely precise result rounded to the number uniquely determined by the rounding rules. This is not equivalent to rounding of at most ½ ULP, as the rule for ties must be obeyed. “Faithful” is looser: The result may be one of the two immediately surrounding neighbors.
The phrase “only recommended to be properly rounded” has “only” near “recommended” although it is more likely intended to modify “properly rounded.”
Also worth noting is that humans do not yet know how to evaluate all the “elementary” functions (sine, cosine, logarithm, and so on) with correct rounding in a known-bounded execution time. Nobody would be able to implement a library satisfying IEEE 754’s recommendation with a known bound on execution time without new research. At my suggestion, the committee voted to recommend faithful rounding, but it was changed in balloting after the committee finished its work.
1

Generally, the representation of floating point numbers is defined by the standard IEEE 754 and my assumption is that this standard is implemented by all (major) programming languages.

Precision and rounding are known issues and may sometimes lead to unexpected results.

Aspects that may have an influence on the result of a calculation depending on the programming language or used math library:

  • different calculation methods (in your case: the cosine function might be implemented by numerical approximation with different approaches)
  • different rounding strategies during calculation or for the final output
Improve this answer

2 Comments

it is not language matter, but hardware (CPU and FPU design).
@MarekR: Hardware can make IEEE754 easier or harder to implement, but you can do IEEE754 fully in software.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.