On 8/27/23 8:52 AM, Kim Hanjoon wrote:
> Hi, I'm new at Fortran. I'm studying numerical analysis and I got question about real number precision
>
> program test
> real*8 x
>
> x = 1.0/3.0
>
> write(*,*) x
> stop
> end

First, let me rewrite your code in modern fortran and in an expanded form.

program testfp
use, intrinsic :: iso_fortran_env, only: real32, real64
real(real64) :: s
s = real( 1.0_real32 / 3.0_real32, kind=real64 )
write(*,*) s
end program testfp

There are of course many other ways to write this code, but this shows
explicitly what your code is doing. In the original expression, these
steps were all done implicitly by the compiler, so they might not be
obvious to a new fortran programmer.

Note that the assignment expression (the division) is evaluated in
real32 precision, and then that value is converted and assigned to the
real64 variable. That initial evaluation is where the precision was lost.

An important feature in fortran is that expressions are always evaluated
the same way, regardless of the type and kind of the lhs variable. Any
conversions, if necessary, are done just at the final assignment step.

If you want the expression to be evaluated entirely with real64
precision, then you would write it as something like

s = 1.0_real64 / 3.0_real64

There is no need for a conversion step, real(...,kind=real64), in this
assignment because the rhs and the lhs are both real64.

Hopefully, that explains the results that you see, and it shows you how
to change things if you want something different to be done.

Fortran gives the programmer complete control over the precision of
expression evaluation, so if the default evaluation and conversion rules
aren't what you want, you can always change the expression to do the
right thing.

$.02 -Ron Shepard

On 27/08/2023 18:38, Ron Shepard wrote:
> On 8/27/23 8:52 AM, Kim Hanjoon wrote:
>> Hi, I'm new at Fortran. I'm studying numerical analysis and I got question about real number precision
>>
>> program test
>> real*8 x
>>
>> x = 1.0/3.0
>>
>> write(*,*) x
>> stop
>> end
>
> First, let me rewrite your code in modern fortran and in an expanded form.
>
> program testfp
>    use, intrinsic :: iso_fortran_env, only: real32, real64
>    real(real64) :: s
>    s = real( 1.0_real32 / 3.0_real32, kind=real64 )
>    write(*,*) s
> end program testfp
>
> There are of course many other ways to write this code, but this shows explicitly what your code is doing. In the original expression, these steps were all done implicitly by the compiler, so they might not be obvious to a new fortran programmer.
>
> Note that the assignment expression (the division) is evaluated in real32 precision, and then that value is converted and assigned to the real64 variable. That initial evaluation is where the precision was lost.
>
> An important feature in fortran is that expressions are always evaluated the same way, regardless of the type and kind of the lhs variable. Any conversions, if necessary, are done just at the final assignment step.
>
> If you want the expression to be evaluated entirely with real64 precision, then you would write it as something like
>
>    s = 1.0_real64 / 3.0_real64
>
> There is no need for a conversion step, real(...,kind=real64), in this assignment because the rhs and the lhs are both real64.
>
> Hopefully, that explains the results that you see, and it shows you how to change things if you want something different to be done.
>
> Fortran gives the programmer complete control over the precision of expression evaluation, so if the default evaluation and conversion rules aren't what you want, you can always change the expression to do the right thing.
>
> $.02 -Ron Shepard

That is absolutely right. But what might be worth saying is that traditionally Fortran Standards have resolutely refused to specify the precision of arithmetic or the number of bits of storage. Almost since the start one could use REAL or DOUBLE PRECISION types, the latter now deprecated of course, but without being able to specify what they meant until fairly recently with functions like SELECTED_REAL_KIND. This used to be a serious problem. Some years ago I got code working on both a mini-computer and a mainframe where the DOUBLE PRECISION on the mini-computer had fewer digits than the REAL on the mainframe. And this was pefectly legal in the Fortran of the time, and indeed still would be if the hardware still existed.

What has changed is the introduction of the iso_fortran_env intrinsic module which means that Fortran programmers can finally catch up with the rest of the computing world, since pretty much all current processors offer the choice of 32-bits or 64-bits for their floating-point storage and arithmetic (plus other options in some cases). But the syntax for using them, as Ron Shepard showed above, is not very obvious ane really a bit verbose. It is only properly explained in a very few modern Fortran texts. Many old texts will mislead you badly.

It would be nice if we could get the next Fortran Standard written so that 32-bit and 64-bit arithmetic come by default, but I fear that this would break too much existing code for it to be possible.

--
Clive Page

On Thursday, August 31, 2023 at 4:03:09 AM UTC-7, Clive Page wrote:

(snip)

> That is absolutely right. But what might be worth saying is that traditionally Fortran
> Standards have resolutely refused to specify the precision of arithmetic or the
> number of bits of storage. Almost since the start one could use REAL or
> DOUBLE PRECISION types, the latter now deprecated of course, but without being
> able to specify what they meant until fairly recently with functions like
> SELECTED_REAL_KIND. This used to be a serious problem.
> Some years ago I got code working on both a mini-computer and a mainframe
> where the DOUBLE PRECISION on the mini-computer had fewer digits than the
> REAL on the mainframe.

(snip)

> It would be nice if we could get the next Fortran Standard written so that 32-bit
> and 64-bit arithmetic come by default, but I fear that this would break too much
> existing code for it to be possible.
From the beginning, or close to it, it was 36 and 72 bits.

But yes, the CDC 60 bit machines, and then Cray 64 bit machines, did complicate things.

I believe that they had to support software double precision to satisfy the standard,
even if nobody used it.

I have noticed, though, the for IEEE 754 decimal, the basic types are the 64 and 128 bit types.
I think that means that a Fortran compiler should support them as REAL and DOUBLE
PRECISION. Not that it wouldn't support others, though.

