View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2863 Location: South Pole, Antarctica
|
Posted: Sat Mar 11, 2017 9:30 am Post subject: REAL*10 |
|
|
"Error 1210: Extended precision floating point (REAL*10) is not supported
in 64-bit mode"
Any suggestions to get more then real*8 ? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8011 Location: Salford, UK
|
Posted: Sat Mar 11, 2017 10:30 am Post subject: |
|
|
I don't have any immediate suggestions relating to FTN95. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2580 Location: Sydney
|
Posted: Sat Mar 11, 2017 11:22 am Post subject: |
|
|
Dan,
You need a real*16 higher precision software emulation library; they must exist. (google quad precision ?)
I have no experience with using these but expect it would be messy and slow !!
I presume you would require a derived type to store the "real*16" variables and have limited access to the calculations.
Would complex(2) provide the storage ?
For simple multiplication and accumulation, see https://en.wikipedia.org/wiki/Kahan_summation_algorithm
This may help.
John |
|
Back to top |
|
|
simon
Joined: 05 Jul 2006 Posts: 270
|
Posted: Sat Mar 11, 2017 2:09 pm Post subject: |
|
|
I don't have access to the book right now to check whether it is what you need, but there is a section on "Arbitrary precision" in "Numerical Recipes" |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1896
|
Posted: Sat Mar 11, 2017 4:28 pm Post subject: |
|
|
See http://crd-legacy.lbl.gov/~dhbailey/mpdist/ for one package that enables multiple precision.
Other compilers have support for REAL*16 using compiler switches.
Multiple precision is not to be chosen without due deliberation and a well-reasoned conclusion that it is necessary. |
|
Back to top |
|
|
|