|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
Kenneth_Smith
Joined: 18 May 2012 Posts: 697 Location: Hamilton, Lanarkshire, Scotland.
|
Posted: Wed May 18, 2016 9:48 am Post subject: REAL*10 or selected_real_kind(18,4931) |
|
|
Out of curiosity I downloaded the updated compiler and tried to compile some existing code. Unfortunately I did not get very far (line 83 of 35,000).
Can somebody advise me on the status of extended precision floating point REAL*10 or selected_real_kind(18,4931) within the new 64 bit compiler?
Thanks
Ken |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Wed May 18, 2016 10:48 am Post subject: |
|
|
Extended precision is not support in the 64 bit compiler.
Details can be found in the file NotesOn64BitFtn95.txt that should be in the installed ftn95\doc folder. |
|
Back to top |
|
|
Kenneth_Smith
Joined: 18 May 2012 Posts: 697 Location: Hamilton, Lanarkshire, Scotland.
|
Posted: Wed May 18, 2016 11:05 am Post subject: |
|
|
Thanks Paul,
Is this a temporary position. Will real*10 be added later?
Regards
Ken |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Wed May 18, 2016 11:27 am Post subject: |
|
|
No it isn't temporary. I am not sure that it is feasible. Certainly it is not on the current list of things to do. Right now we are working on optimisation and run-time checking. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Wed May 18, 2016 11:49 am Post subject: |
|
|
Ken,
Real*10 is not well supported in 64 bit. gFortran provides real*10, but stores the values in a 16 byte format !! As far as I know, both real*10 and real*16 are only software supported in any windows 64 bit compiler. There is no hardware support for real*10 in 64 bit.
If you need further precision, you would need to find a high precision library for software support. There are strategies to accumulate errors in a sum (see Kahan summation algorithm), but again there can be problems with the precision of the numbers you are providing.
If you need further range; a number larger than 1.7976931E+308 then I have no solution.
I have removed all real*10 usage and have not found a problem with the precision of the real*8 alternative. This was not a hard decision, as my use of real*10 did not improve precision in practical terms.
I once tested a real*10 skyline solver but the real*10 matrix coefficients were the sum of element real*8 matrices, (which were probably based on real*4 parameters). The structural finite element test problem showed bad round-off errors with real*8, but the net result of the real*10 test was no change to the calculated precision of the solution.
John |
|
Back to top |
|
|
Kenneth_Smith
Joined: 18 May 2012 Posts: 697 Location: Hamilton, Lanarkshire, Scotland.
|
Posted: Wed May 18, 2016 4:12 pm Post subject: |
|
|
John,
Thanks for your useful insight on this.
Generally, for the last decade or so I have adopted REAL*8 as my default approach.
Recently I undertook some work using sum, products and quotients of Bessel/Kelvin functions and quickly got mired in precision overflow/underflow problems (In(x) tends to infinity and Kn(x) tends to zero).
Adopting REAL*10 KINDS was a very quick fix that avoided having to recast the equations in my solution to avoid these issues.
Regards
Ken |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Fri May 20, 2016 11:15 am Post subject: |
|
|
Ken,
I have a program to report the available KIND values a compiler supports for integer and real.
I suggest you could try it with FTN95 using the options:
ftn95 kind.f90 /lgo
ftn95 kind.f90 /lgo /64
ftn95 kind.f90 /lgo /alt_kinds
ftn95 kind.f90 /lgo /alt_kinds /64
You could also test it on other compilers to see what is available.
For example, with gfortran I use:
del %1.exe
del %1.o
gfortran %1.f90 -o %1.exe
%1
my test kind.f90 is:
Code: | Program kind_f90
integer*4 p,r, ik, lk
!
write (*,*) 'kind(0) ', kind(0)
write (*,*) 'kind(999999999) ', kind(999999999)
! write (*,*) 'kind(9999999999) ', kind(9999999999)
write (*,*) 'kind(0.) ', kind(0.)
write (*,*) 'kind(0.e0) ', kind(0.e0)
write (*,*) 'kind(0.d0) ', kind(0.d0)
!
11 format (a,' :digits = ',i0,' Kind = ',i0 )
12 format (a,' :digits = ',i0,' :range = ',i0,' Kind = ',i0)
lk = -1
do p = 1,10000
ik = selected_int_kind ( p )
if ( lk == ik ) cycle
write (*,11) 'Int ',p-1,lk
write (*,11) 'Int ',p,ik
lk = ik
if ( ik < 0 ) exit
end do
!
lk = -1
do p = 1,10000
ik = selected_real_kind ( p )
if ( lk == ik ) cycle
write (*,11) 'Real',p-1,lk
write (*,11) 'Real',p,ik
lk = ik
if ( ik < 0 ) exit
end do
!
lk = -1
p = 0
do r = 1,10000
ik = selected_real_kind ( p,r )
if ( lk == ik ) cycle
write (*,12) 'Real',p,r-1,lk
write (*,12) 'Real',p,r,ik
lk = ik
if ( ik < 0 ) exit
end do
end |
I find that gFortran's approach to real*10 of storing it in a 16 byte variable removes a lot of the advantage. You may as well use real*16 as both are supported by an extended precision library and so not suitable for a compute intensive problem. I expect others will disagree.
John |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|