View previous topic :: View next topic |
Author |
Message |
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Thu Nov 15, 2018 10:50 pm Post subject: |
|
|
FK, you mention iterative solution. Do your calculations also involve summation of many values ?
If so there may be an issue with nay rouned values accumulating to produce the levels of error seen here. _________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... " |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Wed Nov 21, 2018 9:20 am Post subject: |
|
|
Eddie
In answer to your question, one way is to write 1.0_3 or 1.0_k where k has been set a call to SELECTED_REAL_KIND.
But if /XREAL is like /DREAL then you will get the extra precision in the constant without adding the kind specifier. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Wed Nov 21, 2018 10:22 am Post subject: |
|
|
Paul, I really meant:
REAL*4 1.0E0
REAL*8 1.0D0
REAL*10 1.0?0
Where ? is the mystical precision-defining letter. I wondered what it might be - that is, if it exists.
Eddie |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Wed Nov 21, 2018 11:34 am Post subject: |
|
|
Eddie
I have had a look and I can only see E and D when parsing a number. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Wed Nov 21, 2018 12:48 pm Post subject: |
|
|
Paul,
I suspected it was so. Presumably, the functions that are intrinsic to the x87 are calculated to 10-byte precision anyway. Thus, one might get a different answer with (say)
Code: | REAL T, A, B
T = TAN(A)
B = T*T |
than with
Code: | REAL T, A, B
B = TAN(A)*TAN(A) |
because T would be truncated down to REAL*4, whereas the result for TAN(A) might just be held in an x87 register. They would both definitely give the same answer with XREAL, and probably one would need to look at the last few significant digits with DREAL.
It;s a pity about there not being a REAL*10 constant (may I suggest 'X' ?), but then many constants are the real equivalent of integers, and the extension even from REAL*4 is a matter of simply adding zeroes.
Thanks for looking.
Eddie |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Wed Nov 21, 2018 1:52 pm Post subject: |
|
|
Eddie
REAL*10 constant are currently available in the form that I described above. Here is a sample...
Code: | integer,parameter::k = SELECTED_REAL_KIND(18,4931)
real(k),parameter::c = 1.23456789012345678_k
print*,c
end |
If you use /XREAL then you don't need the trailing '_k'. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Wed Nov 21, 2018 2:52 pm Post subject: |
|
|
OK Paul,
It hadn't really penetrated my skull, not using KINDs as I'm stuck in the past - The past s a foreign country, they do things differently there. (Usually better, in my view).
Eddie |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Wed Nov 21, 2018 10:36 pm Post subject: |
|
|
Was precision larger than real*8 implemented in /64 ? The real*10 was missing
Last edited by DanRRight on Thu Nov 22, 2018 7:52 pm; edited 1 time in total |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Thu Nov 22, 2018 8:30 am Post subject: |
|
|
REAL*10 is not available for 64 bits. As I understand it, this is a limitation of the hardware (the processor) not FTN95. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Thu Nov 22, 2018 8:27 pm Post subject: |
|
|
But how the code mentioned above claimed to work as real*10 which uses
integer,parameter::k = SELECTED_REAL_KIND(18,4931) ? |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Thu Nov 22, 2018 8:42 pm Post subject: |
|
|
That code works only in 32-bits. If you specify /64 when compiling, you will see
Quote: | *** /DEFREAL_KIND 3 is not available in FTN95/64 |
|
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Sat Nov 24, 2018 10:40 pm Post subject: |
|
|
or even, depending on the context:
*** Extended Precision not available inFTN95/64 _________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... " |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Sat Nov 24, 2018 10:42 pm Post subject: |
|
|
now, what if I asked:
' why is there no difference between:
SELECT_REAL_KIND(18,4931)
and
SELECT_REAL_KIND(15,310) ' ?????? _________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... "
Last edited by John-Silver on Sat Nov 24, 2018 11:00 pm; edited 1 time in total |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Sat Nov 24, 2018 10:57 pm Post subject: |
|
|
like the fool thata I definately am I did some googling on the subject of REAL KINDS and of course fell upon the article from hell
https://comp.lang.fortran.narkive.com/KikBDChI/selected-real-kind-skips-valid-kind-on-free-bsd-9-3
I'm now out of rehab and being treated at the Fortran KIND Rehabilitation Centre
Anyway, at the bottom of that article quoted above there's a code to see what a compiler/machine's REAL KIND characteristics are
I modified the code presented there to:
a) remove the quad precision output (or rather change it to output SP a second time)
b) include SELECT_REAL_KIND(15,310) (as in the original code posted in the article) AND also SELECT_REAL_KIND(18,4931)(the FTN95 extended precision definition as given in this post)
b) have (for me anyway) a more user friendly tabularised output format (you need to also widen your Command Prompt Window)
The results I get are:-
So, as per the question at the top of my comment, why no difference for the 2 extended precision definitions ? Both give the same output/precision. Maybe I've done something wrong.
Why iděs the extended precision ranges E+-19 and not E+-18 ? _________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... "
Last edited by John-Silver on Sat Nov 24, 2018 11:28 pm; edited 8 times in total |
|
Back to top |
|
|
|