REAL16 proposal

[certik]

The document N2169 lists the approved items from the WG5 August 2019 Meeting in Tokyo, one of which is:

US08 - Additional named constant, REAL16, in ISO_FORTRAN_ENV to specify whether the processor supports a 16-bit REAL KIND. J3/19-139r1

[certik]

I know there was a discussion about this point, as I asked the same question. @tclune do you remember what the arguments were?

[tclune]

I think I've missed something. What is the question/position for which arguments are desired?

[certik]

@klausler was asking why not to just use SELECTED_REAL_KIND instead of REAL16 from ISO_FORTRAN_ENV.

[tclune]

Sorry - I did not real the OP carefully enough. Now I understand the context.

At the very least checking to see if two results from SELECTED_REAL_KIND differ is something that happens at run time, and sometimes one wants to know at compile time that some functionality is not available.

The question is really about why the existing standard has REAL32, REAL64, and REAL128. These are much more practical for library developers that wish to overload their procedures for the supported kinds of REAL provided by a given implementation. In that case it is not that the developer wants a certain amount of precision. They are trying to support other users that get to choose precision on their own. REAL16 is proposed just simply to be consistent for an increasingly common option on some hardware.

Note that REAL32 et al are not quite sufficient in and of themselves to allow a portable implementation that covers all supported real kinds. Generally some logic is still required in the build system to control which kinds are selected.

Note also that REAL32 is not necessarily the same thing as default REAL. Theoretically it can be tricky to distinguish such things. In practice, all extant compilers have kind(1.) == REAL32

[FortranFan]

@klausler wrote:

Why not use SELECTED_REAL_KIND()?
..

@klausler, can you please explain your point here?

Are you giving a "thumbs down" or suggesting the proposal involving a trivial effort to add another few named constants (e.g., REAL16, LOGICAL8, LOGICAL16, ..)) to the list of those introduced in the language starting Fortran 2008 (such as REAL32) in ISO_FORTRAN_ENV intrinsic module be removed from consideration?

[certik]

@FortranFan I think @klausler is just asking a general question if user code should be using SELECTED_REAL_KIND or ISO_FORTRAN_ENV. Thanks @tclune for the answer.

[certik]

@klausler this is a long standing issue in Fortran, how you are supposed to declare the precision of the real variable. With multiple opinions even on the committee itself. I personally actually just use dp = kind(1.d0) for double precision, as that is the shortest, and otherwise I use SELECTED_REAL_KIND. I do not use ISO_FORTRAN_ENV. But I know several colleagues that use ISO_FORTRAN_ENV.

[certik]

@klausler exactly. The other functions that go hand in hand with this are epsilon and tiny, both of which I use quite often. That way the numerical code is actually quite independent of the actual accuracy of the real type. In practice I only test with double precision, but I think the porting to single precision or quadruple precision would not be that hard with my codes.