forums.silverfrost.com

LitusSaxonicum · 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

PaulLaidler · 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.

LitusSaxonicum · 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)

PaulLaidler · 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...

LitusSaxonicum · 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

DanRRight · Posted: Wed Nov 21, 2018 10:36 pm Post subject:

Was precision larger than real*8 implemented in /64 ? The real*10 was missing

PaulLaidler · 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.

mecej4 · Joined: 31 Oct 2006 Posts: 1899

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 .

DanRRight · 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) ?

mecej4 · Joined: 31 Oct 2006 Posts: 1899

That code works only in 32-bits. If you specify /64 when compiling, you will see

FK_GER · Posted: Sat Dec 15, 2018 2:50 pm Post subject:

Hello everyone,
only yesterday I've some time to study my described problem. And sorry, but I don't have tracked the course of the discussion since Nov-15, my last input.
My declaration: The real cause of the differences is the determination of the k-values, especially k3 (look at my previous posted picture). These k-values are buildt with a lot of pre-terms, which for their part are the results of extensive iteration processes. The k3-value depends on more than 12 of these iterated pre-terms for example, at which two of these pre-terms are multiplied with each other at first and added subsequently. At such a process with single precision values rounding inaccuracies appear and have an explicit effect on the following calculated terms.
My solution: All significant terms, which are used for the determination of the k-values, are defined as REAL*8.
Result: The computation of checkmate-version and of the release-version is identically! - Problem solved!