3

Can someone explain the differences between doubles and long doubles except for the difference in precision to me? I wrote a program to solve a gravitational n-body problem so i basically integrate second order differential equations and my program works fine using doubles. When i however replace all the doubles i use with long doubles all the calculations seem to produce nonsensical results. Can someone explain the reason for this?

On the contrary to what everyone seems to think i can't find the awnsers i'm looking for on the long double vs double thread.

W. Verbeke
  • 355
  • 2
  • 12
  • 1
    You might be able to salvage this question if you give us an [MCVE](http://stackoverflow.com/help/mcve) showing how you get "nonsensical results." – Fred Larson Dec 11 '14 at 15:37
  • 6
    "MCVE" in my comment is a link. Click it. – Fred Larson Dec 11 '14 at 15:38
  • 1
    How are you outputting the results? – doctorlove Dec 11 '14 at 15:40
  • The point is that when i use long doubles all the results from the integration immediately blow up and go towards infinity ( orders of e500 etc...) whereas using doubles they are of the order of thousands. – W. Verbeke Dec 11 '14 at 15:41
  • It's really weird ... long double have normally better precision than doubles and that should not degrade quality. I suspect a problem of displaying the results. Please add some code including the display of results before the question is closed as duplicate. – Serge Ballesta Dec 11 '14 at 15:43
  • Without looking at the code it's impossible to guess what's wrong with it. Obviously you have rounding errors that result in divisions by very small numbers. Floating points mean loss of precision due to scaling. Even a subtraction that would lead to 0 can result in a very small non-zero number. Perhaps your code checks against 0 instead of a very small number so the errors aren't detected – Panagiotis Kanavos Dec 11 '14 at 15:43
  • The problem is that my code is 800 lines long and i believe few people here would want to look at it and i don't have the time right away to create a smaller version. – W. Verbeke Dec 11 '14 at 15:46
  • @SergeBallesta scaling can cause errors despite better precision. – Panagiotis Kanavos Dec 11 '14 at 15:46
  • What do you mean by scaling? – W. Verbeke Dec 11 '14 at 15:46
  • Comment for closers : OP says that passing from doubles to long doubles degrades results. Question linked for closing as duplicate explains that long doubles have at least same quality as doubles. So it really does not answer *this* question. – Serge Ballesta Dec 11 '14 at 15:48
  • @PanagiotisKanavos : I cannot imagine how increasing precision could add problems in floating point operations. But I do agree on one point : we need some code including data input and output and example of operations. – Serge Ballesta Dec 11 '14 at 15:52
  • @user3642133 scaling errors are a very common cause for algorithm failures. A floating point number consists of an exponent and a mantissa. The exponent has to be the same before addition/subtraction which usually results in rounding errors for the smaller number. As a result, operations that should result in 0 may result in a non-zero number or worse. That's why you should check values against a very small number instead of 0 if you want to avoid unexpected results. Check [here](http://en.wikipedia.org/wiki/Floating_point#Addition_and_subtraction) for examples – Panagiotis Kanavos Dec 11 '14 at 15:52
  • 1
    MinGW has historically had issues with `long double`. This may help: http://stackoverflow.com/a/14988103/465323 – Zéychin Dec 11 '14 at 15:53
  • @SergeBallesta values that would be truncated to 0 can survive with a larger precision float - assuming the compiler doesn't do something particularly bad with long doubles. The n-body problem is **the canonical** example of algorithm instability, that contributed to the discovery of fractals and chaos theory – Panagiotis Kanavos Dec 11 '14 at 15:55
  • 4
    @user3642133: The problem here is that you're asking the wrong question. You're asking what the difference is between `double` and `long double`, but that question has already been answered and the answer doesn't solve your problem. Your question should be, "What am I doing wrong using `long double`", and then show us code that illustrates your problem. – Fred Larson Dec 11 '14 at 15:56
  • @PanagiotisKanavos : got the point, but I hardly imagine that a program that compares float to *exact* 0 can survive even with single precision float ... I once was burnt with that and never did it again ! – Serge Ballesta Dec 11 '14 at 16:05
  • what do you mean by comparing float to exact 0? – W. Verbeke Dec 11 '14 at 16:07
  • I hope OP saw my comment that actually addresses the issue. I would like to advise SergeBallesta and Fred Larson to take their conversation to chat to avoid cluttering. – Zéychin Dec 11 '14 at 16:15
  • 1
    @user3642133 : if x is a floating point number, you should never test `x == 0.` but always `abs(x) < epsilon` where epsilon is given by the precision you need - But you could also look [this other SO post](http://stackoverflow.com/questions/4089174/printf-and-long-double) – Serge Ballesta Dec 11 '14 at 16:24
  • @Zéychin your link refers to `printf` not actual math operations. It doesn't address the issue. The conversation has actually moved much closer to the real problem. – Panagiotis Kanavos Dec 12 '14 at 09:34
  • The operations may well be working properly and well-conditioned. But, if you are printing them using the wrong format specifier, because MinGW tries to interpret an 80-bit number as a 64-bit number, you are going to have problems. Either way, speculating on the potential implementation of code that hasn't been provided helps no one. – Zéychin Dec 12 '14 at 20:12

1 Answers1

0

Maybe refer to here: Why would you use float over double, or double over long double?

But simply a long is normally refers to something similar to an int.

I think you are looking for a long double... If you put only long it will mess you code up because its not a double or a float...

Here review data types: http://en.wikipedia.org/wiki/C_data_types

Community
  • 1
  • 1
Ya Wang
  • 1,758
  • 1
  • 19
  • 41