Implementation of type "long double" with GCC and C++11

Question

I've tried searching for information on long double, and so far I understand it is implemented differently by compilers.

When using GCC on Ubuntu (XUbuntu) Linux 12.10 I get this:

double PId = acos(-1);
long double PIl = acos(-1);
std::cout.precision(100);

std::cout << "PId " << sizeof(double) << " : " << PId << std::endl;
std::cout << "PIl " << sizeof(long double)  << " : " << PIl << std::endl;

Output:

PId 8  : 3.141592653589793115997963468544185161590576171875
PIl 16 : 3.141592653589793115997963468544185161590576171875

Anyone understand why they output (almost) the same thing?

`acos` won't return a long double as long as you don't pass a long double as argument.. — stefan, Dec 16 '12 at 17:39
Side note: g++-4.6.3 requires the use of `std::acos` instead of `acos` to show a difference (at least on my ubuntu x86 machine) — stefan, Dec 16 '12 at 17:46

score 8 · Answer 1 · edited Nov 07 '14 at 11:59

According to the reference of acos, it will return a long double only if you pass a long double to it. You'll also have to use std::acos like baboon suggested. This works for me:

#include <cmath>
#include <iostream>

int main() {

  double PId = acos((double)-1);
  long double PIl = std::acos(-1.0l);
  std::cout.precision(100);

  std::cout << "PId " << sizeof(double) << " :  " << PId << std::endl;
  std::cout << "PIl " << sizeof(long double)  << " : " << PIl << std::endl;
}

Output:

PId 8  : 3.141592653589793115997963468544185161590576171875
PIl 12 : 3.14159265358979323851280895940618620443274267017841339111328125

         3.14159265358979323846264338327950288419716939937510582097494459

The last line is not part of the output and contains the correct digits for pi to this precision.

Use std::acos, as suggested by @bamboon. Then 1.0l works fine. — Artem Sobolev, Dec 16 '12 at 17:51
Not for MinGW, it seems: `error: 'acos' is not a member of 'std'` — schnaader, Dec 16 '12 at 17:51

score 6 · Accepted Answer · edited Dec 22 '12 at 16:25

6

To get the correct number of significant digits use std::numeric_limits. In C++11 we have digits10 for decimal significant digits (as opposed to digits which gives significant bits).

#include <cmath>
#include <iostream>
#include <limits>

int
main()
{
  std::cout.precision(std::numeric_limits<float>::digits10);
  double PIf = acos(-1.0F);
  std::cout << "PIf " << sizeof(float) << " :  " << PIf << std::endl;

  std::cout.precision(std::numeric_limits<double>::digits10);
  double PId = acos(-1.0);
  std::cout << "PId " << sizeof(double) << " :  " << PId << std::endl;

  std::cout.precision(std::numeric_limits<long double>::digits10);
  long double PIl = std::acos(-1.0L);
  std::cout << "PIl " << sizeof(long double)  << " : " << PIl << std::endl;
}

On x86_64 linux I get:

PIf 4 :  3.14159
PId 8 :  3.14159265358979
PIl 16 : 3.14159265358979324

edited Dec 22 '12 at 16:25

answered Dec 16 '12 at 18:25

emsr

15,539
6
49
62

1

It needs to use `std::numeric_limits::digits10 + 1`. E.g. `std::numeric_limits::digits10 + 1 == 3` – Maxim Egorushkin Mar 03 '15 at 16:43
@MaximEgorushkin C++11 adds `std::numeric_limits::digits10` that is guaranteed to round trip. In g++ this is routed to `__glibcxx_max_digits(__FLT_MANT_DIG__)` where the arg is a macro gotten from configuration. The result is digits10 + 2 for floating point types. For integral types `max_digits10` is set to 0 (why?). For the above code I should edit to `max_digits10`. Also, digits10 has always been there - i.e. before C++11. – emsr Mar 03 '15 at 21:02
I'm going to look further about the integral versions of digits10 and max_digits10. I wonder if either g++ of the standard is making a mistake. – emsr Mar 03 '15 at 21:05
I could argue that, for *display* purposes, `digits10` is correct. The extra digits provided by using `max_digits10` are inaccurate but are necessary to ensure that enough bits are loaded after a read so that rewriting the decimal to `digits10` still retains accuracy. Still not sure what's up with integral types. – emsr Mar 03 '15 at 21:09
The standard is pretty clear on [`digits10`](http://en.cppreference.com/w/cpp/types/numeric_limits/digits10): _is the number of base-10 digits that can be represented by the type T without change, that is, any number with this many decimal digits can be converted to a value of type T and back to decimal form, without change due to rounding or overflow._ E.g. any 3 digits cannot be represented by `uint8_t`, whereas any 2 can. – Maxim Egorushkin Mar 04 '15 at 11:09
I think they punted on `max_digits10` for integers. They should have made it `max_digits10 = digits10 + 1` so that a large uint8_t of, say, 145 could be written and read back. I think a lot of this had to do with mixing the semantics of integer and floating point in the same utility. – emsr Mar 05 '15 at 14:36

Stephan Dollberg · Answer 3 · 2012-12-16T17:57:35.170

4

Try:

long double PIl = std::acos(-1.0L);

That makes you pass a long double and not just an int which gets converted.

Note that mostly all of these numbers are rubbish anyway. With an 8 byte double you get 15 Numbers of precision, if you compare your numbers with the real PI

3.1415926535897932384626433

You see that only the first 15 Numbers fit.

As noted in the comments, you probably won't get double the precision as the implementation might only use a 80Bit representation and then it depends on how many bits it reserves for the mantissa.

edited Dec 16 '12 at 17:57

answered Dec 16 '12 at 17:43

Stephan Dollberg

32,985
16
81
107

Ah yes, thank you I get a few extra characters printed. (13 more) Is this expected? I would have thought I should get something about twice the length printed out? – FreelanceConsultant Dec 16 '12 at 17:45
1

@EdwardBird No, that totally depends on how many bit the implementation will reserve for the mantissa. – Stephan Dollberg Dec 16 '12 at 17:56

Implementation of type "long double" with GCC and C++11

3 Answers3

Linked