128-bit types

[foxtran]

Dear all,

In GCC (gfortran), integer(16), real(16), and complex(16) are supported as extensions https://gcc.gnu.org/onlinedocs/gfortran/ISO_005fC_005fBINDING.html.

IEEE-754 defines float128_t. float128_t would be supported in C++ since C++23 (https://en.cppreference.com/w/cpp/types/floating-point).

I would like to have integer(16), real(16), and complex(16) types in standard (probably, with an optional part of it).

[klausler]

You probably mean real(16), not float(16).

Beware, some compilers have 128-bit floating-point that is "double/double", not IEEE 128-bit.

The particular kind values are not standard, though most compilers use the same obvious values for the most popular sizes. (But beware when two kinds have the same size in bytes, like IEEE 16-bit vs "brain float" truncated 32-bit, or when a kind typically has extra padding bytes in storage, like the 8087's 80-bit extended precision.)

Portable code can use selected_real_kind()/selected_int_kind() and precision()/range() to determine whether a particular data format is available and what its kind code happens to be. Or, which is much easier, USE ISO_FORTRAN_ENV and then use the kind codes in REAL128 &c.

[certik]

I call it quadruple precision: https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format, and I've used it a few times with gfortran, it's very useful when double precision is not enough.

[foxtran]

@klausler,

You probably mean real(16), not float(16).

You're right. Thanks! Fixed now.

Beware, some compilers have 128-bit floating-point that is "double/double", not IEEE 128-bit.

Then it would be nice to have standardized behavior of these types rather than to give compiler developers the freedom to define the behavior of these types.

@certik,

it's very useful when double precision is not enough

Yep, they are useful, but not yet in standard.

[tkoenig1]

These types are not special, they are normal types available via selected_real_kind and selected_int_kind, respectively. The only thing the standard could add is to give them distinctive names, which would serve no real purpose; double precision is well-less defined than real64 or selected_real_kind(15).

Also note that gfortran (and gcc in general) does not support 128-bit integer arithmetic on 32-bit systems.

[PierUgit]

double precision is well-less defined than real64 or selected_real_kind(15)

Maybe. However, double precision is required to exist, while real64 is not.

[tkoenig1]

double precision is well-less defined than real64 or selected_real_kind(15)

Maybe. However, double precision is required to exist, while real64 is not.

Correct.

However, if you need more than 25 significant digits in a real, you can write

   integer, parameter :: qp = selected_real_kind(15)
  real(kind=qp) :: a

and one of two things will happen: Either the compiler supports such a type, then the code will compile. Or it does not, then the compilation will fail.

You can also have constants using the 1.2_qp syntax.

What benefits would the suggestion bring that selected_real_kind does not have?

[PierUgit]

What benefits would the suggestion bring that selected_real_kind does not have?

The proposal looks actually pointless, as in practice real128 from iso_fortran_env does what the OP wants. I am just pointing that the selected_real_kind mechanism, although a good idea, has some practical limitations. For instance when writing a library, sticking to real and double precision for the interfaces is generally simpler.

[FortranFan]

The proposal looks actually pointless, as in practice real128 from iso_fortran_env does what the OP wants

@foxtran ,

It may help if you can elaborate further and clarify what exactly you propose here, particularly given some of the comments here e.g., above with "The proposal looks actually pointless."

In your original post, you write, "I would like to have integer(16), real(16), and complex(16) types in standard (probably, with an optional part of it)."

But you may want to look into the "standard" to realize

1. a "magic number" such as 16 is meaningless, it will not make sense for the standard to give you what you "would like to have" with integer(16) or real(16), etc.
2. but now, know the standard states for integer types, "The processor shall provide at least one representation method with a decimal exponent range greater than or equal to 18." Now it appears you're a gfortran user and within the context of gfortran where an integer kind of 16 implies a representation of an integer with a decimal exponent range of at least 18, so you already have integer(16).
3. additionally, for the other two numeric intrinsic types, you included in parenthesis "probably, with an optional part of it" which is already the case!! That is, conforming Fortran processors can indeed include, if they so choose, representations that are equivalent to what you seem to mean as real(16), etc.

Hence the suggestion above for you to explain further what you seek here.