It does seem that hardware support of 128 bit binary types has been slow at arriving.

IBM supported 128 bits (in hexadecimal) from the 360/85 and all S/370 models.
And then ESA/390 added IEEE 754 binary types, they had 32, 64, and 128.

Also RISC-V has a 128 bit format, though I don't know which actual processors
that you can buy support it.

On Thursday, 31 August 2023 at 22:40:56 UTC+10, gah4 wrote:
> On Thursday, August 31, 2023 at 4:03:09 AM UTC-7, Clive Page wrote:
>
> (snip)
> > That is absolutely right. But what might be worth saying is that traditionally Fortran
> > Standards have resolutely refused to specify the precision of arithmetic or the
> > number of bits of storage. Almost since the start one could use REAL or
> > DOUBLE PRECISION types, the latter now deprecated of course, but without being
> > able to specify what they meant until fairly recently with functions like
> > SELECTED_REAL_KIND. This used to be a serious problem.
> > Some years ago I got code working on both a mini-computer and a mainframe
> > where the DOUBLE PRECISION on the mini-computer had fewer digits than the
> > REAL on the mainframe.
> (snip)
> > It would be nice if we could get the next Fortran Standard written so that 32-bit
> > and 64-bit arithmetic come by default, but I fear that this would break too much
> > existing code for it to be possible.
..
> From the beginning, or close to it, it was 36 and 72 bits.
..
From the beginning, it was 32 bit words.
Pilot ACE (1950) and DEUCE (1955) were 32/64 bit machines,.
'
> But yes, the CDC 60 bit machines, and then Cray 64 bit machines, did complicate things.
...
There were also 48-bit machines.
..
> I believe that they had to support software double precision to satisfy the standard,
> even if nobody used it.
>
> I have noticed, though, the for IEEE 754 decimal, the basic types are the 64 and 128 bit types.
> I think that means that a Fortran compiler should support them as REAL and DOUBLE
> PRECISION. Not that it wouldn't support others, though.
>
> It does seem that hardware support of 128 bit binary types has been slow at arriving.
>
> IBM supported 128 bits (in hexadecimal) from the 360/85 and all S/370 models.
> And then ESA/390 added IEEE 754 binary types, they had 32, 64, and 128.
>
> Also RISC-V has a 128 bit format, though I don't know which actual processors
> that you can buy support it.

On 8/31/23 7:40 AM, gah4 wrote:
> I believe that they had to support software double precision to satisfy the standard,
> even if nobody used it.

The ANSI f77 standard book was published so that when you opened a page,
the left hand side of the book was the standard subset, and the right
hand side page was the full standard. If I remember correctly, the
standard subset did not require support for double precision, complex,
or character types. I used a fortran compiler in the early 1980s that
supported complex and character but not double precision. Its REAL type
was 64-bit, so as you say, most programmers did not really need 128-bit
double precision. A subsequent compiler revision did eventually support
128-bit double precision using a mix of hardware and software, so it was
slow.

Nowadays, the de facto standard is that REAL is REAL32, which then means
that REAL64 is DOUBLE PRECISION. I do not know of any compiler in use
these days that contradicts that convention (unless compiler options are
specified). I doubt that the standard will incorporate that convention
due to the backwards compatibility issue and to the possibility that
someone might still want to write a modern fortran compiler for legacy
36-bit, 60-bit, or 64-bit hardware.

$.02 -Ron Shepard

Clive Page <usenet@page2.eu> schrieb:
> That is absolutely right. But what might be worth saying is that
> traditionally Fortran Standards have resolutely refused to specify
> the precision of arithmetic or the number of bits of storage.
> Almost since the start one could use REAL or DOUBLE PRECISION
> types, the latter now deprecated of course, but without being able
> to specify what they meant until fairly recently with functions
> like SELECTED_REAL_KIND.

"Fairly recently" meaning 1991, the year that Fortran 90 came out.
It's only been a bit more than 30 years.

By comparision, Java was released in 1996.

On 9/1/2023 11:16 AM, Thomas Koenig wrote:
> Clive Page <usenet@page2.eu> schrieb:
>> That is absolutely right. But what might be worth saying is that
>> traditionally Fortran Standards have resolutely refused to specify
>> the precision of arithmetic or the number of bits of storage.
>> Almost since the start one could use REAL or DOUBLE PRECISION
>> types, the latter now deprecated of course, but without being able
>> to specify what they meant until fairly recently with functions
>> like SELECTED_REAL_KIND.
>
> "Fairly recently" meaning 1991, the year that Fortran 90 came out.
> It's only been a bit more than 30 years.
>
> By comparision, Java was released in 1996.
1965 seems fairly recent to me, I remember tooling around in grandpas
1956 pontiac star chief :)

On Friday, September 1, 2023 at 9:16:35 AM UTC-7, Thomas Koenig wrote:
> Clive Page <use...@page2.eu> schrieb:

(snip)

> "Fairly recently" meaning 1991, the year that Fortran 90 came out.
> It's only been a bit more than 30 years.

> By comparision, Java was released in 1996.

Java not only specifies the size of the data types, but requires floating point to be IEEE 754 binary.

Rumor is that IBM added BFP (IEEE 754 binary) to ESA/390 so that it could run Java.

On Friday, September 1, 2023 at 9:16:35 AM UTC-7, Thomas Koenig wrote:
> Clive Page <use...@page2.eu> schrieb:

(snip)

> "Fairly recently" meaning 1991, the year that Fortran 90 came out.
> It's only been a bit more than 30 years.

> By comparision, Java was released in 1996.

My first Fortran programs were in 1972. Doesn't seem so long ago.

The IBM OS/360 Fortran manual was my 8th grade graduation present.