Nп/п : 25 из 100
 От   : Clive Page                          2:5075/128        31 авг 23 12:03:03
 К    : Ron Shepard                                           31 авг 23 14:04:02
 Тема : Re: Real number precision in fortran
----------------------------------------------------------------------------------
                                                                                 
@MSGID: <klbab8Fcec7U1@mid.individual.net>
bb417898
@REPLY: 8_8a.15539@fx48.iad>
0831f4ea
@REPLYADDR Clive Page <usenet@page2.eu>
@REPLYTO 2:5075/128 Clive Page
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID:
<klbab8Fcec7U1@mid.individual.net>
@RFC-References:
8_8a.15539@fx48.iad>
@TZUTC: 0100
@PID: Mozilla/5.0 (Windows NT 10.0; Win64; x64;
rv:102.0) Gecko/20100101 Thunderbird/102.14.0
@TID: FIDOGATE-5.12-ge4e8b94
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
 --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.14.0
 * Origin: usenet.network (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441



   GoldED+ VK   │                                                 │   09:55:30    
                                                                                
В этой области больше нет сообщений.

Остаться здесь
Перейти к списку сообщений
Перейти к списку эх