printing long double looks failing in c (gives output as double not long double)

Question

The output is as:

$ ./printnum 
FLOAT:       3.1415927410125732421875000
DOUBLE:      3.1415926535897931159979635
LONG DOUBLE: 3.1415926535897931159979635

for the below program:

int main(int argc, char *argv[])
{
  int i;
  float a;
  double b;
  long double c;
  a=3.141592653589793238462643383279502884197;
  b=3.141592653589793238462643383279502884197;  
  c=3.141592653589793238462643383279502884197;  
  printf("FLOAT:       %.25f\n",a);
  printf("DOUBLE:      %.25f\n",b);
  printf("LONG DOUBLE: %.25Lf\n",c); 
};

I could not be sure why the output looks like double for %f and %Lf both.

the numbers you wrote in your program are doubles themselves — user253751, Apr 08 '22 at 10:54
Also, maybe check `sizeof(double)` and `sizeof(long double)`. On some platforms (notably MSVC/Windows), they are actually the same size and precision (although they are *distinct* types). — Adrian Mole, Apr 08 '22 at 11:14
OT: There is a dangling semicolon after the `main()` function. — the busybee, Apr 08 '22 at 11:17
Pretty much everything in your source has a type, including floating point constants. Decent beginner learning materials tells us not to mix `float` with `double` constants and vice versa. (`1.0f` being `float` and `1.0` being `double`.) Same applies to `long double`. — Lundin, Apr 08 '22 at 11:44
FLOAT: 3.1415927410125732421875000 (4) DOUBLE: 3.1415926535897931159979635 (8) LONG DOUBLE: 3.1415926535897932385128090 (16) The value in the parenthesis is the sizeof-value for each case. But the print result in the last case is still not correct (or not same as in the 'c=' substitution. Maybe actually the long double is 10 bytes (or 80 bits), not 16 bytes? — user1070696, Apr 08 '22 at 13:05
It looks the long double being 10 bytes, not 16.. how can I check? But it uses the whole space of the 16 bytes for storing 10 bytes? — user1070696, Apr 08 '22 at 13:25
@user1070696 padding is necessary for performance. If you want to check it just use `LDBL_MANT_DIG` which gives you the number of significand bits, and `LDBL_MAX_EXP` for the exponent range — phuclv, Apr 08 '22 at 15:33

chux - Reinstate Monica · Answer 1 · 2022-04-08T11:39:50.800

0

double b and long double c are both initialized with the same double constant and so print the same value. @user253751.

To see a potential difference use a long double constant.

// c=3.141592653589793238462643383279502884197;
c=3.141592653589793238462643383279502884197L; // Append an L

Tip: enable all warnings.

warning: conversion from 'double' to 'float' changes value from '3.1415926535897931e+0' to '3.14159274e+0f' [-Wfloat-conversion]

a=3.141592653589793238462643383279502884197; is better as a=3.141592653589793238462643383279502884197f;// appended f as sometimes the f makes for a better value.

edited Apr 08 '22 at 11:39

answered Apr 08 '22 at 11:34

chux - Reinstate Monica

143,097
13
135
256

OK. Appending the L seems the way to do it. $ ./printnum FLOAT: 3.1415927410125732421875000 (4) DOUBLE: 3.1415926535897931159979635 (8) LONG DOUBLE: 3.1415926535897932385128090 (16) The value in parenthesis is the "sizeof"-result. But long double actually didn't fully fix all the 25 digits and I think the long double actually is 10 bytes (or 80 bits), not 16 bytes. It looks like the substution of all the possible digits is not 'automated' according to datatype in this case of long double. The execution times are gone to half, even there is added only 16 bits. – user1070696 Apr 08 '22 at 13:20
@user1070696 if you use x86 on non-MSVC compilers then `long double` would be 80-bit extended precision with 6 bytes of padding by default – phuclv Apr 08 '22 at 15:30
@user1070696 Please explain more your thought: "It looks like the substution of all the possible digits is not 'automated' according to datatype in this case of long double." – chux - Reinstate Monica Apr 08 '22 at 18:21

printing long double looks failing in c (gives output as double not long double)

1 Answers1