Welcome to our forums
Only humanoids can comprehend large output numbers like this done with %rf
59813784709
which is approximately 5.98e10. But there is no Ex.y format in Clearwin. Can this be added?
I will add this to the wish list.
Dan,
My guess is that it is required on output not input, in which case it can be written to a character variable first.
If you really do need it for input, then you can presumably input the the powers of 10 separately from the decimal part in an %rf and a %rd. That also works better with %il, as each box would have its own 2 limits - an E format box needs 4.
Eddie
Thanks you Paul and Eddie, I played further and I think the problem can be more or less satisfactory solved if force %rf to use smaller amount of digits, i.e. use %7rf instead of %rf if this variable intended only for the output. See example below (of course full fledged Ex.y format would be better)
Also I had some problems with %wf, why I use %rf 1000x more often. May be I do something wrong with it. Look at this text sample, the %wf does not react on number of digits
real*8 x
x= 12345678901.123456789
i = winio@('X rf %ta%rf %ff&', x)
i = winio@('X 7rf %ta%7rf%ff&', x)
i = winio@('X 8rf %ta%8rf%ff&', x)
i = winio@('X 9rf %ta%9rf%ff&', x)
i = winio@('X 10rf %ta%10rf%ff&',x)
i = winio@('X 11rf %ta%11rf%ff&',x)
i = winio@('X 12rf %ta%12rf%ff&',x)
i = winio@('X wf %ta%wf %ff&', x)
i = winio@('X 7wf %ta%7wf%ff&', x)
i = winio@('X 8wf %ta%8wf%ff&', x)
i = winio@('X 9wf %ta%9wf%ff&', x)
i = winio@('%es')
end
Another hopefully small problem is that despite Real*8 declaration for X both %rf and %wf treat X as single precision
Add 'D0' to the end of the second line.
Without that, or some other way of signifying that the value is double precision, the decimal number is first converted to a 32-bit REAL, which causes some digits to be lost, and then converted to 64-bit REAL on assignment.
As to accuracy you are right, Mecej4. Since i am stepping on the same rake already 1000 times i suggest developers to make the following 'Warning: such assignment of variable X will lead to the lose of accuracy because by default the values without explicit descriptors are cut to single precision even if declared as double precision. To fix this use double precision descriptor like in 1.23D0' (I like verbose warning and comments, they are less cryptic)
I have made a note of this.
A simple assignment like either of the following will now produce a compiler warning...
double precision:: x = 1.83932434324
x = 1.83932434324
But you will get the same warning with...
double precision:: x = 1.0
x = 1.0
which could be a little off putting.
Great, thanks. As to the numbers like 0., 1., 2., 4. etc how about that compiler checks if the number is 0, 1 and the exact multiple of factor of 2 and does not give the warning? Or just makes a comment that for all other numbers here could be a hidden problem which is often hard to find if user forgets adding D specifier to declare the number at the larger precision (in /VERBOSE mode for the errors)
I don't understand why the F90 standard chose to send us down this path. Why should the following be interpreted differently !! double precision:: x = 1.83932434324 double precision:: y = 1.83932434324D0
Agree, this is an utter absurd of Standard. The intention of the user is clear and was demonstrated two times in stating double precision and giving variable more then 7 digits, yet standard formally push to change that to single precision without even error/warning. Eventually all will more often use double precision numbers and of course omitting D0 will happen more often.
Good this was fixed. But in this case I'd even prefer error message as I never read warnings. When will have time to clean the code I will probably use compiler switch to treat tens of thousands of different warnings as errors.
There is a certain logic to it, because constants are single precision unless stated otherwise, just as REAL is single precision.
OPTIONS (DREAL) helps.
Take for example:
OPTIONS (DREAL)
PROGRAM T
DOUBLE PRECISION A
A = 1.234567890123456789
WRITE (*, '(E24.19)') A
END
gives
.1234567890123456690E+01
which seems to me to be the double precision version of the constant, even though it is not exactly as coded, because even the precision of a DOUBLE PRECISION constant (I vaguely remember 15 or so significant figures) has been exceeded.
Eddie
This has now been fixed so that the warning is not generated for short values.
Great. And appeared on Saturday 😃 Scientists and engineers who don't work on Saturdays do not work at all - this phrase my colleagues assign to me but I don't remember when I said this (very possible ... as the very true is that the supercomputers were always less busy at weekends, so you do in two days the job of entire week, and in two holidays weeks the work of next 6 months ). Life shows this is very right though on everything else. This is how I select people to work with.
This compiler now finds so many subtlest potential problems that if someone has some large code written with other compiler, it most probably just produces plain wrong numbers. I said that before, it now is even more true
Eddie,
Commenting out DREAL shows the problem. .1234567880630493164E+01
Why should the standard enforce this unfriendly response ? Lots of new users are tricked by this and produce inaccurate results that are not easy to find. It is like dealing with the IT dept.
John,
The Fortran 90 standard says that you can't. You could provide such an option, but it would not be portable and would be a bad approach for maintaining the code. It is all a bit ridiculous. consider the following example:
Real*8 s,x
integer i
s = 0 ; x = 0.1
do i = 1,10
s = s+x
end do
write (*,*) s
s = 0 ; x = 0.1d0
do i = 1,10
s = s+x
end do
write (*,*) s
end
Just looking at the code, does not scream out a precision problem, but 0.1 does round to only 7 figures of accuracy, while with Dan's example you can see that more than 7 figures are implied.
Come on guys, be sensible. The default precision for a REAL constant is the default REAL type, which is REAL*4. There's no such thing as a DOUBLE PRECISION constant without the D part.
If you want to make the default for variables AND constants REAL*8, then you use the DREAL option in an OPTION statement.
It isn't a problem, the former is part of Fortran, the latter is part of FTN95. The selection of REAL4 to be the default real precision is the fault of computer designers: on the UK-designed systems it was REAL6 (2 x 24-bit words) before that line of thinking was forced out of the market.
The associated problem is that REAL4 isn't much use for anything that is calculated, and often isn't for anything that is input as data. As an example, consider ground coordinates that need to be specified in mm on a national coordinate system. REAL4 is OK in the SW of England (a small country) but coordinates become rounded as one passes Salford, and totally inaccurate in Scotland! However, for coordinates of points on a a car, they can be specified in hundreds of a mm with REAL4. But for my purposes, REAL4 is usually pointless.
It strikes me that if REAL4 and INTEGER4 are the defaults for 32-bit computing (where addressing is via INTEGER4 length addresses), the REAL8 and INTEGER*8 should be the defaults for 64-bit computing, even though one then has the problem that DOUBLE PRECISION ought to be 128 bits, and the x86 cpus don't seem to have got to that.
In any case, it seems to me that the OPTIONS statement needs the possibility of an INTx to go with INTL and INTS (perhaps there is, I haven't looked).
Eddie
Eddie,
You may be correct. The problem is the FTN compilers would treat the following differently to F90 (and I suspect F77)
real*8 x
x = 1.83932434324
x = 0.1
In both cases, the old compiler's interpretation of the constant would have retained real8 precision. This is in the past, so my memory may be failing, but when the Fortran standard required these constants to be stored as real4, there was a loss of accuracy in a number of programs when converted from FTN to F77. The loss of precision reinforced the view that the newer compiler was not as good as the old one, as it generated less accurate calculations in benchmark comparisons. We've all been there !!
There was another significant event when programs lost precision and that was when real*10 registers disappeared, so again upgrading programs produced an increase in calculated round-off error.
Yes. The quick and easy way is to use /DREAL on the FTN95 command line and this feature was ported from FTN77.
It looks to me that /DREAL is the sensible way to go, as it basically says that REAL is REAL8, and that DOUBLE PRECISION means the same as REAL. This is fine by me, as I don''t have any use for REAL16 - if REAL8 isn't enough, then I would look for a different algorithm. (REAL16 being DOUBLE PRECISION if REAL*8 is the default REAL).
The compiler can't be a mind-reader, but it does seem logical that the assumed intent of a programmer assigning a more precise than REAL4 constant to a REAL8 variable should imply that it is a REAL*8 constant, standard conforming or not, so it depends on whether one wants strictness - which is available with /ISO - or a bit of mind-reading.
Whether the telepathic version should be implemented, it would be consistent wit the treatment of INTEGET constants - see FTN95.CHM description of INTS - which sets integer constants to INTEGER2 UNLESS they exceed the range for INTEGER2. The compiler options section notes that /DEFREAL_KIND behaves unlike DEFINT_KIND.
Incidentally, with the Win32 version, there is an /XREAL as well.
While one loses x87 80-bit registers and precision to use SSE etc, this is how Intel designed it, and as most processors are used for Facebook or downloading porn, arithmetic precision is presumably not high on their list of priorities.
Eddie