3

Or put differently, are there equivalents to intmax_t and %jd but for floating point numbers?

This has already been asked as a side question here, but the question is so large that I think people forgot to answer the side question. Also that was tagged as c++, and I'm looking for a c solution.

Related questions:

Community
  • 1
  • 1
Ciro Santilli OurBigBook.com
  • 347,512
  • 102
  • 1,199
  • 985

2 Answers2

4

To my knowledge C does not have extended floating point types. The only floating point types are float, double, and long double. Thus, %La, %Le, %Lf, %Lg, and long double seem to be your answers.

Some implementations may provide additional extended types, but they are completely outside the scope of the standard.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • Why is the situation of floats different from the situation of integers? Integers also only go up to `long long` on any implementation (TODO please confirm this), but still I like the idea of using `intmax_t` just in case in 10 years a larger type becomes available. – Ciro Santilli OurBigBook.com Jun 19 '13 at 11:10
  • C explicitly defines semantics for extended integer types, if they exist. This allows such extended types to be used as part of the implementation, e.g. for defining `intNN_t`, etc. However, no similar provision is made for floating point, so extended floating point types could not be used as the definition for types like `time_t` or `double_t` in a conforming implementation. – R.. GitHub STOP HELPING ICE Jun 19 '13 at 11:19
  • I had never heard of semantics for types and will certainly look it up. Any links greatly appreciated. – Ciro Santilli OurBigBook.com Jun 19 '13 at 12:27
2

C11 does not have a floating point equivalents to intmax_t (Integer type with the maximum width supported.). Should C of the future define some sort of long long double, etc. the language presently has no seamless upgrade path to it.

C11 6.11.1.1 "Future standardization may include additional floating-point types, including those with greater range, precision, or both than long double." does point to the possibility of larger widths you envision.

The situation for floating-point numbers differs from integers in need. Various processors have had increasingly width integer widths over the years (8,16,32,64) and 128 on the horizon. Whereas gross floating-point size has been relatively more stable (4,8,10,16) , precision, range, encoding, rounding have taken up much FP concern. I suspect we'll see decimal and binary floating point specifications next.

Another difference is that integers grow in one dimension - range. FP can grow independently in range and precision, not to mention the peculiarities of base (2, 10, 16, etc.) Also see "IEEE 754" comment below.

Presently we have 3: C11 6.2.5.4 : float, double, and long double. Should you want to create a forward compatibly path you could prepare for a change with say typedef long double Xdouble, but then you may be obliged to write a lot of wrapper functions like Xdouble sinX(Xdouble x);, prepare many equivalent defines to DBL_MANT_DIG, PRIdN, etc. No small effort.

chux - Reinstate Monica
  • 143,097
  • 13
  • 135
  • 256
  • I agree that having multiple representation parameters is a key question, there are multiple alternatives for a single data width. – Ciro Santilli OurBigBook.com Jun 19 '13 at 14:13
  • Are 128-bit integers really "on the horizon"? I don't recall seeing any serious proposals. – Keith Thompson Jun 19 '13 at 14:41
  • 2
    @KeithThompson: many compilers already have partial support for 128b integers, even if they underlying hardware they target does not; clang and gcc expose them for LP64 targets via `__int128_t` and `__uint128_t`, for example. – Stephen Canon Jun 19 '13 at 15:54
  • gcc 4.7.2 recognizes `__int128` (but not `__uint128`), `__uint128_t` (but not `__int128_t`), and `unsigned __int128`. The documentation refers to `__int128` and `unsigned __int128`. It's probably supported only on 64-bit targets. – Keith Thompson Jun 19 '13 at 17:42
  • 1
    About the multiple dimension: that should not be a problem in IEEE 754 because "For an extended format with a precision between two basic formats the exponent range must be as great as that of the next wider basic format. So for instance a 64-bit extended precision binary number must have an 'emax' of at least 16383. The x87 80-bit extended format meets this requirement." https://en.wikipedia.org/wiki/IEEE_floating_point#Extended_and_extendable_precision_formats – Ciro Santilli OurBigBook.com Jun 04 '15 at 07:19