• Standardize real*8 as real(kind=real64)?

    From Beliavsky@21:1/5 to All on Sat Apr 9 07:05:28 2022
    Since compilers treat the non-standard but very common

    real*4, real*8, integer*4, integer*8

    as

    use iso_fortran_env
    real(kind=real32), real(kind=real64), integer(kind=int32), integer(kind=int64)

    would it make sense to standardize the former set of declarations, which is concise and clear, to mean the same as the latter?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Beliavsky@21:1/5 to Beliavsky on Sat Apr 9 07:37:39 2022
    On Saturday, April 9, 2022 at 10:05:29 AM UTC-4, Beliavsky wrote:
    Since compilers treat the non-standard but very common

    real*4, real*8, integer*4, integer*8

    as

    use iso_fortran_env
    real(kind=real32), real(kind=real64), integer(kind=int32), integer(kind=int64)

    would it make sense to standardize the former set of declarations, which is concise and clear, to mean the same as the latter?

    Currently, if someone inherits a code with real*8 and decides to make it standard-conforming, they may replace it with
    real(kind=8), which is not guaranteed to work (failing with the NAG compiler for example). By standardizing real*8 appropriately this error is avoided.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Beliavsky on Sat Apr 9 07:55:38 2022
    On Sunday, April 10, 2022 at 12:37:41 AM UTC+10, Beliavsky wrote:
    On Saturday, April 9, 2022 at 10:05:29 AM UTC-4, Beliavsky wrote:
    Since compilers treat the non-standard but very common

    real*4, real*8, integer*4, integer*8

    as

    use iso_fortran_env
    real(kind=real32), real(kind=real64), integer(kind=int32), integer(kind=int64)

    would it make sense to standardize the former set of declarations, which is concise and clear, to mean the same as the latter?
    Currently, if someone inherits a code with real*8 and decides to make it standard-conforming, they may replace it with
    real(kind=8),
    .
    An appropriate replacement is real (kind=dp)
    which is one character more than the non-portable form you just suggested. (where dp is defined as kind(1.0d0) or something equivalent specifying a number of digits )
    .
    which is not guaranteed to work (failing with the NAG compiler for example). By standardizing real*8 appropriately this error is avoided.
    .
    real*8 has never been standard.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to Beliavsky on Sat Apr 9 08:39:12 2022
    On Saturday, April 9, 2022 at 10:05:29 AM UTC-4, Beliavsky wrote:
    ..
    would it make sense to standardize the former set of declarations, which is concise and clear, to mean the same as the latter?

    No.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Beliavsky on Sat Apr 9 09:08:53 2022
    On Saturday, April 9, 2022 at 7:05:29 AM UTC-7, Beliavsky wrote:
    (snip)

    would it make sense to standardize the former set of declarations,
    which is concise and clear, to mean the same as the latter?

    One thing that I have long thought, is that it would be nice to include in the standard some things that aren't required of implementations, but indicate
    how to do something if it is included.

    (And more generally than this question.)

    In the past, this was complicated by machines with 60 or 64 bit words,
    that had a type of that length as default REAL, and then (as required by
    the standard) a longer type of DOUBLE PRECISION. Those machines are
    now out of favor.

    On the other hand, the IEEE 754-2008 decimal floating point has
    the 64 bit and 128 bit forms as basic types. I suspect that a Fortran
    compiler implementing those would use them as the single and
    double precision types. (The 32 bit form has about the same status
    as the 16 bit binary form.)

    There are many deprecated features that it would be very easy to write
    a program to convert to non-deprecated form. As far as I know, that hasn't been done. (And in both free and fixed form.)

    I do find it interesting that the Fortran II PRINT statement, after not making it into Fortran 66, later was included in the standard. Including REAL*8 makes about as much sense.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Beliavsky on Sat Apr 9 09:16:44 2022
    On Saturday, April 9, 2022 at 7:37:41 AM UTC-7, Beliavsky wrote:

    (snip)

    Currently, if someone inherits a code with real*8 and decides to make it standard-conforming, they may replace it with real(kind=8), which is not guaranteed to work (failing with the NAG compiler for example).

    By standardizing real*8 appropriately this error is avoided.

    As far as I know, REAL(8) is more popular, and equally standard and non-portable.

    I even knew of a MOOC, meant for introducing Fortran to physicists,
    that taught REAL(8).

    REAL(KIND(1D0))

    would be standard, and reliably give a double precision type, though takes
    more characters to type.

    It is nice to have something that can be replaced, line by line, without the need for any other lines to be included. (Well, assuming appropriate continuation rules.)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Beliavsky@21:1/5 to All on Sat Apr 9 09:46:11 2022
    On Saturday, April 9, 2022 at 12:16:46 PM UTC-4, gah4 wrote:
    As far as I know, REAL(8) is more popular, and equally standard and non-portable.

    I even knew of a MOOC, meant for introducing Fortran to physicists,
    that taught REAL(8).

    REAL(KIND(1D0))

    would be standard, and reliably give a double precision type, though takes more characters to type.

    It is nice to have something that can be replaced, line by line, without the need for any other lines to be included. (Well, assuming appropriate continuation rules.)

    If someone declares variables as real*8 they are saying that 8-byte reals are sufficient.
    You could have a platform where singe precision is real(kind=real64) and double precision is real(kind=real128). In that case the natural equivalent of real*8 would be
    real(kind=real128) and not real(kind=kind(1.0d0)).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to Beliavsky on Sat Apr 9 12:15:41 2022
    On 4/9/22 9:05 AM, Beliavsky wrote:
    Since compilers treat the non-standard but very common

    real*4, real*8, integer*4, integer*8

    as

    use iso_fortran_env
    real(kind=real32), real(kind=real64), integer(kind=int32), integer(kind=int64)

    would it make sense to standardize the former set of declarations, which is concise and clear, to mean the same as the latter?

    In my opinion, this would be a step backward for the language.

    There are many reasons why this should not be done, but one of them is
    that REAL*4 etc. were always just defined by the local compiler to map
    to its supported floating point formats. For byte addressable machines,
    that meant that your suggested mapping would be correct. But there are
    also 36-bit, 60-bit, and 64-bit machines that cannot conform to those
    mappings, so they must do something different. In the f77 time in the
    1980s, I used those declarations extensively for exactly that reason, it
    was a way, with some care, to write portable (but nonstandard) code. I
    used REAL*8 declarations to run on machines with all of those word
    lengths. It wasn't pretty, but it served its purpose at the time.

    But now we have the fortran KIND system, which handles all of that much
    better. Yes, when you incorporate old f66 and f77 code into your current project, you need to edit in those changes, but that is not a big deal.
    Your minimal efforts are rewarded with clarity and portability. I have
    programs with hundreds of thousands of lines where I can change the
    precision globally by modifying a single line of code in a module. From
    the programmer's perspective, that is hard to beat.

    Numerical analysts are now experimenting with 16-bit real arithmetic to
    speed up critical parts of algorithms. If/when they get that working,
    the fortran KIND system is already set up to handle that. IEEE decimal arithmetic is another feature raising its head on the horizon. Again,
    the fortran KIND system is already there and waiting. 10-byte arithmetic
    is another example (although some compilers are currently doing this the
    wrong way, I think). 128-bit arithmetic and beyond, both reals and
    integers, are all handled perfectly well with the fortran KIND system.

    If a compiler supports real types with those numbers of bits (real32,
    real64, etc.), then the kind values are set appropriately. If there is
    more than one kind with that many bits, then the processor chooses which
    one to return. If the processor does not support a kind with exactly
    those bits, then the processor sets the value to either -1 or -2. The -2
    value means that some kind is available with higher precision. This
    might not be the best way to write portable code, but if you want to
    write code targeted to specific floating point formats, that is a
    reasonable way to do it. The IEEE intrinsic module goes even further if
    code is intended to target that floating point format, rounding modes,
    NaN, subnormals, etc., all available within the fortran KIND system.
    This is all in contrast to REAL*4, REAL*8, etc, which are mapped in a
    very loose manner to the underlying supported floating point formats.

    I think the fortran KIND system is well thought out and it works well in practice. An improvement might be to eliminate shared KIND values
    between different types -- that is a sometimes subtle source of code
    errors. Another improvement might be the ability to write generic
    subprograms that automatically accommodate all supported KINDs of arguments.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Collins@21:1/5 to Beliavsky on Sat Apr 9 11:11:42 2022
    On Saturday, April 9, 2022 at 3:37:41 PM UTC+1, Beliavsky wrote:
    On Saturday, April 9, 2022 at 10:05:29 AM UTC-4, Beliavsky wrote:
    Since compilers treat the non-standard but very common

    real*4, real*8, integer*4, integer*8

    as

    use iso_fortran_env
    real(kind=real32), real(kind=real64), integer(kind=int32), integer(kind=int64)

    would it make sense to standardize the former set of declarations, which is concise and clear, to mean the same as the latter?
    Currently, if someone inherits a code with real*8 and decides to make it standard-conforming, they may replace it with
    real(kind=8), which is not guaranteed to work (failing with the NAG compiler for example). By standardizing real*8 appropriately this error is avoided.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Collins@21:1/5 to All on Sat Apr 9 11:32:49 2022

    There are many deprecated features that it would be very easy to write
    a program to convert to non-deprecated form. As far as I know, that hasn't been done. (And in both free and fixed form.)

    I do find it interesting that the Fortran II PRINT statement, after not making
    it into Fortran 66, later was included in the standard. Including REAL*8 makes
    about as much sense.

    We have tried to convert a large number of legacy constructs to standard form in fpt (http://simconglobal.com). This includes changing REAL*n to the appropriate kind (Or back again for migration projects where you need to retest on the original host :-)
    ).

    Changing REAL*n, INTEGER*n etc. was easy but some of the conversions were NOT "very easy to write".

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to john.c...@simconglobal.com on Sat Apr 9 11:40:44 2022
    On Saturday, April 9, 2022 at 2:19:23 PM UTC-4, john.c...@simconglobal.com wrote:

    ..
    I am in favour of making this standard ..
    The KIND specifications are clear and unambiguous, but in small test programs they can take up a significant proportion of the entire text.

    Should the standard do anything now, a better option will be to simply provide built-in i.e., ALIASes toward type-and-kind equivalent to certain standard floating point formats, say IEEE binary (and perhaps decimal) formats.

    For the foreseeable future, the powers-that-be in the industry and research and engineering areas I know only expect to use IEEE binary 64-bit floating point in >99% of computing.

    So what will be really useful is to have, say, IEEE_FPB64 as an alias for real(KIND=xx) where xx is IEEE_SELECTED_REAL_KIND( p=, r=, radix=..) corresponding to 64-bit IEEE binary floating point format.

    One should then be able to do the following in any processor that provides support for IEEE_xxx features from Fortran 2003+ which is several of the modern Fortran compilers:

    ieee_fpb64 :: x

    One can combine that with proposal for kinds for literal constants.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Collins@21:1/5 to Beliavsky on Sat Apr 9 11:19:21 2022
    On Saturday, April 9, 2022 at 3:05:29 PM UTC+1, Beliavsky wrote:
    Since compilers treat the non-standard but very common

    real*4, real*8, integer*4, integer*8

    as

    use iso_fortran_env
    real(kind=real32), real(kind=real64), integer(kind=int32), integer(kind=int64)

    would it make sense to standardize the former set of declarations, which is concise and clear, to mean the same as the latter?

    I am in favour of making this standard, but I think it is academic. I know of no compilers in common use which do not support declarations in this format, and I doubt if any compiler writers would remove them for the sake of annoying some of their users.

    The KIND specifications are clear and unambiguous, but in small test programs they can take up a significant proportion of the entire text.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to gah4@u.washington.edu on Sat Apr 9 21:29:34 2022
    gah4 <gah4@u.washington.edu> schrieb:
    On Saturday, April 9, 2022 at 7:05:29 AM UTC-7, Beliavsky wrote:
    (snip)

    would it make sense to standardize the former set of declarations,
    which is concise and clear, to mean the same as the latter?

    One thing that I have long thought, is that it would be nice to include in the
    standard some things that aren't required of implementations, but indicate how to do something if it is included.

    (And more generally than this question.)

    In the past, this was complicated by machines with 60 or 64 bit words,
    that had a type of that length as default REAL, and then (as required by
    the standard) a longer type of DOUBLE PRECISION. Those machines are
    now out of favor.

    POWER has rather recently acquired IEEE quad precision, and
    gfortran will have aquired support for it in the upcoming
    release.

    Not as double precision, but as REAL(KIND=16).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From JCampbell@21:1/5 to Beliavsky on Sat Apr 9 22:35:23 2022
    On Sunday, April 10, 2022 at 12:05:29 AM UTC+10, Beliavsky wrote:
    Since compilers treat the non-standard but very common

    real*4, real*8, integer*4, integer*8

    as

    use iso_fortran_env
    real(kind=real32), real(kind=real64), integer(kind=int32), integer(kind=int64)

    would it make sense to standardize the former set of declarations, which is concise and clear, to mean the same as the latter?
    real*8 and real(kind=real64) both provide a clear documentation of precision. real(8) unfortunately, is not portable.

    real(dp) or real(kind=dp) is not clear, as you need to search for the definition of dp, often in a "remote" module.
    sp, dp, qp, wp, r4 or r8 are not standard abbreviations. They are not uncommon real variables in legacy codes.

    I use multiple compilers, which have different kind values. Real*8 works easily for me on all compilers I use, while real(kind=dp) has the problem of which compiler last compiled the module where DP was defined.
    One compiler has real_kinds of [ 1,2 ] and integer_kinds of [ 1,2,3,4 ]. Try using integers such as 123_4 and see what you get for the different compilers I use.

    When using real*8, there is always the danger of using a compiler that does not support this non-standard syntax. I think there are greater dangers out there at the moment!
    I have used new Fortran compilers that did not support the real*byte syntax. It has happened a few times and I always successfully lobbied for the compiler to be enhanced.
    Most new OS and compilers tend to want to help established users.

    IEEE documents also use REAL*8 syntax.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to gah4@u.washington.edu on Sun Apr 10 07:59:24 2022
    gah4 <gah4@u.washington.edu> schrieb:
    On Saturday, April 9, 2022 at 2:29:37 PM UTC-7, Thomas Koenig wrote:
    gah4 <ga...@u.washington.edu> schrieb:
    On Saturday, April 9, 2022 at 7:05:29 AM UTC-7, Beliavsky wrote:

    (snip)

    In the past, this was complicated by machines with 60 or 64 bit words,
    that had a type of that length as default REAL, and then (as required by >> > the standard) a longer type of DOUBLE PRECISION. Those machines are
    now out of favor.

    POWER has rather recently acquired IEEE quad precision, and
    gfortran will have aquired support for it in the upcoming
    release.

    It was the word addressed 60 and 64 bit machines that didn't have
    a smaller floating point type. IBM had REAL*16 and COMPLEX*32
    since the 360/85 and standard on all S/370 and later models.

    I am surprised it took this long to get to POWER.

    IIRC, the REAL*16 types were implemented as two doubles. POWER also
    had that (but as a pair of IEEE doubles), and a true headache it
    is proving to get rid of that in compiler support.

    VAX Fortran also supports REAL*16 and COMPLEX*32, though
    software emulated on many machines. That was from close
    to the beginning of VAX. (A microcode option on most,
    it was standard on the low end 11/730.)

    You will also find it as KIND=16 on gfortran, implemented
    in software as well (libquadmath).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Thomas Koenig on Sun Apr 10 00:34:40 2022
    On Saturday, April 9, 2022 at 2:29:37 PM UTC-7, Thomas Koenig wrote:
    gah4 <ga...@u.washington.edu> schrieb:
    On Saturday, April 9, 2022 at 7:05:29 AM UTC-7, Beliavsky wrote:

    (snip)

    In the past, this was complicated by machines with 60 or 64 bit words,
    that had a type of that length as default REAL, and then (as required by the standard) a longer type of DOUBLE PRECISION. Those machines are
    now out of favor.

    POWER has rather recently acquired IEEE quad precision, and
    gfortran will have aquired support for it in the upcoming
    release.

    It was the word addressed 60 and 64 bit machines that didn't have
    a smaller floating point type. IBM had REAL*16 and COMPLEX*32
    since the 360/85 and standard on all S/370 and later models.

    I am surprised it took this long to get to POWER.

    VAX Fortran also supports REAL*16 and COMPLEX*32, though
    software emulated on many machines. That was from close
    to the beginning of VAX. (A microcode option on most,
    it was standard on the low end 11/730.)

    Not as double precision, but as REAL(KIND=16).

    As long as it supports a 32 bit, more or less, type, that isn't
    a problem. But the Fortran standard requires, or at least used to,
    a double precision twice (more or less) single precision.

    But as I noted, for the IEEE 754-2008 decimal float types,
    the basic types are 64 and 128 bit.

    A Fortran compiler implementing only those, would call them single
    and double precision. I believe the later POWER machines support those,
    in addition to the binary forms. I would be surprised if someone wrote
    a Fortran compiler for POWER supporting only the decimal types.

    Note, though, that the DEC compilers for the 36 bit PDP-10
    recognize REAL*8 for the 72 bit double precision. I am not sure
    about the CDC and Cray compilers. It isn't required that the *8
    represent 8 bytes of any specific size. (The PDP-10 byte
    instructions work on bytes from 1 to 36 bits. C compilers
    tend to use 9 bits for char. C requires char to be an integer
    fraction of the word (int) size.)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Beliavsky on Sun Apr 10 00:46:33 2022
    On Saturday, April 9, 2022 at 9:46:13 AM UTC-7, Beliavsky wrote:
    On Saturday, April 9, 2022 at 12:16:46 PM UTC-4, gah4 wrote:
    As far as I know, REAL(8) is more popular, and equally standard and non-portable.

    (snip)

    REAL(KIND(1D0))

    would be standard, and reliably give a double precision type, though takes more characters to type.

    It is nice to have something that can be replaced, line by line, without the
    need for any other lines to be included. (Well, assuming appropriate continuation rules.)

    If someone declares variables as real*8 they are saying that 8-byte reals are sufficient.
    You could have a platform where singe precision is real(kind=real64) and double
    precision is real(kind=real128). In that case the natural equivalent of real*8 would be
    real(kind=real128) and not real(kind=kind(1.0d0)).

    The Cray-1 series are word addressed 64 bit machines, with a 64 bit
    floating point type. I believe Fortran supports a software emulated 128
    bit type, as required by the standard. But all the Cray machines are, as far
    as I know, in museums. (There used to be a machine that would one on
    one day a week, as that was how much power they could afford.)

    I don't know about Cray support for REAL*8 syntax.

    I do remember Fortran programs with a series of declarations and
    DATA statements at the beginning, where you uncomment the ones
    for the system you are using. That was for the different word size,
    and also other constants that varied between machines.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to JCampbell on Sun Apr 10 07:44:56 2022
    JCampbell <campbelljohnd01@gmail.com> schrieb:

    real(dp) or real(kind=dp) is not clear, as you need to search for the definition of dp, often in a "remote" module.
    sp, dp, qp, wp, r4 or r8 are not standard abbreviations. They are not uncommon real variables in legacy codes.

    They are what I usually use. In most of my projects, I have a small
    module

    module prec
    implicit none
    integer, parameter :: sp = selected_real_kind(6)
    integer, parameter :: dp = selected_real_kind(15)
    integer, parameter :: qp = selected_real_kind(30)
    end module prec

    I use multiple compilers, which have different kind values. Real*8 works easily for me on all compilers I use, while real(kind=dp) has the problem of which compiler last compiled the module where DP was defined.

    Modules and object code are only valid for one compiler. If you
    mix them, you're in for bigger trouble than that.

    One compiler has real_kinds of [ 1,2 ] and integer_kinds of [ 1,2,3,4 ]. Try using integers such as 123_4 and see what you get for the different compilers I use.

    nagfor, I presume, although they have the -kind=byte option to
    match what others are doing (market pressure, I presume).

    I actually like the -kind=unique version best, no possiblity
    of mixing up any of the kind numbers.

    When using real*8, there is always the danger of using a compiler
    that does not support this non-standard syntax. I think there
    are greater dangers out there at the moment! I have used new
    Fortran compilers that did not support the real*byte syntax. It
    has happened a few times and I always successfully lobbied for
    the compiler to be enhanced. Most new OS and compilers tend to
    want to help established users.

    That is correct. I still find the difference between REAL*8
    and COMPLEX*8 a source of confusion, though.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dick Hendrickson@21:1/5 to All on Sun Apr 10 11:01:12 2022
    On 4/10/22 2:46 AM, gah4 wrote:
    On Saturday, April 9, 2022 at 9:46:13 AM UTC-7, Beliavsky wrote:
    On Saturday, April 9, 2022 at 12:16:46 PM UTC-4, gah4 wrote:
    As far as I know, REAL(8) is more popular, and equally standard and
    non-portable.

    (snip)

    REAL(KIND(1D0))

    would be standard, and reliably give a double precision type, though takes >>> more characters to type.

    It is nice to have something that can be replaced, line by line, without the
    need for any other lines to be included. (Well, assuming appropriate
    continuation rules.)

    If someone declares variables as real*8 they are saying that 8-byte reals are sufficient.
    You could have a platform where singe precision is real(kind=real64) and double
    precision is real(kind=real128). In that case the natural equivalent of real*8 would be
    real(kind=real128) and not real(kind=kind(1.0d0)).

    The Cray-1 series are word addressed 64 bit machines, with a 64 bit
    floating point type. I believe Fortran supports a software emulated 128
    bit type, as required by the standard. But all the Cray machines are, as far as I know, in museums. (There used to be a machine that would one on
    one day a week, as that was how much power they could afford.)

    I don't know about Cray support for REAL*8 syntax.

    Cray supported both real*4 and real*8 syntax. The syntax was easy, the
    hard part was deciding what it meant. As you said, there was no
    support for a 32 bit real; real*4 declared a 64 bit variable. The
    hardware supported 64 bit real and software emulation did the 128 bit
    real. The problem was most people used real*8 because 64 bits was
    enough, not that they needed "double precision". Promoting real*8 to
    twice the size of a real*4 wasn't what they wanted for performance.
    Ultimately, we gave them a control card option to effectively treat
    real*4 and real*8 as identical. Fortunately, the standard let us do that.

    Dick Hendrickson

    PS: there was one syntax issue. Things like REAL*4 HENRY initially
    gave the parser fits.


    I do remember Fortran programs with a series of declarations and
    DATA statements at the beginning, where you uncomment the ones
    for the system you are using. That was for the different word size,
    and also other constants that varied between machines.




    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Thomas Koenig on Sun Apr 10 09:16:00 2022
    On Sunday, April 10, 2022 at 12:59:28 AM UTC-7, Thomas Koenig wrote:
    gah4 <ga...@u.washington.edu> schrieb:

    (snip)

    It was the word addressed 60 and 64 bit machines that didn't have
    a smaller floating point type. IBM had REAL*16 and COMPLEX*32
    since the 360/85 and standard on all S/370 and later models.

    I am surprised it took this long to get to POWER.

    IIRC, the REAL*16 types were implemented as two doubles. POWER also
    had that (but as a pair of IEEE doubles), and a true headache it
    is proving to get rid of that in compiler support.

    The IBM HFP 16 byte type has the form of two of the usual 8 byte type.
    Base 16 like the others, with a 7 bit exponent. That is the form that the 360/85 implemented, and was carried on through S/370 and ESA/390.

    When IBM did it, they implemented DXR, extended precision divide,
    only in software emulation. Statistics said that it wasn't used all that
    much, such that it wasn't worth doing in hardware. The "two doubles"
    format makes the software emulation a little easier, and 112 bits
    is enough.

    They also wrote the emulation software for other S/360 models,
    again the format makes it easier. My first hand disassembly of
    a whole program was those emulators. (After I figured out
    how to extract hex dumps from load module libraries.
    Sometime in high school years, if you are counting.)

    Also, the 16 byte values are stored in a pair of floating
    point registers. S/360 only has four such registers, so
    only two pairs. Later, ESA/390 added more registers.

    Also, late in the ESA/390 years, so maybe 1995 or so, they finally
    added DXR to hardware. Maybe about the time that IEEE binary
    floating point was added, including a 16 byte form.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to Thomas Koenig on Sun Apr 10 12:48:10 2022
    On 4/10/22 2:44 AM, Thomas Koenig wrote:
    real(dp) or real(kind=dp) is not clear, as you need to search for the definition of dp, often in a "remote" module.
    sp, dp, qp, wp, r4 or r8 are not standard abbreviations. They are not uncommon real variables in legacy codes.
    They are what I usually use. In most of my projects, I have a small
    module

    module prec
    implicit none
    integer, parameter :: sp = selected_real_kind(6)
    integer, parameter :: dp = selected_real_kind(15)
    integer, parameter :: qp = selected_real_kind(30)
    end module prec

    Just to include this possibility into the mix, there is also

    real*8, private :: temp
    integer, parameter :: wp=kind(temp)

    The rest of the code should use the "wp" parameter of course, in
    declarations and in literal constants, but in that one module, it isn't
    so bad to use real*8 in that one place. Once it is localized like this,
    it isn't even so bad to hardwire the kind number.

    integer, parameter :: wp=8

    The big porting problems arise when the "8" is scattered throughout the
    source code.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to All on Sun Apr 10 12:30:35 2022
    On 4/10/22 2:34 AM, gah4 wrote:
    Note, though, that the DEC compilers for the 36 bit PDP-10
    recognize REAL*8 for the 72 bit double precision. I am not sure
    about the CDC and Cray compilers. It isn't required that the *8
    represent 8 bytes of any specific size. (The PDP-10 byte
    instructions work on bytes from 1 to 36 bits. C compilers
    tend to use 9 bits for char. C requires char to be an integer
    fraction of the word (int) size.)

    I remember using these machines in the late 1970s. My memory might be
    off, but I remember being able to use REAL*4 (mapped to 36-bit single precision) and REAL*8 (mapped to 72-bit double precision). This was
    before the CHARACTER type was available, but Hollerith characters could
    be stored in integer, real, double precision, or logical variables, or
    even used in literal constants pretty freely. They were 7-bit ascii
    characters, up to 5 per word (so one bit per word could be used by the programmer for something else, if necessary). I never used an f77
    compiler on those machines, but I think they did exist later on. I never
    used C on those machines, so I do not know about its 9-bit characters,
    but that would have been incompatible with both the fortran convention
    and with all of the other uses of characters in the operating system
    (file names, interactive shells, text editors, etc.).

    I think gfortan even now has options that treat real*8 declarations as
    single precision and real*16 as double precision. I don't use these, but
    I think integer and logical kinds are all promoted too, so everything
    works the way it should according to the standard storage sequence requirements. There are, of course, incompatibilities with external
    libraries such as BLAS and LAPACK that, in their naming convention,
    continue to treat 4-byte integers and reals as single precision.

    I also remember when CRAY started using byte-addressable CPUs (i.e. MIPS
    and AMD chips). They tried to include options that would facilitate
    porting from their earlier 64-bit word machines, but it was easy to make mistakes with, for example, integer and real storage sequence
    associations in common blocks.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jfh@21:1/5 to Thomas Koenig on Sun Apr 10 15:43:37 2022
    On Sunday, April 10, 2022 at 7:44:59 PM UTC+12, Thomas Koenig wrote:
    JCampbell <campbel...@gmail.com> schrieb:
    real(dp) or real(kind=dp) is not clear, as you need to search for the definition of dp, often in a "remote" module.
    sp, dp, qp, wp, r4 or r8 are not standard abbreviations. They are not uncommon real variables in legacy codes.
    They are what I usually use. In most of my projects, I have a small
    module

    module prec
    implicit none
    integer, parameter :: sp = selected_real_kind(6)
    integer, parameter :: dp = selected_real_kind(15)
    integer, parameter :: qp = selected_real_kind(30)
    end module prec
    I use multiple compilers, which have different kind values. Real*8 works easily for me on all compilers I use, while real(kind=dp) has the problem of which compiler last compiled the module where DP was defined.

    In one of my projects where I test programs with lower precision to save run time but finish up using the highest I use a little module like this:

    module myprec
    integer, parameter :: prec(4) = [6,15,18,33]
    integer, parameter :: wp = selected_real_kind(prec(2))
    end module myprec

    when I want what gfortran and ifort call double precision. Changing the desired precision requires changing only the 2 into 1, 3 or 4, and no change is needed in a program that uses that module.

    That works well with gfortran but when compiling with ifort I must remember that asking for prec(3) is the same as asking for prec(4).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From JCampbell@21:1/5 to jfh on Sun Apr 10 21:38:36 2022
    On Monday, April 11, 2022 at 8:43:39 AM UTC+10, jfh wrote:
    On Sunday, April 10, 2022 at 7:44:59 PM UTC+12, Thomas Koenig wrote:
    JCampbell <campbel...@gmail.com> schrieb:
    real(dp) or real(kind=dp) is not clear, as you need to search for the definition of dp, often in a "remote" module.
    sp, dp, qp, wp, r4 or r8 are not standard abbreviations. They are not uncommon real variables in legacy codes.
    They are what I usually use. In most of my projects, I have a small
    module

    module prec
    implicit none
    integer, parameter :: sp = selected_real_kind(6)
    integer, parameter :: dp = selected_real_kind(15)
    integer, parameter :: qp = selected_real_kind(30)
    end module prec
    I use multiple compilers, which have different kind values. Real*8 works easily for me on all compilers I use, while real(kind=dp) has the problem of which compiler last compiled the module where DP was defined.
    In one of my projects where I test programs with lower precision to save run time but finish up using the highest I use a little module like this:

    module myprec
    integer, parameter :: prec(4) = [6,15,18,33]
    integer, parameter :: wp = selected_real_kind(prec(2))
    end module myprec

    when I want what gfortran and ifort call double precision. Changing the desired precision requires changing only the 2 into 1, 3 or 4, and no change is needed in a program that uses that module.

    That works well with gfortran but when compiling with ifort I must remember that asking for prec(3) is the same as asking for prec(4).
    I am not sure I would agree that real*10 works well with gfortran, especially considering the memory storage approach.
    I do miss the precision of 8087 real*10, especially for loop accumulators, but the improved performance of real*8 SIMD : MMX, SSE and AVX is a must.
    I have felt cheated by the alignment issues with SSE and AVX, which should have always been solved by the hardware and not left for programmers to try and fix with messy memory address calculations.
    Rather than 8, 16 or 32 byte compiler alignment options for arrays, why is there not a 4096 byte (memory page) alignment, which "might" be useful for multi-threading for heap ALLOCATE arrays ?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Ron Shepard on Mon Apr 11 01:48:21 2022
    On Monday, April 11, 2022 at 3:48:14 AM UTC+10, Ron Shepard wrote:
    On 4/10/22 2:44 AM, Thomas Koenig wrote:
    real(dp) or real(kind=dp) is not clear, as you need to search for the definition of dp, often in a "remote" module.
    sp, dp, qp, wp, r4 or r8 are not standard abbreviations. They are not uncommon real variables in legacy codes.
    They are what I usually use. In most of my projects, I have a small
    module

    module prec
    implicit none
    integer, parameter :: sp = selected_real_kind(6)
    integer, parameter :: dp = selected_real_kind(15)
    integer, parameter :: qp = selected_real_kind(30)
    end module prec
    Just to include this possibility into the mix, there is also

    real*8, private :: temp
    .
    It REALly isn't standard, is it !!
    .
    integer, parameter :: wp=kind(temp)

    The rest of the code should use the "wp" parameter of course, in
    declarations and in literal constants, but in that one module, it isn't
    so bad to use real*8 in that one place. Once it is localized like this,
    it isn't even so bad to hardwire the kind number.

    integer, parameter :: wp=8

    The big porting problems arise when the "8" is scattered throughout the source code.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to FortranFan on Mon Apr 11 02:07:45 2022
    On Sunday, April 10, 2022 at 4:40:46 AM UTC+10, FortranFan wrote:
    On Saturday, April 9, 2022 at 2:19:23 PM UTC-4, john.c...@simconglobal.com wrote:

    ..
    I am in favour of making this standard ..
    The KIND specifications are clear and unambiguous, but in small test programs they can take up a significant proportion of the entire text.
    Should the standard do anything now, a better option will be to simply provide built-in i.e., ALIASes toward type-and-kind equivalent to certain standard floating point formats, say IEEE binary (and perhaps decimal) formats.

    For the foreseeable future, the powers-that-be in the industry and research and engineering areas I know only expect to use IEEE binary 64-bit floating point in >99% of computing.

    So what will be really useful is to have, say, IEEE_FPB64 as an alias for real(KIND=xx) where xx is IEEE_SELECTED_REAL_KIND( p=, r=, radix=..) corresponding to 64-bit IEEE binary floating point format.

    One should then be able to do the following in any processor that provides support for IEEE_xxx features from Fortran 2003+ which is several of the modern Fortran compilers:

    ieee_fpb64 :: x
    .
    Can we not write in English? REAL (KIND=DP) :: x
    .
    One can combine that with proposal for kinds for literal constants.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to john.c...@simconglobal.com on Mon Apr 11 02:00:23 2022
    On Sunday, April 10, 2022 at 4:19:23 AM UTC+10, john.c...@simconglobal.com wrote:
    On Saturday, April 9, 2022 at 3:05:29 PM UTC+1, Beliavsky wrote:
    Since compilers treat the non-standard but very common

    real*4, real*8, integer*4, integer*8

    as

    use iso_fortran_env
    real(kind=real32), real(kind=real64), integer(kind=int32), integer(kind=int64)

    would it make sense to standardize the former set of declarations, which is concise and clear, to mean the same as the latter?
    I am in favour of making this standard, but I think it is academic. I know of no compilers in common use which do not support declarations in this format, and I doubt if any compiler writers would remove them for the sake of annoying some of their
    users.

    The KIND specifications are clear and unambiguous, but in small test programs they can take up a significant proportion of the entire text.
    .
    In small test programs, REAL and DOUBLE PRECISION are clear,
    and can be written quickly.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Ron Shepard on Mon Apr 11 02:03:01 2022
    On Sunday, April 10, 2022 at 3:15:45 AM UTC+10, Ron Shepard wrote:
    On 4/9/22 9:05 AM, Beliavsky wrote:
    Since compilers treat the non-standard but very common

    real*4, real*8, integer*4, integer*8

    as

    use iso_fortran_env
    real(kind=real32), real(kind=real64), integer(kind=int32), integer(kind=int64)

    would it make sense to standardize the former set of declarations, which is concise and clear, to mean the same as the latter?
    In my opinion, this would be a step backward for the language.

    There are many reasons why this should not be done, but one of them is
    that REAL*4 etc. were always just defined by the local compiler to map
    to its supported floating point formats. For byte addressable machines,
    that meant that your suggested mapping would be correct. But there are
    also 36-bit, 60-bit, and 64-bit machines that cannot conform to those mappings, so they must do something different. In the f77 time in the
    1980s, I used those declarations extensively for exactly that reason, it
    was a way, with some care, to write portable (but nonstandard) code. I
    used REAL*8 declarations to run on machines with all of those word
    lengths. It wasn't pretty, but it served its purpose at the time.

    But now we have the fortran KIND system, which handles all of that much better. Yes, when you incorporate old f66 and f77 code into your current project, you need to edit in those changes, but that is not a big deal.
    Your minimal efforts are rewarded with clarity and portability. I have programs with hundreds of thousands of lines where I can change the
    precision globally by modifying a single line of code in a module. From
    the programmer's perspective, that is hard to beat.
    .
    Indeed !!!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to JCampbell on Mon Apr 11 02:21:31 2022
    On Sunday, April 10, 2022 at 3:35:25 PM UTC+10, JCampbell wrote:
    On Sunday, April 10, 2022 at 12:05:29 AM UTC+10, Beliavsky wrote:
    Since compilers treat the non-standard but very common

    real*4, real*8, integer*4, integer*8

    as

    use iso_fortran_env
    real(kind=real32), real(kind=real64), integer(kind=int32), integer(kind=int64)

    would it make sense to standardize the former set of declarations, which is concise and clear, to mean the same as the latter?
    real*8 and real(kind=real64) both provide a clear documentation of precision. real(8) unfortunately, is not portable.
    .
    and real*8 is not standard.
    .
    real(dp) or real(kind=dp) is not clear,
    .
    in what way? "dp" is used often enough that it is immediately clear
    that it signifies double precision.
    .
    as you need to search for the definition of dp,
    .
    Really?
    The purpose of using such "words" as 'dp' and 'wp' in your
    programs makes it clear what the words mean.
    .
    often in a "remote" module.
    sp, dp, qp, wp, r4 or r8 are not standard abbreviations. They are not uncommon real variables in legacy codes.
    .
    Can't say I have seen these in any old codes.
    .
    I use multiple compilers, which have different kind values. Real*8 works easily for me on all compilers I use,
    .
    So does DOUBLE PRECISION, which is STANDARD.
    .
    while real(kind=dp) has the problem of which compiler last compiled the module where DP was defined.
    One compiler has real_kinds of [ 1,2 ] and integer_kinds of [ 1,2,3,4 ]. Try using integers such as 123_4 and see what you get for the different compilers I use.
    .
    Don't use such silly suffixes.
    .
    When using real*8, there is always the danger of using a compiler that does not support this non-standard syntax. I think there are greater dangers out there at the moment!
    I have used new Fortran compilers that did not support the real*byte syntax. It has happened a few times and I always successfully lobbied for the compiler to be enhanced.
    .
    "enhanced"? you mean, down-graded.
    .
    Most new OS and compilers tend to want to help established users.

    IEEE documents also use REAL*8 syntax.
    .
    So what?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From steve kargl@21:1/5 to JCampbell on Mon Apr 11 16:05:46 2022
    JCampbell wrote:

    I am not sure I would agree that real*10 works well with gfortran, especially considering the memory storage approach.

    Can you elaborate?

    gfortran's real(10) on x86_64 class hardware is Intel 80-bit
    extended double precision.

    --
    steve

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to steve kargl on Mon Apr 11 19:45:16 2022
    On 4/11/22 11:05 AM, steve kargl wrote:
    JCampbell wrote:

    I am not sure I would agree that real*10 works well with gfortran, especially considering the memory storage approach.

    Can you elaborate?

    gfortran's real(10) on x86_64 class hardware is Intel 80-bit
    extended double precision.

    I think the problem people have is that it is stored in 16 bytes, so
    there is a lot of wasted memory and/or file space.

    I'm glad the option is there, for example for accumulating sums with
    extended precision, but its overall usefulness is limited because of
    those wasted 48-bits per value. Programmers instead are likely just to
    use the 128-bit floating point kind which takes up the same memory/file
    space. And it is nice to have the 128-bit kind supported too.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From steve kargl@21:1/5 to Ron Shepard on Tue Apr 12 16:17:20 2022
    Ron Shepard wrote:

    On 4/11/22 11:05 AM, steve kargl wrote:
    JCampbell wrote:

    I am not sure I would agree that real*10 works well with gfortran, especially considering the memory storage approach.

    Can you elaborate?

    gfortran's real(10) on x86_64 class hardware is Intel 80-bit
    extended double precision.

    I think the problem people have is that it is stored in 16 bytes, so
    there is a lot of wasted memory and/or file space.

    I'm glad the option is there, for example for accumulating sums with
    extended precision, but its overall usefulness is limited because of
    those wasted 48-bits per value. Programmers instead are likely just to
    use the 128-bit floating point kind which takes up the same memory/file space. And it is nice to have the 128-bit kind supported too.

    Then those people are blaming the wrong thing. Intel choose 4, 8, and 16-byte alignment in their ABIs. gfortran (and gcc) are just a tool sitting above the cpu.

    --
    steve

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Collins@21:1/5 to Robin Vowels on Tue Apr 12 11:04:19 2022
    On Monday, April 11, 2022 at 10:21:33 AM UTC+1, Robin Vowels wrote:
    <snip>> .
    So does DOUBLE PRECISION, which is STANDARD.
    .

    I'm not sure that it is, or at least, not in a helpful way. A system with a default 64-bit real number might interpret DOUBLE PRECISION as 128-bit.

    I agree that standardising REAL*8 would inject a fossil into the language. Perhaps a way forward is to define a new class of PARAMETER for types and kinds, e.g.

    PARAMETER,KIND :: REAL_8 = REAL,KIND=KIND(1.0D0)

    Then REAL_8 could only be used in a kind specification and would always mean the same thing. This would avoid an error which we found recently in an important code where the user had written an expression of the form:

    REAL(dp),PARAMETER :: kappa = 68431_dp

    dp was (as a result of SELECTED_REAL_KIND) equal to 8 so the integer was defined as 64-bits and no error occurred on the original ifort compiler. What NAG or FTN95 would have done with it I don't want to know. We don't (yet) know how many more of these
    are likely to turn up. The compiler could issue an error if a parameterised KIND were used as a tag for an integer literal.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to john.c...@simconglobal.com on Tue Apr 12 11:23:30 2022
    On Tuesday, April 12, 2022 at 11:04:21 AM UTC-7, john.c...@simconglobal.com wrote:

    (snip)

    I agree that standardising REAL*8 would inject a fossil into the language. Perhaps a way forward is to define a new class of PARAMETER for types and kinds, e.g.

    PARAMETER,KIND :: REAL_8 = REAL,KIND=KIND(1.0D0)

    Then REAL_8 could only be used in a kind specification and would always mean the same thing.
    This would avoid an error which we found recently in an important code where the user had written an expression of the form:

    REAL(dp),PARAMETER :: kappa = 68431_dp

    The KIND values could have been required to be different for different
    types, though they are required to be the same for a REAL type and the
    twice as big COMPLEX type.

    (IBM and DEC call the double precision complex type REAL*16.)

    dp was (as a result of SELECTED_REAL_KIND) equal to 8 so the integer
    was defined as 64-bits and no error occurred on the original ifort compiler.

    What NAG or FTN95 would have done with it I don't want to know.
    We don't (yet) know how many more of these are likely to turn up.
    The compiler could issue an error if a parameterised KIND were used as a tag for an integer literal.

    As well as I know the standard, the KIND values are just integers.

    The standard doesn't care much where you get your KIND values,
    as long as the one you come up with is supported.

    REAL(dp),PARAMETER :: kappa = 68431_dp

    is legal, standard, but not portable.

    I suspect one could claim that reusing KIND values between INTEGER and
    REAL kinds is a quality of implementation issue, and that a high quality implementation would not do that. Start sending in bug reports!

    The original subject here is the non-standard REAL*8, but there is the standard, non-portable, and way too common REAL(8).

    There is no suggestion in the standard that REAL(8) exists,
    and even less that it is an 8 byte or 64 bit type.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From steve kargl@21:1/5 to John Collins on Tue Apr 12 19:52:44 2022
    John Collins wrote:

    On Monday, April 11, 2022 at 10:21:33 AM UTC+1, Robin Vowels wrote:
    <snip>> .
    So does DOUBLE PRECISION, which is STANDARD.
    .

    I'm not sure that it is, or at least, not in a helpful way. A system with a default 64-bit real number might interpret DOUBLE PRECISION as 128-bit.


    DOUBLE PRECISION is defined by the standard. An entity with
    default REAL kind type occupies one numeric storage unit.
    An entity with DOUBLE PRECISION type occupies two numeric
    storage units. If one numeric storage unit is 64 bits, then
    two would use 128 bits.

    --
    steve

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phillip Helbig (undress to reply@21:1/5 to sgk@REMOVEtroutmask.apl.washington. on Tue Apr 12 20:06:23 2022
    In article <t34lac$utb$1@dont-email.me>, steve kargl <sgk@REMOVEtroutmask.apl.washington.edu> writes:

    John Collins wrote:

    On Monday, April 11, 2022 at 10:21:33 AM UTC+1, Robin Vowels wrote:
    <snip>> .
    So does DOUBLE PRECISION, which is STANDARD.
    .

    I'm not sure that it is, or at least, not in a helpful way. A system with a default 64-bit real number might interpret DOUBLE PRECISION as 128-bit.


    DOUBLE PRECISION is defined by the standard. An entity with
    default REAL kind type occupies one numeric storage unit.
    An entity with DOUBLE PRECISION type occupies two numeric
    storage units. If one numeric storage unit is 64 bits, then
    two would use 128 bits.

    Right. DOUBLE is really double the size, since the actual precision,
    however it is measured, can vary, and is usually not double.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to steve kargl on Tue Apr 12 13:40:35 2022
    On Tuesday, April 12, 2022 at 12:52:47 PM UTC-7, steve kargl wrote:

    (snip)

    DOUBLE PRECISION is defined by the standard. An entity with
    default REAL kind type occupies one numeric storage unit.
    An entity with DOUBLE PRECISION type occupies two numeric
    storage units. If one numeric storage unit is 64 bits, then
    two would use 128 bits.

    Yes, the word addressed Cray machines with 64 bit words, and CDC machines with 60 bit
    words, did not have a smaller type. So the Fortran required double precision had to
    be 128 bits, or 120 bits, respectively, and as well as I know, was done in software.

    As far as I know, all those are in museums, so we don't have to plan for them. Is there any thought that more such processor might be built?

    Otherwise, for the IEEE 754 decimal forms, the basic (IEEE 754 term) forms
    are the 64 bit and 128 bit forms. If there was interest in a Fortran compiler supporting them as its default types, such that default REAL would be 64 bits, then it would be useful, as above, to have a way to ask for this, without asking for a double precision type.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to All on Wed Apr 13 00:12:38 2022
    On 4/12/22 3:06 PM, Phillip Helbig (undress to reply) wrote:
    [...]
    Right. DOUBLE is really double the size, since the actual precision,
    however it is measured, can vary, and is usually not double.

    And sometimes the precision is more than double. Compare the 24-bit
    mantissas in single precision to the 53-bit mantissas in double
    precision. Those counts include the implicit hidden bit.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to All on Wed Apr 13 00:04:29 2022
    On 4/12/22 1:23 PM, gah4 wrote:
    The original subject here is the non-standard REAL*8, but there is the standard, non-portable, and way too common REAL(8).

    There are thousands of lines of compiler documentation that use REAL(8)
    because that is a concise way to describe how the compiler does things.
    When new programmers see that documentation, they will mimic it in their
    codes. This problem is not going away any time soon.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to john.c...@simconglobal.com on Tue Apr 12 23:05:40 2022
    On Wednesday, April 13, 2022 at 4:04:21 AM UTC+10, john.c...@simconglobal.com wrote:
    On Monday, April 11, 2022 at 10:21:33 AM UTC+1, Robin Vowels wrote:
    <snip>> .
    So does DOUBLE PRECISION, which is STANDARD.
    .
    I'm not sure that it is, or at least, not in a helpful way. A system with a default 64-bit real number might interpret DOUBLE PRECISION as 128-bit.
    .
    How many of those do you use?
    .
    I agree that standardising REAL*8 would inject a fossil into the language. Perhaps a way forward is to define a new class of PARAMETER for types and kinds, e.g.

    PARAMETER,KIND :: REAL_8 = REAL,KIND=KIND(1.0D0)

    Then REAL_8 could only be used in a kind specification and would always mean the same thing. This would avoid an error which we found recently in an important code where the user had written an expression of the form:

    REAL(dp),PARAMETER :: kappa = 68431_dp

    dp was (as a result of SELECTED_REAL_KIND) equal to 8 so the integer was defined as 64-bits and no error occurred on the original ifort compiler. What NAG or FTN95 would have done with it I don't want to know.
    .
    The design of the kind system in FORTRAN is flawed, and allows errors of this type to pass unnoticed.
    The way around it is to have a kind number that is unique for every available kind.
    Most manufacturers have circumvented this simple check and invented kind numbers
    according to the number of bytes typically employed for the relevant real or integer.
    Thus, compilers have the same kind number for both single-precision real [32-bit] and for
    a default [32-bit] integer, and so on.
    .
    In PL/I we can write DECLARE X FLOAT DECIMAL(15);
    and DECLARE Y FLOAT DECIMAL (6);
    and get the precision that we desire, so that even if a machine
    were available that offered only 64-bit reals, we would have
    it using hardware floats of 64-bits for variables X and Y.
    (Of course, the number of desired digits can be parameterised,
    just as in Fortran, so that it would be easy to change.)
    As well as the above, one can write DECLARE Z FLOAT BINARY (53);
    if it is desired to express the requirement in binary digits.
    ..
    We don't (yet) know how many more of these are likely to turn up.
    The compiler could issue an error if a parameterised KIND were used as a tag for an integer literal.
    .
    It could do it now had the compiler writer used unique integers for every kind. It doesn't need any language changes,.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to steve kargl on Tue Apr 12 23:13:03 2022
    On Wednesday, April 13, 2022 at 5:52:47 AM UTC+10, steve kargl wrote:
    John Collins wrote:

    On Monday, April 11, 2022 at 10:21:33 AM UTC+1, Robin Vowels wrote:
    <snip>> .
    So does DOUBLE PRECISION, which is STANDARD.
    .

    I'm not sure that it is, or at least, not in a helpful way. A system with a default 64-bit real number might interpret DOUBLE PRECISION as 128-bit.

    DOUBLE PRECISION is defined by the standard. An entity with
    default REAL kind type occupies one numeric storage unit.
    An entity with DOUBLE PRECISION type occupies two numeric
    storage units. If one numeric storage unit is 64 bits, then
    two would use 128 bits.
    .
    How many machines are you using that offer 64 bit words for single precision?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Ron Shepard on Tue Apr 12 23:09:15 2022
    On Wednesday, April 13, 2022 at 3:04:34 PM UTC+10, Ron Shepard wrote:
    On 4/12/22 1:23 PM, gah4 wrote:
    The original subject here is the non-standard REAL*8, but there is the standard, non-portable, and way too common REAL(8).
    There are thousands of lines of compiler documentation that use REAL(8) because that is a concise way to describe how the compiler does things.
    When new programmers see that documentation, they will mimic it in their codes. This problem is not going away any time soon.
    .
    How long would it take to write a program to read in a Fortran
    program and change REAL(8) to REAL(dp) ?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to steve kargl on Tue Apr 12 23:06:50 2022
    On Wednesday, April 13, 2022 at 5:52:47 AM UTC+10, steve kargl wrote:
    John Collins wrote:

    On Monday, April 11, 2022 at 10:21:33 AM UTC+1, Robin Vowels wrote:
    <snip>> .
    So does DOUBLE PRECISION, which is STANDARD.
    .

    I'm not sure that it is, or at least, not in a helpful way. A system with a default 64-bit real number might interpret DOUBLE PRECISION as 128-bit.

    DOUBLE PRECISION is defined by the standard. An entity with
    default REAL kind type occupies one numeric storage unit.
    An entity with DOUBLE PRECISION type occupies two numeric
    storage units. If one numeric storage unit is 64 bits, then
    two would use 128 bits.
    .
    How many machines are using that offer only 64 bit reals?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Robin Vowels on Wed Apr 13 00:44:12 2022
    On Tuesday, April 12, 2022 at 11:06:52 PM UTC-7, Robin Vowels wrote:

    (snip)

    How many machines are using that offer only 64 bit reals?

    Cray-1, Cray-1A, Cray-1S, Cray-1M, Cray-X-MP, Cray-Y-MP, Cray-2
    Cray-C90 Cray-EL90.

    How many of each did they make, so we can add them all up?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to All on Wed Apr 13 01:24:00 2022
    On Wednesday, April 13, 2022 at 5:44:14 PM UTC+10, gah4 wrote:
    On Tuesday, April 12, 2022 at 11:06:52 PM UTC-7, Robin Vowels wrote:

    (snip)
    How many machines are using that offer only 64 bit reals?
    .
    The word "you" was inadvertently omitted from the sentence.
    .
    Cray-1, Cray-1A, Cray-1S, Cray-1M, Cray-X-MP, Cray-Y-MP, Cray-2
    Cray-C90 Cray-EL90.

    How many of each did they make, so we can add them all up?
    .
    There is none in use. Any that still exist are museum pieces.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to All on Wed Apr 13 10:10:25 2022
    On 4/13/22 2:44 AM, gah4 wrote:
    On Tuesday, April 12, 2022 at 11:06:52 PM UTC-7, Robin Vowels wrote:

    (snip)

    How many machines are using that offer only 64 bit reals?

    Cray-1, Cray-1A, Cray-1S, Cray-1M, Cray-X-MP, Cray-Y-MP, Cray-2
    Cray-C90 Cray-EL90.

    I'm not sure exactly what this discussion is about, but fortran
    compilers on those computers also supported 128-bit reals. Double
    precision on those machines was slow, but it was there if you absolutely
    needed it.

    However, the FPS series of machines, which were also popular in the
    1980s, did not support 128-bit arithmetic at all. They only supported
    64-bit single precision floating point.

    How many of each did they make, so we can add them all up?

    These were not personal computers, so the measure is not how many of the computers were made, but rather how many programmers and users had
    access to them. In my field of computational chemistry, that would be essentially every active programmer. In the 1980s, one could gain access
    in a variety of ways, through government agencies like NSF, NIH, DoD, or
    DOE, through state computer access programs, through universities, or
    through private employers. Those machines cast a huge shadow in their time.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From steve kargl@21:1/5 to Robin Vowels on Wed Apr 13 15:46:36 2022
    Robin Vowels wrote:

    On Wednesday, April 13, 2022 at 5:52:47 AM UTC+10, steve kargl wrote:
    John Collins wrote:

    On Monday, April 11, 2022 at 10:21:33 AM UTC+1, Robin Vowels wrote:
    <snip>> .
    So does DOUBLE PRECISION, which is STANDARD.
    .

    I'm not sure that it is, or at least, not in a helpful way. A system with a default 64-bit real number might interpret DOUBLE PRECISION as 128-bit.

    DOUBLE PRECISION is defined by the standard. An entity with
    default REAL kind type occupies one numeric storage unit.
    An entity with DOUBLE PRECISION type occupies two numeric
    storage units. If one numeric storage unit is 64 bits, then
    two would use 128 bits.
    .
    How many machines are you using that offer 64 bit words for single precision?

    I can run any code that I have with a 64-bit default real on x86_64 hardware. The requirements in the Fortran standard do not place restrictions on the underlying hardware.

    % cat o.f90
    program o
    real a ! default real kind
    real*4 b ! nonstanard, but portable, declaration
    a = 0.1_4 ! initialization with kind type suffix
    b = 3. ! default real kind literal real constant
    print '(2I3,1X,G0)', storage_size(a), storage_size(b), a / b
    a = exp(1.)
    b = 4 * atan(1.)
    print '(2I3,1X,G0)', storage_size(a), storage_size(b), a / b
    end program

    % gfortran11 -o z o.f90 && ./z
    32 32 0.333333351E-1
    32 32 0.865255952
    % gfortran11 -o z o.f90 && ./z
    % gfortran11 -o z -fdefault-real-8 o.f90 && ./z
    64 32 0.33333333830038704E-1
    64 32 0.86525595535432454
    % gfortran11 -o z -freal-4-real-8 o.f90 && ./z
    64 64 0.33333333333333333E-1
    64 64 0.86525597943226507

    I'll let you ponder what's going on.

    --
    steve

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Collins@21:1/5 to Robin Vowels on Wed Apr 13 11:41:19 2022
    On Wednesday, April 13, 2022 at 7:09:17 AM UTC+1, Robin Vowels wrote:
    .
    How long would it take to write a program to read in a Fortran
    program and change REAL(8) to REAL(dp) ?

    If the original code didn't have odd space characters, continuation lines and comments in silly places very little time at all. But I think that an issue here is that dp must be defined somewhere, and the definition added to every routine. Inserting an
    INCLUDE file or USE statement into every Fortran sub-program is much more work than a 1-line sed script.

    We have done all this. But I think a simple, unambiguous declaration which didn't have any associated complexities would be useful. To that end REAL*8 is the best we have got, it works everywhere (at least that I know of) and doesn't need to be in the
    standard if everyone understands it.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to All on Wed Apr 13 15:33:45 2022
    On Wednesday, April 13, 2022 at 8:10:29 AM UTC-7, Ron Shepard wrote:

    (snip, I wrote)

    Cray-1, Cray-1A, Cray-1S, Cray-1M, Cray-X-MP, Cray-Y-MP, Cray-2
    Cray-C90 Cray-EL90.

    I'm not sure exactly what this discussion is about, but fortran
    compilers on those computers also supported 128-bit reals. Double
    precision on those machines was slow, but it was there if you absolutely needed it.

    In the 1970's (mostly CDC) and 1980's (CDC and Cray), porting
    programs was complicated if you wanted a 64 bit (more or less)
    data type. That is, single precision on some machines, double
    on others. (In addition, some other constants, sometimes many
    other constants, would change between machines.)

    One that I think I remember, from the card days, was cards for all
    the different possibilities, each with a C in column 80. You then
    reverse the card in the deck, so the C is in column 1, for those you
    don't want to use.

    In any case, REAL*8 suggests that you want about 64 bits,
    and maybe about 53 bits of significand, on any machine.

    It does not suggest that you want double precision on hardware
    with a 60 or 64 bit single precision.

    There are ways to do this within the standard, which take a lot
    of typing, and also ways that are non-standard.

    If you manage to USE the appropriate module, at the right time,
    there is REAL64 and C_DOUBLE.

    REAL(SELECTED_REAL_KIND(12))

    might be about right, but is a lot to write. It is difficult to do a simple string substitution without problems with continuations and such.

    REAL(8) is shorter, but the standard does not give specific
    KIND values, so one can't reliably expect any specific type,
    or even that such type exists.

    REAL*8 is easy to type, and does not suggest double precision on hardware
    with a longer single precision type.


    However, the FPS series of machines, which were also popular in the
    1980s, did not support 128-bit arithmetic at all. They only supported
    64-bit single precision floating point.

    Interesting. Since Fortran compilers were, as well as I know, not hosted
    on the FPS machine, they might avoid the standard requirement for
    a double precision type.

    As well as I know it, C does not require or suggest that (double)
    is twice the size, or otherwise more precision, than (float).
    Systems with a 64 bit (float) can also have a 64 bit (double).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to john.c...@simconglobal.com on Wed Apr 13 17:38:10 2022
    On Wednesday, April 13, 2022 at 11:41:22 AM UTC-7, john.c...@simconglobal.com wrote:
    On Wednesday, April 13, 2022 at 7:09:17 AM UTC+1, Robin Vowels wrote:

    How long would it take to write a program to read in a Fortran
    program and change REAL(8) to REAL(dp) ?

    If the original code didn't have odd space characters, continuation lines
    and comments in silly places very little time at all.
    But I think that an issue here is that dp must be defined somewhere,
    and the definition added to every routine. Inserting an INCLUDE file or
    USE statement into every Fortran sub-program is much more work
    than a 1-line sed script.

    I would probably use AWK, and it is likely more than one line.

    I am not sure at all how easy it is to find the right place to put
    in the USE statement (for a constant that is in a module)
    or PARAMETER statement for one that isn't.

    And then you need to be sure that there isn't already one,
    or that (ugh) the name could already have another use.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to john.c...@simconglobal.com on Wed Apr 13 18:16:48 2022
    On Wednesday, April 13, 2022 at 2:41:22 PM UTC-4, john.c...@simconglobal.com wrote:

    .. I think a simple, unambiguous declaration which didn't have any associated complexities would be useful. To that end REAL*8 is the best we have got, it works everywhere (at least that I know of) and doesn't need to be in the standard if everyone
    understands it.

    REAL*8 comes with considerable confusion given the current state of nonstandard compiler implementations and it is not going to make it into the ISO IEC standard for Fortran.

    A "simple, unambiguous declaration" can be as suggested upthread i.e., IEEE_FPB64 where

    IEEE_FPB64 is an intrinsic (built-in) alias for REAL(KIND=K) where K = IEEE_SELECTED_REAL_KIND( P=15, R=307, RADIX=2 )

    Here IEEE_FPB64 is something a Fortran processor supporting IEEE_ARITHMETIC introduced Fortran 2003 must support intrinsically, meaning there will be no need for any USE statements.

    The introduction of IEEE_FPB64 can meet almost all the needs given the >9X.Y% (X, Y likely >8) of computing that is now done using IEEE floating-point arithmetic toward the binary64 format in the IEEE 60559:2011 standard.

    Note: the Fortran standard can also introduce IEEE_FPB32, IEEE_FPB128, IEEE_FPB256 for completeness to introduce intrinsic support for binart32, binary128, and binary256 formats from the IEEE 60559:2011 i.e., those that are colloquially understood to be
    single, quadruple, and octuple precision formats respectively. Additionally the standard can also introduce IEEE_FPD32, IEEE_FPD64, IEEE_FPD128 for the decimal formats since the IEEE_SELECTED_REAL_KIND also permits RADIX argument. The latter may not
    be supported by any real processor for a long, long time but it will be there for comprehensiveness.

    Refactoring, when needed, of "REAL*8" codes would be a simple string replacement to "IEEE_FPB64".

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to FortranFan on Wed Apr 13 19:13:45 2022
    On Wednesday, April 13, 2022 at 6:16:51 PM UTC-7, FortranFan wrote:

    (snip)

    A "simple, unambiguous declaration" can be as suggested upthread i.e., IEEE_FPB64 where

    IEEE_FPB64 is an intrinsic (built-in) alias for REAL(KIND=K) where
    K = IEEE_SELECTED_REAL_KIND( P=15, R=307, RADIX=2 )

    I didn't know about that one.

    Here IEEE_FPB64 is something a Fortran processor supporting
    IEEE_ARITHMETIC introduced Fortran 2003 must support intrinsically,
    meaning there will be no need for any USE statements.

    It is still longer than REAL*8, so string substitution is a little complicated.

    The introduction of IEEE_FPB64 can meet almost all the needs given
    the >9X.Y% (X, Y likely >8) of computing that is now done using IEEE floating-point arithmetic toward the binary64 format in the
    IEEE 60559:2011 standard.

    Note: the Fortran standard can also introduce IEEE_FPB32, IEEE_FPB128, IEEE_FPB256 for completeness to introduce intrinsic support for binart32, binary128, and binary256 formats from the IEEE 60559:2011 i.e.,
    those that are colloquially understood to be single, quadruple, and octuple
    precision formats respectively. Additionally the standard can also introduce IEEE_FPD32, IEEE_FPD64, IEEE_FPD128 for the decimal formats since the IEEE_SELECTED_REAL_KIND also permits RADIX argument.
    The latter may not be supported by any real processor for a long,
    long time but it will be there for comprehensiveness.

    IBM is selling hardware that supports it, but I don't know which compilers do.

    Refactoring, when needed, of "REAL*8" codes would be a simple string replacement to "IEEE_FPB64".

    OK, but you really should have one that allows for either IEEE binary64 or decimal64.

    Given the above, it should be IEEE_FP64.

    As I noted earlier, in the case if IEEE decimal, 64 is single precision and 128 is double precision. And all that without Cray!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to john.c...@simconglobal.com on Wed Apr 13 20:00:43 2022
    On Thursday, April 14, 2022 at 4:41:22 AM UTC+10, john.c...@simconglobal.com wrote:
    On Wednesday, April 13, 2022 at 7:09:17 AM UTC+1, Robin Vowels wrote:
    .
    How long would it take to write a program to read in a Fortran
    program and change REAL(8) to REAL(dp) ?
    If the original code didn't have odd space characters, continuation lines and comments
    in silly places very little time at all. But I think that an issue here is that dp must be defined
    somewhere, and the definition added to every routine.
    .
    That can be added trivially on the same statement as the first REAL X (DP) :: ....
    in a procedure, or all of them after the first statement of the procedure. e.g., INTEGER, PARAMETER :: dp = KIND(1.0d0) ; REAL (dp) :: ...
    .
    Inserting an INCLUDE file or USE statement into every Fortran sub-program is much more work than a 1-line sed script.
    .
    Try doing it in Fortran. Even inserting a line is trivial. Let it be USE
    .
    We have done all this. But I think a simple, unambiguous declaration which didn't have any associated complexities would be useful. To that end REAL*8 is the best we have got, it works everywhere (at least that I know of) and doesn't need to be in the
    standard if everyone understands it.
    .
    What a mess.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to FortranFan on Wed Apr 13 20:04:00 2022
    On Thursday, April 14, 2022 at 11:16:51 AM UTC+10, FortranFan wrote:
    On Wednesday, April 13, 2022 at 2:41:22 PM UTC-4, john.c...@simconglobal.com wrote:

    .. I think a simple, unambiguous declaration which didn't have any associated complexities would be useful. To that end REAL*8 is the best we have got, it works everywhere (at least that I know of) and doesn't need to be in the standard if everyone
    understands it.

    REAL*8 comes with considerable confusion given the current state of nonstandard compiler implementations and it is not going to make it into the ISO IEC standard for Fortran.

    A "simple, unambiguous declaration" can be as suggested upthread i.e., IEEE_FPB64 where

    IEEE_FPB64 is an intrinsic (built-in) alias for REAL(KIND=K) where K = IEEE_SELECTED_REAL_KIND( P=15, R=307, RADIX=2 )

    Here IEEE_FPB64 is something a Fortran processor supporting IEEE_ARITHMETIC introduced Fortran 2003 must support intrinsically, meaning there will be no need for any USE statements.

    The introduction of IEEE_FPB64 can meet almost all the needs given the >9X.Y% (X, Y likely >8) of computing that is now done using IEEE floating-point arithmetic toward the binary64 format in the IEEE 60559:2011 standard.

    Note: the Fortran standard can also introduce IEEE_FPB32, IEEE_FPB128, IEEE_FPB256 for completeness to introduce intrinsic support for binart32, binary128, and binary256 formats from the IEEE 60559:2011 i.e., those that are colloquially understood to
    be single, quadruple, and octuple precision formats respectively. Additionally the standard can also introduce IEEE_FPD32, IEEE_FPD64, IEEE_FPD128 for the decimal formats since the IEEE_SELECTED_REAL_KIND also permits RADIX argument. The latter may not
    be supported by any real processor for a long, long time but it will be there for comprehensiveness.

    Refactoring, when needed, of "REAL*8" codes would be a simple string replacement to "IEEE_FPB64".
    .
    That's gobbledegook.
    English words are better, such as REAL, etc.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to Robin Vowels on Thu Apr 14 09:35:30 2022
    On Wednesday, April 13, 2022 at 11:04:02 PM UTC-4, Robin Vowels wrote:

    On Thursday, April 14, 2022 at 11:16:51 AM UTC+10, FortranFan wrote:
    On Wednesday, April 13, 2022 at 2:41:22 PM UTC-4, john.c...@simconglobal.com wrote:

    .. I think a simple, unambiguous declaration
    ..
    Refactoring, when needed, of "REAL*8" codes would be a simple string replacement to "IEEE_FPB64".
    .
    That's gobbledegook.
    English words are better, such as REAL, etc.

    @Robin Vowels, re: your comments "That's gobbledegook," and "English words are better" no, you're absolutely wrong on both fronts.

    "English words" in far too many situations absolutely fail to convey a "simple, unambiguous" declaration. The topic of this thread with REAL*8 is one such.

    About the only thing that can work to achieve a "simple, unambiguous" to address the REAL*8 is an acronym that is also a mnemonic which is exactly what is IEEE_FPB64.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pehache@21:1/5 to All on Fri Jun 17 23:27:09 2022
    Le 09/04/2022 à 16:05, Beliavsky a écrit :
    Since compilers treat the non-standard but very common

    real*4, real*8, integer*4, integer*8

    as

    use iso_fortran_env
    real(kind=real32), real(kind=real64), integer(kind=int32), integer(kind=int64)

    would it make sense to standardize the former set of declarations, which is concise and clear, to mean the same as the latter?

    It could make sense, except that xxxx*n notations have never been
    standardized

    As noted by other contributors :
    - both REAL*4 and REAL*8 were mapped to the 64 bits floating point type
    on old CRAY computers
    - REAL*4 was mapped to the 36 bits floating point on CDC, and REAL*8 to
    72 bits.

    So mapping REAL*4 to kind=real32 could break some legacy codes, as it
    seems to me that kind=real32 is *required* to be stored on exactly 32 bits.

    I have to admit that 36 bits machines are unlikely to show up again (but
    how knows...), but compilers that would completely drop 32 flating point support are not that unlikely in the future.

    --
    "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
    même sens que les tiennes.", ST sur fr.bio.medecine
    ST passe le mur du çon : <j3nn2hFmqj7U1@mid.individual.net>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pehache@21:1/5 to All on Fri Jun 17 23:47:53 2022
    Le 09/04/2022 à 16:55, Robin Vowels a écrit :
    On Sunday, April 10, 2022 at 12:37:41 AM UTC+10, Beliavsky wrote:
    On Saturday, April 9, 2022 at 10:05:29 AM UTC-4, Beliavsky wrote:
    Since compilers treat the non-standard but very common

    real*4, real*8, integer*4, integer*8

    as

    use iso_fortran_env
    real(kind=real32), real(kind=real64), integer(kind=int32), integer(kind=int64)

    would it make sense to standardize the former set of declarations, which is concise and clear, to mean the same as the latter?
    Currently, if someone inherits a code with real*8 and decides to make it standard-conforming, they may replace it with
    real(kind=8),
    .
    An appropriate replacement is real (kind=dp)
    (where dp is defined as kind(1.0d0)...)

    If it was, the developers would have used DOUBLE PRECISION from the
    begining, and not REAL*8


    --
    "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
    même sens que les tiennes.", ST sur fr.bio.medecine
    ST passe le mur du çon : <j3nn2hFmqj7U1@mid.individual.net>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pehache@21:1/5 to All on Sat Jun 18 00:02:27 2022
    Le 13/04/2022 à 17:10, Ron Shepard a écrit :
    On 4/13/22 2:44 AM, gah4 wrote:
    On Tuesday, April 12, 2022 at 11:06:52 PM UTC-7, Robin Vowels wrote:

    (snip)

    How many machines are using that offer only 64 bit reals?

    Cray-1, Cray-1A, Cray-1S, Cray-1M, Cray-X-MP, Cray-Y-MP, Cray-2
    Cray-C90 Cray-EL90.

    I'm not sure exactly what this discussion is about, but fortran
    compilers on those computers also supported 128-bit reals. Double
    precision on those machines was slow, but it was there if you absolutely needed it.

    However, the FPS series of machines, which were also popular in the
    1980s, did not support 128-bit arithmetic at all. They only supported
    64-bit single precision floating point.

    How many of each did they make, so we can add them all up?

    These were not personal computers, so the measure is not how many of the computers were made, but rather how many programmers and users had
    access to them. In my field of computational chemistry, that would be essentially every active programmer. In the 1980s, one could gain access
    in a variety of ways, through government agencies like NSF, NIH, DoD, or
    DOE, through state computer access programs, through universities, or
    through private employers. Those machines cast a huge shadow in their time.

    Yep. And REAL*8 was by far the simplest way to have code running
    efficiently on both these supercomputers and the unix workstations, when ~64bits precision was needed



    --
    "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
    même sens que les tiennes.", ST sur fr.bio.medecine
    ST passe le mur du çon : <j3nn2hFmqj7U1@mid.individual.net>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pehache@21:1/5 to All on Sat Jun 18 00:55:26 2022
    Le 09/04/2022 à 19:15, Ron Shepard a écrit :
    On 4/9/22 9:05 AM, Beliavsky wrote:
    Since compilers treat the non-standard but very common

    real*4, real*8, integer*4, integer*8

    as

    use iso_fortran_env
    real(kind=real32), real(kind=real64), integer(kind=int32),
    integer(kind=int64)

    would it make sense to standardize the former set of declarations,
    which is concise and clear, to mean the same as the latter?

    In my opinion, this would be a step backward for the language.

    There are many reasons why this should not be done, but one of them is
    that REAL*4 etc. were always just defined by the local compiler to map
    to its supported floating point formats. For byte addressable machines,
    that meant that your suggested mapping would be correct. But there are
    also 36-bit, 60-bit, and 64-bit machines that cannot conform to those mappings, so they must do something different. In the f77 time in the
    1980s, I used those declarations extensively for exactly that reason, it
    was a way, with some care, to write portable (but nonstandard) code. I
    used REAL*8 declarations to run on machines with all of those word
    lengths. It wasn't pretty, but it served its purpose at the time.

    But now we have the fortran KIND system, which handles all of that much better. Yes, when you incorporate old f66 and f77 code into your current project, you need to edit in those changes, but that is not a big deal.
    Your minimal efforts are rewarded with clarity and portability. I have programs with hundreds of thousands of lines where I can change the
    precision globally by modifying a single line of code in a module. From
    the programmer's perspective, that is hard to beat.

    Numerical analysts are now experimenting with 16-bit real arithmetic to
    speed up critical parts of algorithms. If/when they get that working,
    the fortran KIND system is already set up to handle that. IEEE decimal arithmetic is another feature raising its head on the horizon. Again,
    the fortran KIND system is already there and waiting. 10-byte arithmetic
    is another example (although some compilers are currently doing this the wrong way, I think). 128-bit arithmetic and beyond, both reals and
    integers, are all handled perfectly well with the fortran KIND system.

    If a compiler supports real types with those numbers of bits (real32,
    real64, etc.), then the kind values are set appropriately. If there is
    more than one kind with that many bits, then the processor chooses which
    one to return. If the processor does not support a kind with exactly
    those bits, then the processor sets the value to either -1 or -2. The -2 value means that some kind is available with higher precision. This
    might not be the best way to write portable code, but if you want to
    write code targeted to specific floating point formats, that is a
    reasonable way to do it. The IEEE intrinsic module goes even further if
    code is intended to target that floating point format, rounding modes,
    NaN, subnormals, etc., all available within the fortran KIND system.
    This is all in contrast to REAL*4, REAL*8, etc, which are mapped in a
    very loose manner to the underlying supported floating point formats.

    I think the fortran KIND system is well thought out and it works well in practice.

    And yet, it still lacks something as simple as REAL*8, which would
    select either the default REAL or the DOUBLE PRECISION, and nothing else.

    kind=real64 is almost that, except that:
    - it may not exist
    - nothing garantees that real64 is kind(1.0) or kind(1.0d0)

    OK, as of today there's probably no compiler where real64 does not exist
    (or does exist but is inefficient). Nevertheless it can happen one day
    or another...

    I used to write:

    integer, parameter :: sp = kind(1.0)
    integer, parameter :: dp = kind(1.0d0)
    integer, parameter :: sp_is_enough = min(max(precision(sp)-9,1),0)
    integer, parameter :: double = sp*sp_is_enough + dp*(1-sp_is_enough)

    so REAL(kind=double) is similar to the C "double", which is only
    required to have at least 10 digits precision, and which can be
    identical to "float". And most importantly it is always, and will always
    be, defined.

    kind=sp, kind=dp, and kind=double, cover 99.99% of the needs.


    --
    "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
    même sens que les tiennes.", ST sur fr.bio.medecine
    ST passe le mur du çon : <j3nn2hFmqj7U1@mid.individual.net>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to pehache on Fri Jun 17 15:35:07 2022
    On Friday, June 17, 2022 at 3:02:31 PM UTC-7, pehache wrote:

    (snip)

    Yep. And REAL*8 was by far the simplest way to have code running
    efficiently on both these supercomputers and the unix workstations, when ~64bits precision was needed

    It seems, though, that REAL(8) is now very popular, and even taught in
    some scientific computing courses. However, KIND values are not
    standardized at all, and so that is less reasonable than REAL*8.

    In the days of punched cards, less typing was important, though
    the shift needed for the * made it slightly harder.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to pehache on Fri Jun 17 18:58:26 2022
    On 6/17/2022 4:27 PM, pehache wrote:
    Le 09/04/2022 à 16:05, Beliavsky a écrit :
    Since compilers treat the non-standard but very common

    real*4, real*8, integer*4, integer*8

    as

    use iso_fortran_env
    real(kind=real32), real(kind=real64), integer(kind=int32),
    integer(kind=int64)

    would it make sense to standardize the former set of declarations,
    which is concise and clear, to mean the same as the latter?

    It could make sense, except that xxxx*n notations have never been standardized

    As noted by other contributors :
    - both REAL*4 and REAL*8 were mapped to the 64 bits floating point type
    on old CRAY computers
    - REAL*4 was mapped to the 36 bits floating point on CDC, and REAL*8 to
    72 bits.

    So mapping REAL*4 to kind=real32 could break some legacy codes, as it
    seems to me that kind=real32 is *required* to be stored on exactly 32 bits.

    I have to admit that 36 bits machines are unlikely to show up again (but
    how knows...), but compilers that would completely drop 32 flating point support are not that unlikely in the future.

    The CDC 7600 that I programmed on back in the 1970s was 60 bit words.
    REAL*4 was mapped to the 60 bit word.

    The UNIVAC 1108 was 36 bit words back in the 1970s. REAL*4 was mapped
    to the 36 bit word.

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Lynn McGuire on Fri Jun 17 17:31:37 2022
    On Friday, June 17, 2022 at 4:58:32 PM UTC-7, Lynn McGuire wrote:

    (snip)
    The CDC 7600 that I programmed on back in the 1970s was 60 bit words.
    REAL*4 was mapped to the 60 bit word.

    The UNIVAC 1108 was 36 bit words back in the 1970s. REAL*4 was mapped
    to the 36 bit word.

    I am not sure about REAL*4 and the PDP-10's 36 bit word, but I do
    remember that REAL*8 got the double precision 72 bit word.
    (Actually, there are two PDP-10 double precisions, one for the machines
    without double precision hardware that do it in software, the other
    for ones with the hardware.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to pehache on Fri Jun 17 19:10:25 2022
    On Saturday, June 18, 2022 at 8:02:31 AM UTC+10, pehache wrote:
    Le 13/04/2022 à 17:10, Ron Shepard a écrit :
    On 4/13/22 2:44 AM, gah4 wrote:
    On Tuesday, April 12, 2022 at 11:06:52 PM UTC-7, Robin Vowels wrote:

    (snip)

    How many machines are using that offer only 64 bit reals?

    Cray-1, Cray-1A, Cray-1S, Cray-1M, Cray-X-MP, Cray-Y-MP, Cray-2
    Cray-C90 Cray-EL90.

    I'm not sure exactly what this discussion is about, but fortran
    compilers on those computers also supported 128-bit reals. Double precision on those machines was slow, but it was there if you absolutely needed it.

    However, the FPS series of machines, which were also popular in the
    1980s, did not support 128-bit arithmetic at all. They only supported 64-bit single precision floating point.

    How many of each did they make, so we can add them all up?

    These were not personal computers, so the measure is not how many of the computers were made, but rather how many programmers and users had
    access to them. In my field of computational chemistry, that would be essentially every active programmer. In the 1980s, one could gain access in a variety of ways, through government agencies like NSF, NIH, DoD, or DOE, through state computer access programs, through universities, or through private employers. Those machines cast a huge shadow in their time.
    Yep. And REAL*8 was by far the simplest way to have code running
    efficiently on both these supercomputers and the unix workstations, when ~64bits precision was needed
    .
    DOUBLE PRECISION was clear and unequivocal (and STANDARD).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to pehache on Fri Jun 17 19:21:24 2022
    On Saturday, June 18, 2022 at 8:55:30 AM UTC+10, pehache wrote:
    Le 09/04/2022 à 19:15, Ron Shepard a écrit :
    On 4/9/22 9:05 AM, Beliavsky wrote:
    Since compilers treat the non-standard but very common

    real*4, real*8, integer*4, integer*8

    as

    use iso_fortran_env
    real(kind=real32), real(kind=real64), integer(kind=int32),
    integer(kind=int64)

    would it make sense to standardize the former set of declarations,
    which is concise and clear, to mean the same as the latter?

    In my opinion, this would be a step backward for the language.

    There are many reasons why this should not be done, but one of them is that REAL*4 etc. were always just defined by the local compiler to map
    to its supported floating point formats. For byte addressable machines, that meant that your suggested mapping would be correct. But there are also 36-bit, 60-bit, and 64-bit machines that cannot conform to those mappings, so they must do something different. In the f77 time in the 1980s, I used those declarations extensively for exactly that reason, it was a way, with some care, to write portable (but nonstandard) code. I used REAL*8 declarations to run on machines with all of those word lengths. It wasn't pretty, but it served its purpose at the time.

    But now we have the fortran KIND system, which handles all of that much better. Yes, when you incorporate old f66 and f77 code into your current project, you need to edit in those changes, but that is not a big deal. Your minimal efforts are rewarded with clarity and portability. I have programs with hundreds of thousands of lines where I can change the precision globally by modifying a single line of code in a module. From the programmer's perspective, that is hard to beat.

    Numerical analysts are now experimenting with 16-bit real arithmetic to speed up critical parts of algorithms. If/when they get that working,
    the fortran KIND system is already set up to handle that. IEEE decimal arithmetic is another feature raising its head on the horizon. Again,
    the fortran KIND system is already there and waiting. 10-byte arithmetic is another example (although some compilers are currently doing this the wrong way, I think). 128-bit arithmetic and beyond, both reals and integers, are all handled perfectly well with the fortran KIND system.

    If a compiler supports real types with those numbers of bits (real32, real64, etc.), then the kind values are set appropriately. If there is more than one kind with that many bits, then the processor chooses which one to return. If the processor does not support a kind with exactly
    those bits, then the processor sets the value to either -1 or -2. The -2 value means that some kind is available with higher precision. This
    might not be the best way to write portable code, but if you want to
    write code targeted to specific floating point formats, that is a reasonable way to do it. The IEEE intrinsic module goes even further if code is intended to target that floating point format, rounding modes, NaN, subnormals, etc., all available within the fortran KIND system.
    This is all in contrast to REAL*4, REAL*8, etc, which are mapped in a
    very loose manner to the underlying supported floating point formats.

    I think the fortran KIND system is well thought out and it works well in practice.

    And yet, it still lacks something as simple as REAL*8, which would
    select either the default REAL or the DOUBLE PRECISION, and nothing else.
    .
    Are you not overlooking the fact that you can have a single statement
    in an entire program of hundreds of functions and subroutines
    that sets the precision required? And which can be changed to set the precision required? -- and it saves considerably more typing than what you propose.

    kind=real64 is almost that, except that:
    - it may not exist
    - nothing garantees that real64 is kind(1.0) or kind(1.0d0)

    OK, as of today there's probably no compiler where real64 does not exist
    (or does exist but is inefficient). Nevertheless it can happen one day
    or another...

    I used to write:

    integer, parameter :: sp = kind(1.0)
    integer, parameter :: dp = kind(1.0d0)
    integer, parameter :: sp_is_enough = min(max(precision(sp)-9,1),0)
    integer, parameter :: double = sp*sp_is_enough + dp*(1-sp_is_enough)
    .
    This last line won't work in some compilers.
    .
    so REAL(kind=double) is similar to the C "double", which is only
    required to have at least 10 digits precision, and which can be
    identical to "float". And most importantly it is always, and will always
    be, defined.

    kind=sp, kind=dp, and kind=double, cover 99.99% of the needs.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pehache@21:1/5 to All on Sat Jun 18 07:30:03 2022
    Le 18/06/2022 à 04:10, Robin Vowels a écrit :


    These were not personal computers, so the measure is not how many of the >>> computers were made, but rather how many programmers and users had
    access to them. In my field of computational chemistry, that would be
    essentially every active programmer. In the 1980s, one could gain access >>> in a variety of ways, through government agencies like NSF, NIH, DoD, or >>> DOE, through state computer access programs, through universities, or
    through private employers. Those machines cast a huge shadow in their time.

    Yep. And REAL*8 was by far the simplest way to have code running
    efficiently on both these supercomputers and the unix workstations, when
    ~64bits precision was needed
    .
    DOUBLE PRECISION was clear and unequivocal (and STANDARD).

    And a full waste of resources (both CPU time and memory) on a Cray, as
    it was 128 bits software emulated.

    When you were lucky enough to have access to such machines back then, it
    was a crime to use DOUBLE PRECISION where REAL was enough.

    --
    "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
    même sens que les tiennes.", ST sur fr.bio.medecine
    ST passe le mur du çon : <j3nn2hFmqj7U1@mid.individual.net>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pehache@21:1/5 to All on Sat Jun 18 07:36:30 2022
    Le 18/06/2022 à 04:21, Robin Vowels a écrit :

    I used to write:

    integer, parameter :: sp = kind(1.0)
    integer, parameter :: dp = kind(1.0d0)
    integer, parameter :: sp_is_enough = min(max(precision(sp)-9,1),0)
    integer, parameter :: double = sp*sp_is_enough + dp*(1-sp_is_enough)
    .
    This last line won't work in some compilers.
    .

    Isn't it a constant expression ?


    --
    "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
    même sens que les tiennes.", ST sur fr.bio.medecine
    ST passe le mur du çon : <j3nn2hFmqj7U1@mid.individual.net>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to pehache on Sat Jun 18 05:34:28 2022
    On Saturday, June 18, 2022 at 3:30:07 PM UTC+10, pehache wrote:
    Le 18/06/2022 à 04:10, Robin Vowels a écrit :


    These were not personal computers, so the measure is not how many of the >>> computers were made, but rather how many programmers and users had
    access to them. In my field of computational chemistry, that would be >>> essentially every active programmer. In the 1980s, one could gain access >>> in a variety of ways, through government agencies like NSF, NIH, DoD, or >>> DOE, through state computer access programs, through universities, or >>> through private employers. Those machines cast a huge shadow in their time.

    Yep. And REAL*8 was by far the simplest way to have code running
    efficiently on both these supercomputers and the unix workstations, when >> ~64bits precision was needed
    .
    DOUBLE PRECISION was clear and unequivocal (and STANDARD).
    And a full waste of resources (both CPU time and memory) on a Cray, as
    it was 128 bits software emulated.

    When you were lucky enough to have access to such machines back then, it
    was a crime to use DOUBLE PRECISION where REAL was enough.
    .
    In that case, you used REAL.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pehache@21:1/5 to All on Sat Jun 18 18:26:38 2022
    Le 18/06/2022 à 14:34, Robin Vowels a écrit :

    .
    DOUBLE PRECISION was clear and unequivocal (and STANDARD).
    And a full waste of resources (both CPU time and memory) on a Cray, as
    it was 128 bits software emulated.

    When you were lucky enough to have access to such machines back then, it
    was a crime to use DOUBLE PRECISION where REAL was enough.
    .
    In that case, you used REAL.

    You forgot what I wrote in a previous message: "...code running
    efficiently on both these supercomputers and the unix workstations..."

    People who had access to a Cray at the times also had classical unix workstations, with compilers defaulting REAL to 32 bits as usual. Many
    codes had to run on both machines.

    --
    "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
    même sens que les tiennes.", ST sur fr.bio.medecine
    ST passe le mur du çon : <j3nn2hFmqj7U1@mid.individual.net>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pehache@21:1/5 to All on Sat Jun 18 21:38:38 2022
    Le 18/06/2022 à 21:38, pehache a écrit :
    Le 18/06/2022 à 00:55, pehache a écrit :

    And yet, it still lacks something as simple as REAL*8, which would
    select either the default REAL or the DOUBLE PRECISION, and nothing else.

    kind=real64 is almost that, except that:
    - it may not exist
    - nothing garantees that real64 is kind(1.0) or kind(1.0d0)

    OK, as of today there's probably no compiler where real64 does not
    exist (or does exist but is inefficient). Nevertheless it can happen
    one day or another...

    I used to write:

    integer, parameter :: sp = kind(1.0)
    integer, parameter :: dp = kind(1.0d0)
    integer, parameter :: sp_is_enough = min(max(precision(sp)-9,1),0)
    integer, parameter :: double = sp*sp_is_enough + dp*(1-sp_is_enough)

    so REAL(kind=double) is similar to the C "double", which is only
    required to have at least 10 digits precision, and which can be
    identical to "float". And most importantly it is always, and will
    always be, defined.

    kind=sp, kind=dp, and kind=double, cover 99.99% of the needs.



    I am just discovering the stdlib kinds module... REAL(kind=dp) might be
    the quasi-standard substitute for REAL*8. If I understand correctly "dp"
    is just an alias to "c_double" in ISO_BIND_C. Good point : it is always defined.


    https://stdlib.fortran-lang.org/page/specs/stdlib_kinds.html

    --
    "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
    même sens que les tiennes.", ST sur fr.bio.medecine
    ST passe le mur du çon : <j3nn2hFmqj7U1@mid.individual.net>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to All on Sat Jun 18 13:02:47 2022
    On Saturday, June 18, 2022 at 12:45:40 PM UTC-7, Phillip Helbig (undress to reply) wrote:
    integer, parameter :: sp = kind(1.0)
    integer, parameter :: dp = kind(1.0d0)

    In such cases, why not just write REAL and DOUBLE PRECISION? The
    results will be exactly the same.

    If you are going to use KIND, then don't call it something like sp or dp which is confusing if you change the definition (sort of the point of
    KIND); if you won't ever change it, just use REAL and DOUBLE PRECISION: completely clear, completely standard.

    Well, some then define wp, working precision, which is either sp or dp.
    So you only have to change one place.

    But in the days before KIND, it was also somewhat common to have
    different sets of constants for different machines. There might at
    least be an EPSILON, but sometimes whole polynomial approximations
    that were different for different machines.

    They would then have comments for the ones you weren't using.

    One trick from the card days was a C in column 80. You then reverse
    the card, and to end, so the C is in column 1. Just for the ones
    you don't want to use.

    With computer editors, the complications are different, but usually
    it isn't so hard to select the ones you want.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phillip Helbig (undress to reply@21:1/5 to All on Sat Jun 18 19:45:35 2022
    integer, parameter :: sp = kind(1.0)
    integer, parameter :: dp = kind(1.0d0)

    In such cases, why not just write REAL and DOUBLE PRECISION? The
    results will be exactly the same.

    If you are going to use KIND, then don't call it something like sp or dp
    which is confusing if you change the definition (sort of the point of
    KIND); if you won't ever change it, just use REAL and DOUBLE PRECISION: completely clear, completely standard.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jfh@21:1/5 to All on Sat Jun 18 14:05:51 2022
    On Sunday, June 19, 2022 at 8:02:51 AM UTC+12, gah4 wrote:

    Well, some then define wp, working precision, which is either sp or dp.
    So you only have to change one place.

    I use wp a lot but with the gfortran compiler I sometimes use selected_real(kind(prec)) where prec is any of 6,15,18,33 because the smaller ones are useful for checking the program and they run faster, but 33 is needed for high accuracy in one of my
    programs.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to jfh on Sat Jun 18 16:27:47 2022
    On Saturday, June 18, 2022 at 5:05:54 PM UTC-4, jfh wrote:

    .. I sometimes use selected_real(kind(prec)) where prec is any of 6,15,18,33 ..

    You meant selected_real_kind(prec)?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to All on Sat Jun 18 19:00:09 2022
    On 6/17/2022 7:31 PM, gah4 wrote:
    On Friday, June 17, 2022 at 4:58:32 PM UTC-7, Lynn McGuire wrote:

    (snip)
    The CDC 7600 that I programmed on back in the 1970s was 60 bit words.
    REAL*4 was mapped to the 60 bit word.

    The UNIVAC 1108 was 36 bit words back in the 1970s. REAL*4 was mapped
    to the 36 bit word.

    I am not sure about REAL*4 and the PDP-10's 36 bit word, but I do
    remember that REAL*8 got the double precision 72 bit word.
    (Actually, there are two PDP-10 double precisions, one for the machines without double precision hardware that do it in software, the other
    for ones with the hardware.

    I never wrote anything on a PDP. Just the later 32 bit VMS machines.

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jfh@21:1/5 to FortranFan on Sat Jun 18 21:53:34 2022
    On Sunday, June 19, 2022 at 11:27:51 AM UTC+12, FortranFan wrote:
    On Saturday, June 18, 2022 at 5:05:54 PM UTC-4, jfh wrote:

    .. I sometimes use selected_real(kind(prec)) where prec is any of 6,15,18,33 ..

    You meant selected_real_kind(prec)?
    Yes. Sorry. I usually check anything I say in Fortran by compiling it but I was in a hurry this morning.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phillip Helbig (undress to reply@21:1/5 to gah4@u.washington.edu on Sun Jun 19 06:11:42 2022
    In article <88433631-0744-4418-b371-90bd0a4b463bn@googlegroups.com>,
    gah4 <gah4@u.washington.edu> writes:

    On Saturday, June 18, 2022 at 12:45:40 PM UTC-7, Phillip Helbig (undress to reply) wrote:
    integer, parameter :: sp = kind(1.0)
    integer, parameter :: dp = kind(1.0d0)

    In such cases, why not just write REAL and DOUBLE PRECISION? The
    results will be exactly the same.

    If you are going to use KIND, then don't call it something like sp or dp which is confusing if you change the definition (sort of the point of KIND); if you won't ever change it, just use REAL and DOUBLE PRECISION: completely clear, completely standard.

    Well, some then define wp, working precision, which is either sp or dp.
    So you only have to change one place.

    That is different, and makes sense.

    One trick from the card days was a C in column 80. You then reverse
    the card, and to end, so the C is in column 1. Just for the ones
    you don't want to use.

    Hadn't heard of that one. (But I started after punched cards. I know
    someone only 7 years older, though, he used them extensively.)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pehache@21:1/5 to All on Sun Jun 19 15:24:45 2022
    Le 18/06/2022 à 21:45, Phillip Helbig (undress to reply) a écrit :
    integer, parameter :: sp = kind(1.0)
    integer, parameter :: dp = kind(1.0d0)

    In such cases, why not just write REAL and DOUBLE PRECISION?

    Just to simplify the two lines that come ater and that you have cut ;)



    --
    "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
    même sens que les tiennes.", ST sur fr.bio.medecine
    ST passe le mur du çon : <j3nn2hFmqj7U1@mid.individual.net>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to All on Sun Jun 19 10:14:04 2022
    On 6/17/22 5:35 PM, gah4 wrote:
    [...]
    It seems, though, that REAL(8) is now very popular, and even taught in
    some scientific computing courses. However, KIND values are not
    standardized at all, and so that is less reasonable than REAL*8.

    I think the real problem now with REAL(8) usage is how compiler
    documentation is written. Take gfortran, as one of many examples. If you
    look up any intrinsic function involving real kinds, it will use literal
    (4) and (8). This is both more concise than the longer (kind(1.0))) and (kind(1.0D0)), or (real32) and (real64), but it also documents the kind
    mapping that gfortran uses. Also, if (real32) etc. were used in the documentation, than the accompanying line with USE ISO_FORTRAN_ENV would
    need to be added throughout. Otherwise, the example code would not work
    when a beginner types in the code.

    So when a beginner looks up the details of some feature in the
    documentation, and that documentation uses hardwired KIND literals, he
    is going to follow that example exactly as written. Then once he has
    invested effort in writing a few thousand lines of code with literal
    kind values, he isn't going to want to go back and fix them, he is
    instead going to ask the standard committee to change the language to
    agree with his code.

    I don't know the answer to this dilemma. I don't think the fortran documentation needs to be changed, but beginners somehow need to know
    not to write code that way. It is at least an awkward situation when
    learning or teaching the language.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to pehache on Sun Jun 19 11:00:38 2022
    On 6/17/22 5:55 PM, pehache wrote:

    I think the fortran KIND system is well thought out and it works well
    in practice.

    And yet, it still lacks something as simple as REAL*8, which would
    select either the default REAL or the DOUBLE PRECISION, and nothing else.

    The common real(wp) convention is only one character more, and it avoids
    all of the problems with the literal kind value. You can write millions
    of lines of code with that declaration, and the wp parameter can be
    defined in a single line of code. To change precision throughout, only
    that single line of code needs to be changed.

    You can't make things easier than that.

    Further, if for some reason there is a conflict of kinds between some
    legacy code and the modern code, then you find out these problems at
    compile time where they can be easily addressed. It does not require
    some extensive testing and debugging at run time to find the kind
    mismatches.

    I do think it would be better if it were easier to incorporate legacy
    code into modules. But it is hard to think of an improvement over the
    fortran KIND system, for either mixed- or nonmixed precision arithmetic.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to pehache on Sun Jun 19 10:44:24 2022
    On 6/18/22 11:26 AM, pehache wrote:
    [...]
    People who had access to a Cray at the times also had classical unix workstations, with compilers defaulting REAL to 32 bits as usual. Many
    codes had to run on both machines.

    I think this is why CRAY computers weren't more popular than they were.
    Seymore Cray focused on high-end supercomputing, and he was not
    interested in the full programming infrastructure to support that supercomputing. There were several things that would have saved the
    company and that computing environment, none of which happened:

    1) PC-level, workstation-level, or department-level minicomputers that supported the CRAY instruction set.

    2) Development of interactive debuggers to facilitate code development.

    3) Support for cross compilers that would allow code development on
    PC-level computers. It would have been great if code could have run in simulation mode on these computers, but even having the ability to
    compile the code on a local PC or workstation to see compile-time
    diagnostics would have been a huge step forward.

    4) Support for fortran 8x, with array operations and more or less direct support for vector hardware. Instead, it was not until the late 1980s
    and 1990s that CRAY computers even supported f77.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to Robin Vowels on Sun Jun 19 10:26:09 2022
    On 6/17/22 9:10 PM, Robin Vowels wrote:
    On Saturday, June 18, 2022 at 8:02:31 AM UTC+10, pehache wrote:
    Le 13/04/2022 à 17:10, Ron Shepard a écrit :
    On 4/13/22 2:44 AM, gah4 wrote:
    On Tuesday, April 12, 2022 at 11:06:52 PM UTC-7, Robin Vowels wrote:

    (snip)

    How many machines are using that offer only 64 bit reals?

    Cray-1, Cray-1A, Cray-1S, Cray-1M, Cray-X-MP, Cray-Y-MP, Cray-2
    Cray-C90 Cray-EL90.

    I'm not sure exactly what this discussion is about, but fortran
    compilers on those computers also supported 128-bit reals. Double
    precision on those machines was slow, but it was there if you absolutely >>> needed it.

    However, the FPS series of machines, which were also popular in the
    1980s, did not support 128-bit arithmetic at all. They only supported
    64-bit single precision floating point.

    How many of each did they make, so we can add them all up?

    These were not personal computers, so the measure is not how many of the >>> computers were made, but rather how many programmers and users had
    access to them. In my field of computational chemistry, that would be
    essentially every active programmer. In the 1980s, one could gain access >>> in a variety of ways, through government agencies like NSF, NIH, DoD, or >>> DOE, through state computer access programs, through universities, or
    through private employers. Those machines cast a huge shadow in their time. >> Yep. And REAL*8 was by far the simplest way to have code running
    efficiently on both these supercomputers and the unix workstations, when
    ~64bits precision was needed
    .
    DOUBLE PRECISION was clear and unequivocal (and STANDARD).

    No, it was just standard. It was neither clear nor unequivocal, as
    explained above, or portable in a practical sense. Ironically, REAL*8
    was more portable, yet nonstandard, which is why it was so popular at
    the time and why so much legacy code was written that way.

    Now modern fortran has a much superior mechanism for specifying
    precision that is portable, standard conforming, and open ended for
    future precisions. Yet some people want to continue using the old
    approaches.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pehache@21:1/5 to All on Sun Jun 19 23:15:47 2022
    Le 19/06/2022 à 17:44, Ron Shepard a écrit :
    On 6/18/22 11:26 AM, pehache wrote:
    [...]
    People who had access to a Cray at the times also had classical unix
    workstations, with compilers defaulting REAL to 32 bits as usual. Many
    codes had to run on both machines.

    I think this is why CRAY computers weren't more popular than they were.

    I think the main reason was the price :)


    Seymore Cray focused on high-end supercomputing, and he was not
    interested in the full programming infrastructure to support that supercomputing. There were several things that would have saved the
    company and that computing environment, none of which happened:

    1) PC-level, workstation-level, or department-level minicomputers that supported the CRAY instruction set.

    2) Development of interactive debuggers to facilitate code development.

    3) Support for cross compilers that would allow code development on
    PC-level computers. It would have been great if code could have run in simulation mode on these computers, but even having the ability to
    compile the code on a local PC or workstation to see compile-time
    diagnostics would have been a huge step forward.

    4) Support for fortran 8x, with array operations and more or less direct support for vector hardware. Instead, it was not until the late 1980s
    and 1990s that CRAY computers even supported f77.

    I have worked a bit on Cray computers near the end of this era, in the
    1990's, and I don't share this analysis.

    For development, tests, small to medium volumes of calculations, we had
    Sun and HP workstations. The codes were tested, debugged, etc, first on
    these workstations, and didn't need a lot of additional work on the Cray itself. Sure, an interactive debugger or a cross-compiler may have
    helped a bit, but I don't remember that we had big troubles.

    Early support for f90, maybe... But even in the 1990s f90 was not that
    popular in high performance computing (for sometimes good, sometimes bad reasons). The recommandation where I was working (as a PhD student) was
    to stick to f77. So the lack of f90 features on the Cray was not a big
    problem I guess.

    Regarding workstation-level computers, I have some doubts... The
    architecture was so special that it would have been quite difficult to
    tranpose it to lower end machines.


    --
    "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
    même sens que les tiennes.", ST sur fr.bio.medecine
    ST passe le mur du çon : <j3nn2hFmqj7U1@mid.individual.net>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phillip Helbig (undress to reply@21:1/5 to pehache.7@gmail.com on Mon Jun 20 08:08:08 2022
    In article <jh8mctFn6e2U1@mid.individual.net>, pehache
    <pehache.7@gmail.com> writes:

    Le 18/06/2022 à 21:45, Phillip Helbig (undress to reply) a écrit :
    integer, parameter :: sp = kind(1.0)
    integer, parameter :: dp = kind(1.0d0)

    In such cases, why not just write REAL and DOUBLE PRECISION?

    Just to simplify the two lines that come ater and that you have cut ;)

    Yes, you have a point. However, I have seen the above used standalone.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to Ron Shepard on Mon Jun 20 08:19:39 2022
    Ron Shepard <nospam@nowhere.org> schrieb:
    On 6/18/22 11:26 AM, pehache wrote:
    [...]
    People who had access to a Cray at the times also had classical unix
    workstations, with compilers defaulting REAL to 32 bits as usual. Many
    codes had to run on both machines.

    I think this is why CRAY computers weren't more popular than they were.

    Crays and other mainframes were very expensive mainframes, and they
    were not suitable for every task. Partial differential equations
    were great, but for solving ODEs, for example, they were not
    particularly fast.


    Seymore Cray focused on high-end supercomputing, and he was not
    interested in the full programming infrastructure to support that supercomputing. There were several things that would have saved the
    company and that computing environment, none of which happened:

    Vector computers were only effective for a particular time, when
    memory latency was relatively low compared to the cycle time and
    you could use the vector pipes to do several operations per cycle.
    They had no cache, for example.

    Nowadays, you get several operations by cycle using superscalar
    OoO - microarchitectures. DRAM speed has not increased as much
    as cycle times, which led to the introduction of multi-level
    cache hierarchies.

    If your algorithms have a good cache footprint, you can also do
    several operations per cycle, with very good flexibility, and this
    does not count the "vectorization" (which is really a bit painful)
    using SIMD registers, which can lead to a large speedup for the
    right problems and right algorithms (and the right compiler magic,
    which is still lacking for many cases). SIMD is an area where a
    good assembler programmer can still get a factor 2,4 or 8 against
    normal code.

    And, of course, there's graphics cards - very hard to program,
    extremely fast, often memory bound.

    1) PC-level, workstation-level, or department-level minicomputers that supported the CRAY instruction set.

    Once the ISA was no longer beneficial, that would have died out.

    2) Development of interactive debuggers to facilitate code development.

    3) Support for cross compilers that would allow code development on
    PC-level computers. It would have been great if code could have run in simulation mode on these computers, but even having the ability to
    compile the code on a local PC or workstation to see compile-time
    diagnostics would have been a huge step forward.

    I did both of the above with a Fujitsu VP and a HP workstation,
    later with Linux. I even wrote a short wrapper to convert END DO
    to the standarf F77 form.

    4) Support for fortran 8x, with array operations and more or less direct support for vector hardware. Instead, it was not until the late 1980s
    and 1990s that CRAY computers even supported f77.

    Late introduction for never Fortran version, and late adoption by
    vendors, has led to Fortran's lost decase (or so). Once people
    had discovered the ubiquitous C language, with all its faults
    (but with structs and recursion and dynamic memory management)
    that particular train left its station.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pehache@21:1/5 to All on Mon Jun 20 16:06:38 2022
    Le 19/06/2022 à 18:00, Ron Shepard a écrit :
    On 6/17/22 5:55 PM, pehache wrote:

    I think the fortran KIND system is well thought out and it works well
    in practice.

    And yet, it still lacks something as simple as REAL*8, which would
    select either the default REAL or the DOUBLE PRECISION, and nothing else.

    The common real(wp) convention is only one character more, and it avoids
    all of the problems with the literal kind value. You can write millions
    of lines of code with that declaration, and the wp parameter can be
    defined in a single line of code. To change precision throughout, only
    that single line of code needs to be changed.

    You can't make things easier than that.

    Further, if for some reason there is a conflict of kinds between some
    legacy code and the modern code, then you find out these problems at
    compile time where they can be easily addressed. It does not require
    some extensive testing and debugging at run time to find the kind
    mismatches.

    I do think it would be better if it were easier to incorporate legacy
    code into modules. But it is hard to think of an improvement over the
    fortran KIND system, for either mixed- or nonmixed precision arithmetic.

    In practice I mostly agree with you.

    Still, there is something missing: how do you know the degree of hardware support of a given kind?

    Requesting and obtaining a true quadruple precision real (128 bits) is
    nice, but if it is emulated maybe you would prefer (or not) an extended precision real (80 bits) that is much faster (at the price of more
    algorithmic work on your side).

    Also imagine a future machine where the hardware floating point model
    would not be IEEE (because the vendor has found another representation
    that is simpler to implement, or that allows higher performances, or
    whatever), but with a compiler that also provides emulated IEEE kinds for compatibility purposes. Then selected_real_kind() may return an emulated
    kind even for usual precisions...

    Also in theory the result of selected_real_kind() could be a kind that is neither REAL nor DOUBLE PRECISION. But if your code is calling libraries
    such as BLAS/LAPACK, you really want only one of these two...

    What I mean here is that in practice, the usage of all the kind system
    rely on some assumptions about the hardware. It's OK because we have
    nowadays quite standardized machines, but we tend to forget that we are
    making assumptions.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to pehache on Mon Jun 20 12:39:06 2022
    On 6/20/22 11:06 AM, pehache wrote:
    Also in theory the result of selected_real_kind() could be a kind that
    is neither REAL nor DOUBLE PRECISION. But if your code is calling
    libraries such as BLAS/LAPACK, you really want only one of these two...

    This is a shortcoming of the implementation of the BLAS and LAPACK
    libraries. They were designed to support the real and double precision
    provided by fortran in the 1970s and 1980s, and nothing else.


    What I mean here is that in practice, the usage of all the kind system
    rely on some assumptions about the hardware. It's OK because we have
    nowadays quite standardized machines, but we tend to forget that we are making assumptions.

    I think the fortran kind system is quite open ended and well designed.
    When combined with explicit interfaces, which prevent mistakes
    associated with mismatched arguments, it seems hard to beat the design.
    Take for example, the two 8-byte floating point representations
    supported by the VAX computers in the 1980s. It was very difficult
    within a program to either switch back and forth between those data
    types or to have a program that allowed mixtures. Instead, you basically compiled your code either one way or the other, and took whatever that produced. The modern fortran kind system would have solved both of those problems. Of course, Ken Olsen, who was CEO of DEC in the 1980s, opposed
    modern fortran, so that support never happened during the VAX lifetime.

    The problem I see with fortran isn't the kind system, which allows the programmer to mix kinds within expressions with complete control, rather
    it is the complications that come from the library support of those
    kinds. If a compiler has, say 10 different real kinds, then it is
    required to support all of the intrinsics for each of those kinds, all
    the exp and log functions, all the trig functions, all the Bessel
    functions, and so on, for both real and complex types. That seems like a
    high hurdle. I don't know what the answer is for this. Maybe the
    language should have two types of support, one just a subset for simple operations, and the other level being the full support as it is now.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Beliavsky on Mon Jun 20 18:57:29 2022
    On Saturday, April 9, 2022 at 7:05:29 AM UTC-7, Beliavsky wrote:
    Since compilers treat the non-standard but very common

    real*4, real*8, integer*4, integer*8

    I just notice that there is no mention of COMPLEX*8, COMPLEX*16, and even COMPLEX*32.

    Should we have those, too?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pehache@21:1/5 to All on Tue Jun 21 13:04:06 2022
    Le 20/06/2022 à 19:39, Ron Shepard a écrit :
    On 6/20/22 11:06 AM, pehache wrote:
    Also in theory the result of selected_real_kind() could be a kind that
    is neither REAL nor DOUBLE PRECISION. But if your code is calling
    libraries such as BLAS/LAPACK, you really want only one of these two...

    This is a shortcoming of the implementation of the BLAS and LAPACK
    libraries. They were designed to support the real and double precision provided by fortran in the 1970s and 1980s, and nothing else.

    Whatever, this is something that should be addressed, as legacy has
    always been something to care about in Fortran.

    For instance :

    selected_real_kind(p,r,list) where list would be an optional array of
    kinds we want to chose from

    or a "double" kind value provided by ISO_FORTRAN_ENV (or stdlib_kind at
    the moment), which would have at leasts 10 digits precison and that
    would be either kind(1.0) or kind(1.0d0)

    By the way, as long as there's no full generic programming in Fortran,
    writing libraries for all possible kinds that can be encountered is not
    easy.

    I don't know what the answer is for this. Maybe the
    language should have two types of support, one just a subset for simple operations, and the other level being the full support as it is now.

    Let's say that REAL and DOUBLE PRECISION must have full support, and the
    rest don't have to... :)


    --
    "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
    même sens que les tiennes.", ST sur fr.bio.medecine
    ST passe le mur du çon : <j3nn2hFmqj7U1@mid.individual.net>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Ron Shepard on Tue Jun 21 05:35:41 2022
    On Monday, June 20, 2022 at 10:39:10 AM UTC-7, Ron Shepard wrote:

    (snip)

    I think the fortran kind system is quite open ended and well designed.
    When combined with explicit interfaces, which prevent mistakes
    associated with mismatched arguments, it seems hard to beat the design.

    I suppose, but it leaves out that you often don't know the kind needed.

    Maybe it is more obvious for integers. They need to be big enough
    for whatever you might want to count. And you might know now how
    big is enough, but maybe not forever, when your program might be
    used by someone else. 32 bit integers are big enough for the
    size (one dimension) of a square matrix, but maybe not for the
    number of elements. 16 bit integers are not big enough for
    storing a US (five digit) zip code.

    For floating point, very little is built to better than single
    precision. (About 1mm per km, or 1s per day, or one gram
    per ton.) But very often double precision intermediates
    are needed to get single precision results. That is true
    for many matrix algorithms, and often for numerical
    derivatives.

    Sometimes we know that four or five digits is good
    enough, but that isn't enough reason to rewrite the
    program to use that precision. (Assuming that there
    is hardware to supply it.)

    Most often, algorithms are written to "good enough"
    precision.

    You could write REAL(SELECTED_REAL_KIND(8)) when you knew
    that 8 digits was enough, and that you didn't need 12 or 14.

    But since 8 digit hardware is rare, might as well just use the
    usual hardware precision of about 52 significant bits.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to pehache on Tue Jun 21 06:07:04 2022
    On Saturday, June 18, 2022 at 3:36:34 PM UTC+10, pehache wrote:
    Le 18/06/2022 à 04:21, Robin Vowels a écrit :

    I used to write:

    integer, parameter :: sp = kind(1.0)
    integer, parameter :: dp = kind(1.0d0)
    integer, parameter :: sp_is_enough = min(max(precision(sp)-9,1),0)
    integer, parameter :: double = sp*sp_is_enough + dp*(1-sp_is_enough)
    .
    This last line won't work in some compilers.
    .
    Isn't it a constant expression ?
    .
    0004) integer, parameter :: sp_is_enough = min(max(precision(sp)-9,1),0)
    *** The first argument (X) to the intrinsic PRECISION must be of REAL or
    COMPLEX type, not INTEGER(KIND=3)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pehache@21:1/5 to All on Tue Jun 21 17:10:20 2022
    Le 21/06/2022 à 15:07, Robin Vowels a écrit :
    On Saturday, June 18, 2022 at 3:36:34 PM UTC+10, pehache wrote:
    Le 18/06/2022 à 04:21, Robin Vowels a écrit :

    I used to write:

    integer, parameter :: sp = kind(1.0)
    integer, parameter :: dp = kind(1.0d0)
    integer, parameter :: sp_is_enough = min(max(precision(sp)-9,1),0)
    integer, parameter :: double = sp*sp_is_enough + dp*(1-sp_is_enough)
    .
    This last line won't work in some compilers.
    .
    Isn't it a constant expression ?
    .
    0004) integer, parameter :: sp_is_enough = min(max(precision(sp)-9,1),0)
    *** The first argument (X) to the intrinsic PRECISION must be of REAL or
    COMPLEX type, not INTEGER(KIND=3)

    Ah, yes, on the *third* line it should be "precision(1.0)" and not "precision(sp)"

    --
    "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
    même sens que les tiennes.", ST sur fr.bio.medecine
    ST passe le mur du çon : <j3nn2hFmqj7U1@mid.individual.net>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to All on Tue Jun 21 10:56:15 2022
    On 6/21/22 7:35 AM, gah4 wrote:
    On Monday, June 20, 2022 at 10:39:10 AM UTC-7, Ron Shepard wrote:

    (snip)

    I think the fortran kind system is quite open ended and well designed.
    When combined with explicit interfaces, which prevent mistakes
    associated with mismatched arguments, it seems hard to beat the design.

    I suppose, but it leaves out that you often don't know the kind needed.

    Maybe it is more obvious for integers. They need to be big enough
    for whatever you might want to count. And you might know now how
    big is enough, but maybe not forever, when your program might be
    used by someone else. 32 bit integers are big enough for the
    size (one dimension) of a square matrix, but maybe not for the
    number of elements. 16 bit integers are not big enough for
    storing a US (five digit) zip code.

    Selected_int_kind(5) is enough to hold current zip codes, and if the
    post office were to add another digit, then selected_int_kind(6) would
    be sufficient. In this case, one does know the number of digits in
    advance. I've used machines in the past that supported 3-byte integers, although that was before f90 was available. That kind value can be
    specified in a single place, and then propagated throughout your code,
    so if the usps does add that digit, you only need to change a single
    character in your source code, recompile, and you are good to go.


    For floating point, very little is built to better than single
    precision. (About 1mm per km, or 1s per day, or one gram
    per ton.) But very often double precision intermediates
    are needed to get single precision results. That is true
    for many matrix algorithms, and often for numerical
    derivatives.

    Yes, but these are comments about floating point arithmetic. Sometimes
    you need more mantissa bits, sometimes you need more exponent bits,
    sometimes you need both.


    Sometimes we know that four or five digits is good
    enough, but that isn't enough reason to rewrite the
    program to use that precision. (Assuming that there
    is hardware to supply it.)

    Most often, algorithms are written to "good enough"
    precision.

    You could write REAL(SELECTED_REAL_KIND(8)) when you knew
    that 8 digits was enough, and that you didn't need 12 or 14.

    Those machines that supported 3-byte integers also supported 6-byte
    reals. That was sufficient for a lot of numerical work, but I think it
    failed in a few places such as the ones you mention where extra
    precision is necessary.


    But since 8 digit hardware is rare, might as well just use the
    usual hardware precision of about 52 significant bits.

    Yes, this is the way floating point arithmetic is done typically. It
    doesn't hurt much to use more precision than necessary, but it is
    catastrophic to try to use too little precision. The exception is when
    the additional precision is localized within the algorithm, such as an
    extended precision accumulator, then you might see code that is written
    in a more targeted and specific way. The other exception was back in the
    1970s when memory was scarce. Then you might see minicomputer codes
    where every integer and real declaration had a (2), (4), or (8), because
    if they used integer(4) and real(8) everywhere, the program would not fit.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to pehache on Tue Jun 21 10:24:34 2022
    On 6/21/22 6:04 AM, pehache wrote:
    Le 20/06/2022 à 19:39, Ron Shepard a écrit :
    On 6/20/22 11:06 AM, pehache wrote:
    Also in theory the result of selected_real_kind() could be a kind
    that is neither REAL nor DOUBLE PRECISION. But if your code is
    calling libraries such as BLAS/LAPACK, you really want only one of
    these two...

    This is a shortcoming of the implementation of the BLAS and LAPACK
    libraries. They were designed to support the real and double precision
    provided by fortran in the 1970s and 1980s, and nothing else.

    Whatever, this is something that should be addressed, as legacy has
    always been something to care about in Fortran.

    Note that some vendors supported 128-bit floating point arithmetic even
    in the 1970s and early 1980s when these libraries were first developed.
    They did extend the use to double precision complex, a common extension
    that was not part of standard fortran, but they did not account for any
    other real or complex kinds. Now that the kind facility is available,
    this could be done in a straightforward way, but that hasn't occurred in
    the 30+ years since f90 has been available. I'm just guessing about
    this, but I think the reason is that the source code is available, so if
    some individual wanted a 128-bit floating point version of some linear
    algebra code, he could do the work himself.


    For instance :

    selected_real_kind(p,r,list) where list would be an optional array of
    kinds we want to chose from

    or a "double" kind value provided by ISO_FORTRAN_ENV (or stdlib_kind at
    the moment), which would have at leasts 10 digits precison and that
    would be either kind(1.0) or kind(1.0d0)

    This is already what selected_real_kind(10) does. If there are more than
    one choice, then maybe it doesn't return the one the programmer might
    want, but then the other exponent and base arguments can be added to
    refine the selection. In any case, this only needs to be done once in a program, and it propagates throughout the code from that one place.


    By the way, as long as there's no full generic programming in Fortran, writing libraries for all possible kinds that can be encountered is not
    easy.

    If a programmer wants to manually specify the kinds, then it is not too difficult. If he wants to automate the process, and produce different
    numbers of kind versions on different machines, then it is more
    difficult. And then if the programmer wants to allow mixed-kind
    arguments, including various combinations of integer, real, and complex
    kinds, it becomes truly a difficult process.


    I don't know what the answer is for this. Maybe the language should
    have two types of support, one just a subset for simple operations,
    and the other level being the full support as it is now.

    Let's say that REAL and DOUBLE PRECISION must have full support, and the
    rest don't have to... :)

    What I meant was some simple operations (+-*/><) along with some subset
    of conversions and query functions (int(), real(), cmplx(), precision(), max_val(), min_val(), nearest(), and so on). If the compiler supported
    that minimal subset of operations on a kind value, then the programmer
    could go from there and do whatever else was necessary, complex log
    functions or whatever, entirely within that supported subset of
    operations. There would be no need to write assembler language or use interfaces to other languages, it could all be done within fortran. An interface to the function could extend the intrinsic functions, and from
    there the programmer could access it the same way as if that kind were supported in the language.

    BTW, that kind of formalized minimal support for some KIND might also be
    a way to allow unsigned integers and bit strings into the language. They
    would be second class passengers in the language compared to the other integers, but that subset would allow them to be used where they are
    needed, without blowing up the rest of the language.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to All on Wed Jun 22 12:53:30 2022
    On 6/20/2022 8:57 PM, gah4 wrote:
    On Saturday, April 9, 2022 at 7:05:29 AM UTC-7, Beliavsky wrote:
    Since compilers treat the non-standard but very common

    real*4, real*8, integer*4, integer*8

    I just notice that there is no mention of COMPLEX*8, COMPLEX*16, and even COMPLEX*32.

    Should we have those, too?

    And logical*4 and logical*8.

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pehache@21:1/5 to just on Thu Jun 23 10:55:28 2022
    Le 21/06/2022 à 17:24, Ron Shepard a écrit :
    On 6/21/22 6:04 AM, pehache wrote:
    Le 20/06/2022 à 19:39, Ron Shepard a écrit :
    On 6/20/22 11:06 AM, pehache wrote:
    Also in theory the result of selected_real_kind() could be a kind
    that is neither REAL nor DOUBLE PRECISION. But if your code is
    calling libraries such as BLAS/LAPACK, you really want only one of
    these two...

    This is a shortcoming of the implementation of the BLAS and LAPACK
    libraries. They were designed to support the real and double precision
    provided by fortran in the 1970s and 1980s, and nothing else.

    Whatever, this is something that should be addressed, as legacy has
    always been something to care about in Fortran.

    Note that some vendors supported 128-bit floating point arithmetic even
    in the 1970s and early 1980s when these libraries were first developed.
    They did extend the use to double precision complex, a common extension
    that was not part of standard fortran, but they did not account for any
    other real or complex kinds. Now that the kind facility is available,
    this could be done in a straightforward way, but that hasn't occurred in
    the 30+ years since f90 has been available. I'm just guessing about
    this, but I think the reason is that the source code is available, so if
    some individual wanted a 128-bit floating point version of some linear algebra code, he could do the work himself.

    The main reason is that there is not something like a unified hardware
    support for quadruple precision. If one writes a library and wants to
    provide binaries for a platform that has no hardware support for quadruple precision, what should one do? One can compile the library with a compiler
    that has a real128 kind, but without any guarantee that it will work if
    the compiled library is called from a code compiled with another compiler,
    as different compilers may use different interpretation of real128
    (ieee-754 compliant, or as "double double", or as the x86 10 bytes
    floating point padded to 16 bytes, ...).


    For instance :

    selected_real_kind(p,r,list) where list would be an optional array of
    kinds we want to chose from

    or a "double" kind value provided by ISO_FORTRAN_ENV (or stdlib_kind at
    the moment), which would have at leasts 10 digits precison and that
    would be either kind(1.0) or kind(1.0d0)

    This is already what selected_real_kind(10) does.

    No, it does not ensure that the result is necessarily kind(1.0) or
    kind(1.0d0)

    If there are more than
    one choice, then maybe it doesn't return the one the programmer might
    want, but then the other exponent and base arguments can be added to
    refine the selection.

    If the programmer knows what specific kind he wants beforehand, there's
    simply no reason at all to use selected_real_kind()

    It's like:
    - "From now I want you to recruit from anonymous CVs"
    - "OK, but really I'd like to hire this guy at the end"
    - "No problem, just write job requirements that exactly correspond to his skills"

    :)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to pehache on Thu Jun 23 05:46:07 2022
    On Thursday, June 23, 2022 at 3:55:32 AM UTC-7, pehache wrote:

    (snip)

    No, it does not ensure that the result is necessarily kind(1.0) or kind(1.0d0)

    Yes. But the big assumption with SELECTED_REAL_KIND is
    that you know how many digits you need. In numerical
    algorithms, that is fairly rare. With most matrix routines,
    there is precision loss with subtraction, but you never
    known when, where, or how much.

    If you are lucky enough to know how many digits you
    need in the end, you still don't know how much for
    intermediate calculations.

    The result is that, most of the time, you have to
    assume kind(1.0) and kind(1.d0).

    IBM has consistently supplied REAL*16 with the 360/85
    and all 370 and successors. VAX has H_FLOAT, but
    it might be in software emulation.

    (Actually, for a long time IBM did DXR, that is,
    extended precision divide, in software emulation,
    even when the hardware had the rest. They did
    a study to show that was good enough, enough
    of the time. But then later, late ESA/390 days,
    added it.)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to pehache on Thu Jun 23 05:21:43 2022
    On Thursday, June 23, 2022 at 8:55:32 PM UTC+10, pehache wrote:
    Le 21/06/2022 à 17:24, Ron Shepard a écrit :
    On 6/21/22 6:04 AM, pehache wrote:
    Le 20/06/2022 à 19:39, Ron Shepard a écrit :
    On 6/20/22 11:06 AM, pehache wrote:
    Also in theory the result of selected_real_kind() could be a kind
    that is neither REAL nor DOUBLE PRECISION. But if your code is
    calling libraries such as BLAS/LAPACK, you really want only one of
    these two...

    This is a shortcoming of the implementation of the BLAS and LAPACK
    libraries. They were designed to support the real and double precision >>> provided by fortran in the 1970s and 1980s, and nothing else.

    Whatever, this is something that should be addressed, as legacy has
    always been something to care about in Fortran.

    Note that some vendors supported 128-bit floating point arithmetic even
    in the 1970s and early 1980s when these libraries were first developed. They did extend the use to double precision complex, a common extension that was not part of standard fortran, but they did not account for any other real or complex kinds. Now that the kind facility is available,
    this could be done in a straightforward way, but that hasn't occurred in the 30+ years since f90 has been available. I'm just guessing about
    this, but I think the reason is that the source code is available, so if some individual wanted a 128-bit floating point version of some linear algebra code, he could do the work himself.
    The main reason is that there is not something like a unified hardware support for quadruple precision. If one writes a library and wants to provide binaries for a platform that has no hardware support for quadruple precision, what should one do? One can compile the library with a compiler that has a real128 kind, but without any guarantee that it will work if
    the compiled library is called from a code compiled with another compiler, as different compilers may use different interpretation of real128
    (ieee-754 compliant, or as "double double", or as the x86 10 bytes
    floating point padded to 16 bytes, ...).
    For instance :

    selected_real_kind(p,r,list) where list would be an optional array of
    kinds we want to chose from

    or a "double" kind value provided by ISO_FORTRAN_ENV (or stdlib_kind at >> the moment), which would have at leasts 10 digits precison and that
    would be either kind(1.0) or kind(1.0d0)

    This is already what selected_real_kind(10) does.
    No, it does not ensure that the result is necessarily kind(1.0) or kind(1.0d0)
    If there are more than
    one choice, then maybe it doesn't return the one the programmer might want, but then the other exponent and base arguments can be added to refine the selection.
    If the programmer knows what specific kind he wants beforehand, there's simply no reason at all to use selected_real_kind()

    The point of using the kind system is that you don't need to know in advance what kinds are available. SELECTED_REAL_KIND helps to do that.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Quadibloc@21:1/5 to steve kargl on Thu Jun 23 11:05:41 2022
    On Tuesday, April 12, 2022 at 10:17:23 AM UTC-6, steve kargl wrote:
    Ron Shepard wrote:

    I think the problem people have is that it is stored in 16 bytes, so
    there is a lot of wasted memory and/or file space.

    Then those people are blaming the wrong thing. Intel choose 4, 8, and 16-byte alignment in their ABIs. gfortran (and gcc) are just a tool sitting above the cpu.

    If people avoid using Intel's temporary real format because it wastes space, they would do so regardless of whether it's the compiler or the hardware that is to blame, so I don't see how the fact that they're avoiding it means that they're
    blaming the compiler.

    John Savard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Quadibloc@21:1/5 to Robin Vowels on Thu Jun 23 11:03:11 2022
    On Monday, April 11, 2022 at 3:21:33 AM UTC-6, Robin Vowels wrote:
    On Sunday, April 10, 2022 at 3:35:25 PM UTC+10, JCampbell wrote:

    real(dp) or real(kind=dp) is not clear,
    .
    in what way? "dp" is used often enough that it is immediately clear
    that it signifies double precision.

    My quarrel with it is that it is redundant. DOUBLE PRECISION is already
    in existence in the language; the syntax real(...) is for when you want to specify by length instead.

    John Savard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Quadibloc@21:1/5 to john.c...@simconglobal.com on Thu Jun 23 11:15:40 2022
    On Wednesday, April 13, 2022 at 12:41:22 PM UTC-6, john.c...@simconglobal.com wrote:
    To that end REAL*8 is the best we have got, it works everywhere (at least that I know of)
    and doesn't need to be in the standard if everyone understands it.

    On the FORTRAN compiler for the IBM System/360, IBM added length specifications as
    an extension to the standard. It allowed them to define COMPLEX*16, since DOUBLE
    COMPLEX was not yet part of the standard at the time. And it allowed them to define
    LOGICAL*1 in addition to LOGICAL*4 (the default), and INTEGER*2 in addition to INTEGER*4.

    This extension served a purpose in its day. But it was not intended to be _portable_.

    So on a machine with addressable 6-bit characters, REAL might be REAL*6 or REAL*8,
    and DOUBLE PRECISION might be REAL*12 or REAL*16. Or even REAL*10.

    Of course, these days, byte addressing and power-of-two word sizes are nigh universal.

    John Savard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Quadibloc@21:1/5 to pehache on Thu Jun 23 11:46:12 2022
    On Sunday, June 19, 2022 at 3:15:52 PM UTC-6, pehache wrote:

    Early support for f90, maybe... But even in the 1990s f90 was not that popular in high performance computing (for sometimes good, sometimes bad reasons). The recommandation where I was working (as a PhD student) was
    to stick to f77. So the lack of f90 features on the Cray was not a big problem I guess.

    And that is history repeating itself. IBM's FORTRAN II compiler for the 7090 had the same excellent optimization as the original FORTRAN for the 704,
    but when IBM brought in a FORTRAN IV compiler, it wasn't optimized. So
    people had to use FORTRAN II for serious work.

    John Savard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Quadibloc@21:1/5 to Ron Shepard on Thu Jun 23 11:57:18 2022
    On Monday, June 20, 2022 at 11:39:10 AM UTC-6, Ron Shepard wrote:

    The problem I see with fortran isn't the kind system, which allows the programmer to mix kinds within expressions with complete control, rather
    it is the complications that come from the library support of those
    kinds. If a compiler has, say 10 different real kinds, then it is
    required to support all of the intrinsics for each of those kinds, all
    the exp and log functions, all the trig functions, all the Bessel
    functions, and so on, for both real and complex types. That seems like a
    high hurdle. I don't know what the answer is for this. Maybe the
    language should have two types of support, one just a subset for simple operations, and the other level being the full support as it is now.

    Generally speaking, though, that isn't a problem one encounters in
    real life. FORTRAN compilers would allow use of those hardware floating-point types that are relevant to the kinds of computation FORTRAN is for.

    The kind system deals with another problem: since some machines
    might have 32-bit single precision, and 64-bit double precision, and others might have 64-bit single precision and 128-bit double precision, a way is provided to use the 64-bit reals on both kinds of machine by specifying that one wants at least 15 (or even 12) decimal digits of precision.

    John Savard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Quadibloc on Thu Jun 23 13:02:42 2022
    On Thursday, June 23, 2022 at 11:57:22 AM UTC-7, Quadibloc wrote:

    (snip)

    The kind system deals with another problem: since some machines
    might have 32-bit single precision, and 64-bit double precision, and others might have 64-bit single precision and 128-bit double precision, a way is provided to use the 64-bit reals on both kinds of machine by specifying that one wants at least 15 (or even 12) decimal digits of precision.

    Most of those are now in museums, running or not.

    It looks to me, though, that IEEE 754 decimal floating point considers
    the 64 bit form single precision, and the 128 bit as double precision.

    There are 16 bit binary, 256 bit binary, and 32 bit decimal forms that
    are called "not-basic".

    It looks to me that Fortran compilers implementing it would use
    the 64 bit and 128 bit formats for REAL and DOUBLE PRECISION.

    We will have to see when those compilers come out.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to Quadibloc on Thu Jun 23 20:42:40 2022
    Quadibloc <jsavard@ecn.ab.ca> schrieb:
    On Monday, April 11, 2022 at 3:21:33 AM UTC-6, Robin Vowels wrote:
    On Sunday, April 10, 2022 at 3:35:25 PM UTC+10, JCampbell wrote:

    real(dp) or real(kind=dp) is not clear,
    .
    in what way? "dp" is used often enough that it is immediately clear
    that it signifies double precision.

    My quarrel with it is that it is redundant. DOUBLE PRECISION is already
    in existence in the language; the syntax real(...) is for when you want to specify by length instead.

    Not with all compilers (nagfor being one example).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jfh@21:1/5 to Quadibloc on Thu Jun 23 13:44:05 2022
    On Friday, June 24, 2022 at 6:15:44 AM UTC+12, Quadibloc wrote:
    On Wednesday, April 13, 2022 at 12:41:22 PM UTC-6, john.c...@simconglobal.com wrote:
    To that end REAL*8 is the best we have got, it works everywhere (at least that I know of)
    and doesn't need to be in the standard if everyone understands it.

    On the FORTRAN compiler for the IBM System/360, IBM added length specifications as
    an extension to the standard. It allowed them to define COMPLEX*16, since DOUBLE
    COMPLEX was not yet part of the standard at the time. And it allowed them to define
    LOGICAL*1 in addition to LOGICAL*4 (the default), and INTEGER*2 in addition to
    INTEGER*4.

    This extension served a purpose in its day. But it was not intended to be _portable_.

    So on a machine with addressable 6-bit characters, REAL might be REAL*6 or REAL*8,
    and DOUBLE PRECISION might be REAL*12 or REAL*16. Or even REAL*10.

    Of course, these days, byte addressing and power-of-two word sizes are nigh universal.

    John Savard

    DOUBLE COMPLEX was not standard f77 and is not standard f18. Last time I looked at NAG Fortran it did not use 4 and 8 for single and double precision unless one asked for a particular compiling option. When I don't know in advance what precision a given
    calculation will need I try all four of wp=selected_real_kind(n) where n is 6,15,18 or 33. That works well with gfortran but ifort treats 18 as if it were 33 because that compiler offers only three real kinds. I no longer have access to NAG because my
    university's systems people thought not enough people were using it to justify the cost.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pehache@21:1/5 to All on Fri Jun 24 08:22:54 2022
    Le 23/06/2022 à 14:21, Robin Vowels a écrit :


    The point of using the kind system is that you don't need to know in advance what kinds are available. SELECTED_REAL_KIND helps to do that.

    I get that, and that's not my point.

    --
    "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
    même sens que les tiennes.", ST sur fr.bio.medecine
    ST passe le mur du çon : <j3nn2hFmqj7U1@mid.individual.net>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)