forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Difference between release and checkmate?
Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
John-Silver



Joined: 30 Jul 2013
Posts: 961
Location: Aerospace Valley

PostPosted: Thu Nov 15, 2018 10:50 pm    Post subject: Reply with quote

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 are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5609
Location: Salford, UK

PostPosted: Wed Nov 21, 2018 9:20 am    Post subject: Reply with quote

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
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1879
Location: Yateley, Hants, UK

PostPosted: Wed Nov 21, 2018 10:22 am    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5609
Location: Salford, UK

PostPosted: Wed Nov 21, 2018 11:34 am    Post subject: Reply with quote

Eddie

I have had a look and I can only see E and D when parsing a number.
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1879
Location: Yateley, Hants, UK

PostPosted: Wed Nov 21, 2018 12:48 pm    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5609
Location: Salford, UK

PostPosted: Wed Nov 21, 2018 1:52 pm    Post subject: Reply with quote

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
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1879
Location: Yateley, Hants, UK

PostPosted: Wed Nov 21, 2018 2:52 pm    Post subject: Reply with quote

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
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 1879
Location: South Pole, Antarctica

PostPosted: Wed Nov 21, 2018 10:36 pm    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5609
Location: Salford, UK

PostPosted: Thu Nov 22, 2018 8:30 am    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1031

PostPosted: Thu Nov 22, 2018 4:09 pm    Post subject: Reply with quote

I think that Microsoft decided during the initial stages of developing XP-64 that X87 instructions would not be used in 64-bit code. The hardware may be capable of executing X87 instructions, but it would be a big problem to save and restore X87 state in addition to saving and restoring X64 and SSE2 state during a context switch or to service interrupts. Without OS support for X87, what one could do in user code with X87 instructions is extremely limited.

See slide-9 of https://www-zeuthen.desy.de/technisches_seminar/texte/amd64_znsem.pdf , and the following post by Dr. Tim Prince (retd. from Intel): https://software.intel.com/en-us/forums/intel-c-compiler/topic/305407#comment-1616819 .
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 1879
Location: South Pole, Antarctica

PostPosted: Thu Nov 22, 2018 8:27 pm    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1031

PostPosted: Thu Nov 22, 2018 8:42 pm    Post subject: Reply with quote

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
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 961
Location: Aerospace Valley

PostPosted: Sat Nov 24, 2018 10:40 pm    Post subject: Reply with quote

or even, depending on the context:
*** Extended Precision not available inFTN95/64
_________________
''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 961
Location: Aerospace Valley

PostPosted: Sat Nov 24, 2018 10:42 pm    Post subject: Reply with quote

now, what if I asked:
' why is there no difference between:
SELECT_REAL_KIND(18,4931)
and
SELECT_REAL_KIND(15,310) ' ??????
_________________
''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... Smile "


Last edited by John-Silver on Sat Nov 24, 2018 11:00 pm; edited 1 time in total
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 961
Location: Aerospace Valley

PostPosted: Sat Nov 24, 2018 10:57 pm    Post subject: Reply with quote

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 are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... Smile "


Last edited by John-Silver on Sat Nov 24, 2018 11:28 pm; edited 8 times in total
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General All times are GMT + 1 Hour
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
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